SPFレコードの構文とは何か、アプリケーションメールにどう影響するのか

SPFレコードは順序を持つポリシー式である

RFC 7208では、SPFレコードを、最初の項目がv=spf1であるDNS TXTの文字列として定義しています。残りのスペース区切りの項目は、一致判定を行うメカニズムと、処理を変更する修飾子です。評価は左から右へ進み、最初に一致したメカニズムで止まるため、順序そのものがポリシーを表します。典型的なレコードでは、2つの固定アドレス範囲を許可し、1つのプロバイダーのポリシーをincludeし、最後に-allで終わるといった形になります。このパターンをそのまま貼り付けないでください。正しいレコードは、SMTPのMAIL FROMまたはHELOの正確なIDと、実際の送信元によって決まります。まず、アプリケーションのプロバイダー、メールサーバー、サポートツール、ID管理プラットフォーム、マーケティングシステム、転送経路、災害復旧用の送信者を洗い出します。ポリシーは、表示されるFromドメインに自動的に置くのではなく、評価対象となるドメインに公開してください。構文的に有効なレコードであっても、誤った送信元を許可していたり、本番のストリームが漏れていたり、DNSの評価上限を超えていたりすることがあります。

限定子はメカニズムの一致をSPFの結果に対応づける

メカニズムの先頭には限定子を付けられます。+はpass、-はfail、~はsoftfail、?はneutralです。限定子がない場合は+とみなされます。限定子が適用されるのは、そのメカニズムが一致した場合だけです。メカニズムが一致しなかった場合に後続の項目が評価されるかどうかは変わりません。チームは最後のall項目に注目しがちですが、それより前のinclude、アドレス、a、mx、existsの各メカニズムにも限定子があり、評価を終了させることがあります。~allはテストモード、-allはすべての送信元を把握している証拠、と決めつけず、明示的にレビューしてください。failの結果は、評価されたSMTPのIDとIPアドレスに関する受信側の証拠であり、メールを削除せよという普遍的な命令ではありません。受信側は独自のポリシーを適用します。neutralとsoftfailは、許可を意味するpassではありません。許可された送信元、許可されていない送信元、一時的に解決できない送信元について意図する結果を記録し、管理されたIPアドレスとIDのテストデータで検証してください。

アドレス系のメカニズムは直接的だが所有の確認が必要

ip4とip6のメカニズムは、それぞれのプロトコル固有の構文と任意のプレフィックス長で表されたネットワーク範囲に一致するものを許可します。評価時に追加のアドレスルックアップが発生しませんが、送信側のネットワークが変わると古くなることがあります。プライベートな実行環境のアドレスではなく公開の送信アドレスを使い、範囲は運用上のフェイルオーバーが許す限り狭くしてください。すべての範囲に、担当者、送信元システム、環境、変更手順、見直し日を設定します。aメカニズムはAまたはAAAAの名前を解決し、別のdomain-specが指定されない限り、現在のSPFドメインがデフォルトになります。mxメカニズムはMXホストとそのアドレスを解決します。これらのメカニズムはDNSの処理を増やし、アプリケーションのリリースとは無関係に変わるインフラを許可してしまうことがあります。解決されるすべてのアドレスに、その正確なSMTPのIDで送信することを意図して許可する場合を除き、aやmxを近道として使わないでください。変更を監視し、IPv4とIPv6の両方の経路をテストしてください。

includeはテキストの断片ではなく別のポリシーを評価する

includeメカニズムは参照先ドメインのSPFポリシーを評価し、そのネストした評価がpassを返したときに一致します。項目を現在の文字列に機械的に貼り付けるわけではなく、それ以外のネストした結果にもそれぞれ定義された効果があります。includeは、参照先の組織が自社の送信関係のためにそのドメインを明示的に文書化している場合にのみ使ってください。プロバイダーのWebサイトのドメイン、MXドメイン、表示されるFromドメインが、自動的にそのプロバイダーのSPFのinclude先になるわけではありません。includeは運用上の依存関係を生みます。プロバイダーがレコードを変更すると、許可の内容が変わったり、ネストしたDNSルックアップが増えたり、一時的または恒久的なエラーが発生したりすることがあります。ベンダー、サービス、正確なincludeドメイン、契約上の根拠、担当者、削除計画を記録してください。結果となるポリシーを、プロバイダーの実際の送信IPアドレスと自社のエンベロープドメインでテストします。プロバイダーのアドレス変更をすべて追跡し元の意味を保つ責任も引き受けるのでない限り、プロバイダーのincludeをコピーしたIPアドレスのリストにフラット化しないでください。

