SPFレコードが何度も失敗する理由と直し方

SPFが実際に確認していること

SPF（Sender Policy Framework）は、自分のドメインに置くTXTレコードで、どのサーバーが自分の名前でメールを送ってよいかを列挙します。受信側のサーバーはそのレコードを引き、いま接続してきたIPアドレスと突き合わせ、その接続が認可されているかを判断します。

何を突き合わせているのか、その2点がSPFの混乱のほとんどを説明します。

• SPFが見るのはエンベロープの送信者であり、受信者が目にするFrom:アドレスではありません。エンベロープの送信者（SMTP対話のMAIL FROM、リターンパスとも呼ばれます）はメールソフトでは見えません。まったく別の、偽装されたFrom:を表示しながらSPFを通ることがあり、だからSPF単体ではなりすましを止められません。
• SPFは接続してきたIPアドレスだけを見ます。本文もヘッダーも内容も調べません。問いは1つだけです。このIPはあなたの名前で接続してよかったのか。

ですからSPFの失敗は、レコードの書式が崩れていることをほぼ意味しません。ふつうは、レコードに載っていないどこかからメールが出た、あるいはレコードを最後まで評価できなかった、ということです。これは別々の問題で対処も別で、この先では分けて扱います。

自分のSPFレコードの読み方

SPFレコードはTXTの1行で、4つの構成要素を知れば読めます。

メカニズム：誰が許されているか

各項が許可する送信者を足していきます。ip4:とip6:はアドレスや範囲を直接並べます。aはドメインのAレコードが指す先を認可します。mxは自分のメールサーバーを認可します。実務で最も重いのはinclude:です。別ドメインのSPFレコードを丸ごと取り込み、相手のアドレスを知らなくてもGoogleやMicrosoft、一斉配信サービスを認可できます。

include:は委任であって複製ではありません。相手はいつでも自分の一覧を変えられ、あなたのレコードはそれに追随します。それが狙いであり、同時に、あなたが何も触っていないのにレコードが壊れうる理由でもあります。

修飾子：一致したときどうなるか

各メカニズムには接頭辞が付けられます。+はpassで既定値なので、裸のmxは+mxの意味です。-はハードフェイル、つまり拒否。~はソフトフェイル、受け取るが印を付ける。?は中立で、意見なし、実質的にポリシーなしと同じです。

末尾のall

最後の項はほぼ常にallメカニズムで、レコードが挙げなかったすべての送信者の扱いを決めます。-allはそれ以外を拒否、~allは受け取って印を付ける、+allはインターネット全体を認可してしまい、常に誤りです。

自分のために正当に送っているのが誰かを把握し終えるまでは~allから始め、DMARCレポートがきれいになってから-allへ締めてください。その裏づけなしにいきなり-allにすると、忘れられていた請求システムやヘルプデスクが誰にも届かなくなります。

レコードはちょうど1つ、例外なし

1つのドメインが公開できるSPFレコードは1つです。v=spf1で始まるTXTレコードが2つあるとpermerrorになり、permerrorは検証をまったく評価できないという意味で、厳格な受信側ではただのfailより悪い結果です。これは頻繁に起きます。新しいプロバイダーの設定ウィザードが、既存を編集せず自前のレコードを足すからです。統合するとは、両方のメカニズムを載せた1レコードにすることで、2レコードにすることではありません。

10回参照の上限、静かな破壊者

完璧に見えるSPFレコードがそれでも失敗する、最も多い原因がこれです。

仕様はSPFの評価をDNS参照10回までに制限します。include:、a、mx、ptr、exists:はそれぞれ1回を消費し、取り込んだ各レコードの内側の参照も数に入ります。自身が3つのincludeを含むinclude:は、あなたの10回のうち4回を使います。上限を超えると結果はpermerrorです。失敗ではなく評価不能なレコードで、多くの受信側はこれを未認証として扱います。

厄介なのは、見えないまま勝手に増えることです。書いた時点では通っていた。数か月後、プロバイダーの1社が自社のレコードにinclude:を足し、あなたの合計が10を超え、こちら側は何も変えていないのにメールに印が付き始める。ip4:とip6:は参照を消費しません。これが使える最大のてこです。

レコードが問題ないと決める前に、自分の回数を数えてください。自分のドメインのTXTレコードを引き、次に取り込んだ各ドメインのレコードを引き、展開するものがなくなるまで続けます。DNSクエリツールなら手早く済みます。TXTレコードを見て、include:を1つずつたどってください。

レコードが正しく見えるのにメールが失敗する理由

書式が妥当で参照上限内なら、次を順に当たってください。

• 載っていないサービスから何かが送っている。よくある容疑者は、CRM、請求やチケットのシステム、マーケティングのプラットフォーム、監視ツール、ローカルのメールエージェント経由で送るアプリケーションサーバーです。それぞれにinclude:かIP範囲が必要です。
• エンベロープの送信者が別ドメイン。「あなたの代理で」送るプラットフォームは自社のリターンパスを使うことが多く、SPFは相手のドメインで検証されて通る一方、あなたのDMARCのアラインメントは失敗したままです。認証済みでありながら整合していない、という状態が同時に起こります。
• 自前のレコードがないサブドメイン。SPFは継承されません。mail.example.comからのメールはその名前そのもので検証され、TXTレコードがなければ結果はnoneで、Apexのポリシーではありません。送信するサブドメインごとにレコードを公開し、送るべきでないサブドメインには空のv=spf1 -allを置いてください。
• レコードを変えたがキャッシュが追いついていない。TXTレコードにも他と同じくTTLがあるので、保存した瞬間にどこでも有効になるわけではありません。TTLと反映の仕組みに時間の話があります。
• 古いinclude:。使うのをやめたプロバイダーのドメインがもう解決しない場合、permerrorを生むことがあり、それを知らせる動機は誰にもありません。

転送はSPFを壊す。仕様上そうなっている

これはあなたの落ち度ではなく、あなたのレコードでは直せません。1日を費やす前に理解しておく価値があります。

受信者があなたのメッセージを転送すると——大学のエイリアス、.forwardの規則、メーリングリスト——転送するサーバーは自分のIPアドレスで最終宛先に接続し、エンベロープの送信者はあなたのドメインのままです。受信側はあなたのSPFレコードを、あなたが聞いたこともないIPで検証し、失敗します。当然です。そのIPは実際にあなたが認可していません。

緩和策は2つあり、どちらもSPFの変更ではありません。DKIMはメッセージに暗号署名し転送を生き延びるので、SPFに失敗した転送メールもDKIM、ひいてはDMARCを通れます。両方を運用する主な理由がこれです。SRS（Sender Rewriting Scheme）は転送する側の仕事で、エンベロープの送信者を自分のドメインへ書き換え、SPFが自分に対して検証されるようにします。遠くの転送者にそれを強いることはできません。

実務的な結論。転送されたコピーからSPFを診断しないこと。そして、目に見える失敗のすべてが攻撃者だと思い込んで-allに進まないこと。

SPFが通ることはDMARCが通ることではない

ヘッダーにpassと出ているのにDMARCが失敗する、これはほとんどの人を混乱させます。理由はアラインメントです。

SPFはエンベロープの送信者を認証します。DMARCはそれに加えて、認証されたドメインが目に見えるFrom:のドメインと一致することを求めます。自社のリターンパスで送るプラットフォームは、自社ドメインで申し分のないSPF passを与えてくれますが、それはあなたのFrom:ドメインには何もしません。SPFの検証は通り、アラインメントの検証は通らず、DMARCはその理由で失敗します。

つまりSPFはもともとなりすまし対策ではありませんでした。攻撃者は自分のドメインにまったく正当なSPFを公開したうえで、From:欄にあなたの名前を書けます。認証を、受信者が実際に見るアドレスへ結びつけるのがDMARCであり、誰があなたを装って送っているかを知らせるレポートを届けるのもDMARCです。SPF、DKIM、DMARCのガイドが3つの関係とポリシーの導入手順を扱っています。

失敗するレコードの直し方

この順で進めます。各段階が、後の段階なら隠れてしまう原因を取り除くからです。

• レコードがちょうど1つであることを確認する。TXTレコードを引き、v=spf1で始まるものがいくつあるか数えます。2つ以上はpermerrorです。ほかを調べる前に、メカニズムを1つのレコードへ統合してください。
• 入れ子を含めて参照回数を数える。10回に達しているか近いなら、最も重いinclude:をそれが解決するip4:範囲に置き換え、もう使っていないプロバイダーのincludeを削ります。放置された1つを落とすだけで上限内に戻ることがよくあります。
• 自分のために実際に送っているのは誰かを棚卸しする。ここで信頼できる情報源はDMARCの集約レポートだけです。あなたのドメインを使って送るすべてのIPが、誰も覚えていないシステムまで含めて並びます。推測で作ると不完全なレコードになります。
• ptrは完全にやめる。非推奨で、遅く、信頼できず、これを使うレコードを無視する受信側もあります。
• レポートがきれいになるまで~allのままにし、それから-allへ。不完全なレコードでのハードフェイルは、自分のメールを跳ね返します。
• 編集前にTTLを下げ、外から検証する。自分のDNS管理画面を信じるのではなく、公開中のTXTレコードをDNSクエリツールで見て、古いTTLが切れたあとに再確認してください。

よくある失敗

• SPFレコードが2つある。プロバイダーのウィザードが自前のものを足したため。permerrorであり、failより悪い。
• 10回を超えたまま気づかない。失敗は他人のログに出るpermerrorだからです。
• 正当な送信者を把握する前に-allへ飛ぶ。忘れていたシステムは、たいてい顧客に請求を出しているものです。
• サブドメインが継承すると期待する。継承しません。送信するサブドメインごとにレコードを公開してください。
• ptrを使う、あるいは全員を認可する+allを使う。
• 転送されたメッセージで診断する。転送は正当にSPFを失敗させ、あなたのレコードについて何も教えません。
• SPF passをDMARC passだと思い込む。目に見えるFrom:ドメインとのアラインメントがなければ、そうではありません。
• レコードを編集してすぐ試す。古いTXTレコードはTTLのあいだキャッシュに残っています。

まとめ

SPFは接続してきたIPを1つのTXTレコードと突き合わせ、受信者が読むFrom:ではなく、見えないエンベロープの送信者を検証します。レコードはちょうど1つ公開し、DNS参照の合計を——各include:の内側に入れ子になったものも含めて——10回以下に保ち、自分のために正当に送るすべてのサービスを挙げ、送信するサブドメインにはそれぞれ自前のレコードを与え、DMARCレポートが一覧の完全さを裏づけるまでは~allのままにしてください。転送メールは何をしてもSPFに失敗します。だからこそ隣にDKIMとDMARCがあるのです。任意のドメインの公開中のTXTレコードを読み、各include:を展開し、残りTTLを見るには、無料のDNSルックアップツールを使ってください。

関連ツールとガイド：

• DNS検索 — A、AAAA、MX、TXT、NS などの DNS レコードを値と TTL 付きで照会、さらに逆引き DNS も。
• DMARCレポートの読み方：XMLに溺れずに — DMARC集約レポートに何が入っているのか、XMLを1行ずつ読む方法、自社の忘れられた送信元となりすましの見分け方、そしてp=rejectへ安全に進む手順

よくある質問