all、redirect、explanationはそれぞれ役割が異なる

allメカニズムは常に一致し、通常は最後に置かれます。それ以降の項目は評価に影響しません。その限定子によって、それまでに一致しなかった送信元の結果が決まります。redirect修飾子は、現在のレコードのどのメカニズムにも一致しなかった場合に、別のドメインのポリシーを使うようSPFに指示します。redirectはincludeと同じではありません。includeは順序の中の1つのメカニズムであるのに対し、redirectは定義された条件のもとで最終的なポリシーの判断を置き換えます。1つのレコードに複数のredirect修飾子を含めるべきではありません。exp修飾子はfailの結果に対する説明を参照できますが、メールを許可するものではなく、運用面とプライバシー面での考慮事項が増えます。説明は一般的な内容にとどめ、送信者や受信者のデータは含めないでください。ドメイン同士が意図的にポリシー全体を共有し、管理を連携している場合はredirectを選びます。より広いローカルのポリシーの中に、1つのプロバイダーの許可された送信元を追加する場合はincludeを選びます。想定どおりのpassだけでなく、一致しない経路もテストしてください。

ptrは避け、existsとマクロは上級者向けとして扱う

RFC 7208では、ptrメカニズムは遅く、信頼性が低く、負荷が大きいため使用すべきではないとしています。見慣れないIPアドレスをパスさせるためにptrを追加しないでください。existsメカニズムはdomain-specを使ってDNSの存在確認を行うことができ、SPFのマクロは、対応するフィールド内でIDや接続の要素を展開できます。これらを使うと委任や顧客ごとの許可を表現できますが、複雑さ、DNSの処理、プライバシー上の露出、障害パターンが増えます。マクロの構文は任意の文字列テンプレートではなく、定義された文字、変換子、区切り文字、コンテキストだけが有効です。受信者の完全なアドレス、秘密情報、制限のないテナントの入力をDNSクエリに含めないでください。所有するIPアドレス範囲と文書化されたプロバイダーのincludeの単純な組み合わせでポリシーを表現できるなら、そちらを優先してください。高度なポリシーの場合は、本番に出す前に、複数のドメイン、送信者、IPファミリー、空のリバースパス、マクロのエスケープ、NXDOMAIN、タイムアウト、予期しないDNS応答について、決定論的なテストデータを用意してください。

10項目のDNSルックアップ上限を守る

RFC 7208では、SPFの実装が1回のチェックでDNSクエリを発生させる項目を10個までに制限しています。これには、該当するinclude、a、mx、ptr、exists、redirectの処理が含まれます。ネストしたincludeも数に入ります。仕様では、DNSが空の応答や名前エラーを返すvoidルックアップを2回までに制限することも推奨しています。処理の上限を超えると、passではなく恒久的なエラーになることがあります。トップレベルのTXT文字列に見える項目だけでなく、展開した評価グラフ全体を数えてください。1つのプロバイダーのincludeが複数のネストした依存関係を持ち込むこともあり、mxメカニズムは複数のホストのアドレスルックアップを発生させることがあります。取得したDNSのテストデータを使い、標準に準拠した評価ツールを使うと同時に、依存関係のツリーを自分でも確認してください。使っていないプロバイダーや冗長なメカニズムは削除します。プロバイダーの更新が知らないうちに失われる危険なフラット化は避けてください。ポリシーの変更を監視し、上限ちょうどでデプロイするのではなく、プロバイダー側の変化に備えてルックアップの余裕を残しておきましょう。

1つのドメインにはSPFポリシーを1つだけ公開する

RFC 7208では、SPFにDNS TXTレコードを使い、v=spf1で始まるレコードを選択することを求めています。同じ正確なオーナー名に複数のSPFレコードがあると、許可が結合されるのではなく、恒久的なエラーになります。別のアプリケーションにアクセスが必要だからといって2つ目のTXTレコードを追加するのではなく、管理を連携したうえで既存のポリシーを修正してください。その名前に無関係な他のTXTレコードが共存するのは問題ありませんが、選択されるSPFポリシーは1つだけにすべきです。DNSの管理画面が引用符や文字列の分割をどう扱うかを確認し、権威サーバーに照会してから、独立したキャッシュリゾルバーにも照会します。ロールバックに備えて、変更前の値とTTLを保存しておきます。DNSの反映は即時ではなく、ネガティブキャッシュが残ることもあります。ダッシュボードの緑のチェックが証明するのは、そのツールが観測したクエリとパーサーの挙動だけです。受信した生のヘッダーとプロバイダーのログから、本番の正確なエンベロープドメインを検証してください。別のポリシーを公開している可能性のあるサブドメインやバウンス用アドレスも含めて確認します。

SPFの構文とDMARCを混同せずに結びつける

SPFは通常、プロトコルのルールに従ってMAIL FROMドメインまたはHELOのIDを評価します。DMARCは、表示されるRFC 5322のFromドメインを使い、認証されたSPFのドメインがその表示ドメインとアライメントしている場合に限り、SPFを1つの経路として受け入れます。そのため、プロバイダーのReturn-PathでSPFはパスしても、DMARCではアライメントしていないという状況が起こりえます。逆に、SPFが失敗したりアライメントしていなかったりしても、アライメントしたDKIMがパスすればDMARCを満たせます。SPFの結果、評価されたドメイン、接続元IPアドレス、表示されるFrom、DKIMの結果、アライメント、DMARCの結果は、それぞれ別々に記録してください。転送によって接続元IPアドレスが変わることはよくあり、元の送信者が許可されていてもSPFが壊れることがあります。任意の転送サーバーを含めるためにSPFを広げないでください。DKIMや、必要に応じて認証チェーンの仕組みと受信側の証拠を使ってください。SPFのパスは、メッセージの完全性、コンテンツの安全性、受信者の同意、サーバーによる受け付け、受信トレイへの到達を証明するものではありません。

決定論的なワークフローで変更を検証する

DNSを編集する前に、現在のレコードをエクスポートし、各メカニズムと修飾子を担当者と目的とともに列挙します。候補のレコードをRFC 7208の文法で解析し、管理されたスナップショットからDNSの依存関係を展開し、ルックアップを発生させる項目を数え、許可された送信元と許可されていない送信元のIPv4とIPv6のテストデータでテストします。ネストしたincludeがpass、fail、neutral、softfail、一時的なエラー、恒久的なエラーを返した場合の挙動を確認します。HELOによる空のリバースパスの扱い、サブドメイン、プロバイダーのReturn-Path、そしてallまで評価が進むべき送信元をテストします。通常の変更管理の手順で公開し、権威DNSとキャッシュDNSに照会してから、実際のすべてのストリームを通して管理されたテストメッセージを送信します。信頼できる受信側の生のAuthentication-Resultsを保存し、想定したIDと比較します。本番の送信元が漏れている場合、複数のレコードが選択される場合、ルックアップ上限のエラー、広範囲のtemperror、意図しない許可が見つかった場合はロールバックしてください。迷惑メールを送ってテストすることは絶対にしないでください。

SendHQでSPFを設定する

SendHQは、送信者ID設定の一部としてSPF TXTポリシーをプロビジョニングします。競合するSPFポリシーがあると設定を停止し、無関係なポリシーを黙って上書きするのではなく、推奨される統合SPF値を報告します。選択可能なSPFポリシーは正確に1つだけ保持してください。設定と修復の詳細については、Domains and DNSドキュメントを参照してください。

よくある質問

出典

• RFC 7208：Sender Policy Framework（SPF）の仕様 — RFC Editor
• RFC 7489：ドメインベースのメッセージ認証・レポート・適合（DMARC） — RFC Editor
• RFC 5321：簡易メール転送プロトコル（SMTP） — RFC Editor