用語 · SPFレコードの確認

アプリケーションメールのSPFレコードはどう確認すればよいですか？

SPFは、表示されるFromドメインではなく、SMTP MAIL FROMアドレスで使用するドメインで確認してください。TXTをクエリし、v=spf1で始まる1つのレコードを選択して、すべての項を検証し、送信IPに対してメカニズムを左から右へ評価し、DNSクエリの項を数えながらincludeまたはredirectをたどります。次に、受信者側のSPF結果と、認証済みドメインがDMARCに対してアライメントしているかを確認します。SPF passはSMTP IDに対して送信クライアントを許可しますが、DKIM、DMARC、配信、受信トレイ到達率を証明するものではありません。

まずSPFが実際に確認するIDから始める

SPFのチェックには3つの入力が必要です。SMTPクライアントのIPアドレス、許可ポリシーを評価する対象のドメイン、そして送信者IDです。通常のアプリケーションメールでは、このドメインはSMTPのMAIL FROMアドレス（エンベロープ送信者やリターンパスとも呼ばれます）から取得されます。これは、メッセージのFromヘッダーに表示されるアドレスとは異なる場合があります。配信状態通知（DSN）のようにMAIL FROMが空の場合、SPFはMAIL FROMのチェックにHELOのIDを使います。DNSを調べる前に、受信したテストメッセージや送信プロバイダーの設定から、実際の接続元IPとエンベロープIDを記録しておきましょう。アプリケーションが実際にはbounce.provider.testやbounces.example.testのMAIL FROMで送信している場合、Fromに表示されているという理由でexample.testを確認しても、結論は得られません。

MAIL FROMのドメインそのものでTXTを照会する

最初のステップで特定したドメインそのものに対してDNSのTXTを照会します。RFC 7208では、SPFバージョン1のポリシーは、対象となるオーナー名にTXTレコードとして公開することが求められています。無関係なTXTの値は無視し、バージョン部分がちょうどv=spf1であるレコードを選びます。該当するレコードがなければ、SPFの結果はnoneになります。該当するSPFレコードが複数あるとpermerrorになります。ベンダーごとに別々のレコードを公開しても、それらを結合したことにはなりません。1つのTXTリソースレコードがDNSツールによって引用符付きの複数の文字列に分割されることがありますが、それらの文字列はSPFのパース前にスペースを挟まず連結されます。変更後に同じチェックを再実行できるよう、応答全体、リゾルバー、照会時刻、TTLを記録しておきましょう。

構文を検証し、項を左から右へ評価する

SPFレコードは順序を持つポリシーであり、プロバイダーを順不同に並べたリストではありません。v=spf1の後、メカニズムは一致するものが見つかるまで左から右へ評価されます。先頭のクオリファイアが結果を決めます。+はpass（省略時の既定値）、-はfail、~はsoftfail、?はneutralを意味します。ip4とip6のメカニズムは、クライアントのアドレスを特定のアドレスやネットワークと比較します。aとmxのメカニズムはDNSを解決し、includeは別のドメインのSPFポリシーを評価して、includeのルールに従う場合にのみ一致します。existsはDNSに基づくテストを行います。allは常に一致し、一般にレコードの末尾に置かれます。どこかに構文エラーがあると、通常の評価の前にpermerrorになります。有用なチェッカーは、色付きのバッジを返すだけでなく、どのメカニズムが一致したか、そのクオリファイア、展開された各ドメインを報告するべきです。

includeとredirectはエイリアスとして扱わずにたどる

すべてのincludeとredirectを、同じ評価コンテキストのままたどります。includeはメカニズムであり、取り込んだポリシーが現在のクライアントと送信者に対してpassを返すかを問い合わせ、一致しなければ元のレコードの評価を続けます。redirectはモディファイアであり、現在のレコードのメカニズムがどれも一致しなかった後に考慮されます。クライアントIPと送信者はそのままに、評価を別のポリシーに移します。レコード内のどこかにallがあれば、redirectは無視されます。この違いは移行時に重要です。include:vendor.testをredirect=vendor.testに置き換えると、単にベンダーを追加するのではなく、ドメイン所有者のフォールバックポリシー全体を置き換えてしまう可能性があります。循環参照、存在しない参照先、無効な参照先、ネストした恒久的・一時的なエラーを検出し、プロバイダー側のポリシー変更が見えるよう、結果に依存関係の連鎖を残しておきましょう。

DNSクエリの上限を全体で数える

DNSクエリを発生させる項は、トップレベルのレコードだけでなく、再帰的な評価全体で数えます。RFC 7208では、1回のSPF評価におけるinclude、a、mx、ptr、exists、redirectの項は10個までに制限されており、上限を超えるとpermerrorにしなければなりません。all、ip4、ip6のメカニズムはこの上限を消費しません。MXとPTRの処理には、アドレス照会について別の上限があります。RFCはさらに、void lookup（応答は成功したが空、または名前エラーとなるもの）を2回までに制限し、超えた場合はpermerrorにすることを推奨しています。ptrメカニズムは低速で信頼性に欠けるため、使用は推奨されていません。レコード自体は短く見えても、プロバイダーのincludeが展開されてネストした項が増え、上限を超えることがあります。そのため、合計数、それに寄与した各項、void lookup、テストしたIPについて実際にたどった分岐を報告しましょう。

SPFの結果を過大に解釈しない

結果は標準の用語で表します。passは、テストしたクライアントがチェック対象のSMTPのIDを使うことを許可されている、という意味です。failは、一致する否定的な許可が見つかったことを意味します。softfailは弱い否定の表明であり、neutralはドメインがそのクライアントについて何も表明していないことを示します。noneは、該当するSPFレコードがないことを意味します。temperrorは評価時の一時的な問題（多くはDNS）を、permerrorは正しく評価できないポリシーを表します。どのメカニズムにも一致せずredirectも適用されない場合、結果はneutralとなり、暗黙の?allと同じ扱いになります。結果は、ID、クライアントIP、一致した項、DNSのトレース、時刻とあわせて報告してください。passを「安全なメッセージ」「受信者が望むメール」「プロバイダーによる受け付け」「メールボックスへの配信」「受信トレイへの到達」と読み替えてはいけません。SPFはそれらの結果を決めるものではないからです。

公開されたレコードだけでなく、実際のメッセージを確認する

静的なレコードのチェックでわかるのは、ポリシーを検出してパースできるかどうかです。アプリケーションが想定どおりのMAIL FROMドメインや送信IPを使ったことまでは証明できません。本番で実際に使う経路ごとに、自分が管理する受信アカウント宛てに管理されたテストメッセージを送り、受信したヘッダーを調べてください。接続元IP、エンベロープ送信者、受信側のAuthentication-Resultsのエントリを、DNSでの評価結果と比較します。リターンパスが変わりうるプロバイダー、リージョン、専用または共有のプール、フォールバック経路、メッセージの種類ごとに繰り返しましょう。アドレスやルーティングの詳細は機密になりうるため、ヘッダーはアクセスを制限したストレージに保存してください。プロバイダーのダッシュボードと受信したメッセージの内容が食い違う場合は、実際に通った経路の証拠としてメッセージのほうが信頼できます。ただし、単一の受信側で得た結果を、あらゆる配信に当てはまる挙動として一般化すべきではありません。

DMARCアライメントは別のステップとして評価する

プロバイダー所有のリターンパスのドメインでSPFがpassしても、DMARCがその結果を使えない場合があります。現在のDMARCのルールでは、SPF認証に成功したRFC5321.MailFromのドメインと、表示上のRFC5322.Fromフィールドにある作成者ドメインを比較します。strictのアライメントでは同一のDNSドメインである必要があります。relaxedのアライメントでは、DMARCの探索ルールで同じ組織ドメインに解決されるドメインであれば認められます。たとえば、relaxedモードではbounces.example.testとexample.testはアライメントしますが、bounce.provider.testとexample.testはアライメントしません。DMARCの結果は、アライメントした検証済みのDKIM署名に基づくこともできるため、SPFの結果がアライメントしていないからといって、それだけでDMARCが失敗するわけではありません。認証とアライメントはそれぞれ独立して報告し、末尾2ラベルを固定的に比較するのではなく、現行のドメイン探索手順を使ってください。

プロバイダー固有のMAIL FROM設定をテストする

実際の通信でどのSPFのIDが使われるかは、プロバイダーの設定によって決まります。たとえばAmazon SESでは、独自のMXレコードとSPFのTXTレコードを必要とするカスタムMAIL FROMドメインについて説明されています。カスタムドメインのMXの設定に誤りがある場合、SESは設定された挙動に応じて、リージョンに依存するamazonses.comのMAIL FROMドメインにフォールバックするか、送信を拒否します。このフォールバックによって、表示上のFromアドレスが変わらなくてもDMARCのアライメントが変わることがあります。どのプロバイダーでも、設定されたリターンパスのドメイン、必要なDNSの値、フォールバックの挙動、送信リージョン、所有者を記録しておきましょう。DNSやプロバイダーの設定を変更した後は、関連するキャッシュ済みの応答が期限切れになるのを待ってから、DNSの評価と管理されたテスト送信を繰り返してください。ベンダーのincludeを表示上のFromドメインにそのままコピーしてはいけません。それが実際のIDであり、そのドメインの送信元一覧全体がそれを裏付ける場合に限って行ってください。

変更時には再現可能なSPF監査を行う

送信経路ごとに1行を用意し、担当者、アプリケーション、メッセージの種類、表示上のFromドメイン、MAIL FROMドメイン、HELOドメイン、想定される送信元のIP範囲、依存するプロバイダー、最後に管理されたテストを行った日時を記録します。各SPFチェックについて、選択されたレコード、再帰的なトレース、DNSクエリ数、一致したメカニズム、結果、アライメントの判定、機密性のないテスト識別子を保存します。移行中は、新旧の正規の送信元を、必要な移行期間に限って許可しておきます。新しい経路を検証したら、古くなった許可を意図的に削除してください。拒否に反応するだけでなく、恒久的・一時的な認証エラーを監視しましょう。プロバイダーの変更、IPプールの移動、ドメインの変更、DNSの編集、新しいアプリケーションの追加の後には、監査を再実行します。このワークフローによって、正規の経路をブロックしてしまう狭すぎるポリシーと、使われていない許可を残したままの広すぎるポリシーの両方を見つけられます。

同じ証拠基準でSendHQを確認する

SendHQでは、直接送信には検証済みワークスペースドメイン上のアドレスを使用する必要があると文書化されています。これは送信者IDを検証しますが、SPF評価に代わるものではありません。管理されたSendHQメッセージでも、上記と同じDNSトレース、受信ヘッダーの調査、SPF結果、DMARCアライメントの確認が必要です。

よくある質問

SPFを確認するときはどのドメインを使えばよいですか？

通常のメッセージでは、SMTPのMAIL FROMアドレスのドメインを使います。リバースパスが空の場合は、RFC 7208の規定どおりHELOのIDを使います。表示上のFromドメインがSPFのIDであるとは限りません。

2つのプロバイダーのために、1つのドメインに2つのSPFレコードを公開できますか？

いいえ。DNSレコードの選択時にSPFのバージョン部分で始まるレコードが複数見つかると、評価結果はpermerrorになります。構文、サイズ、再帰的なDNSクエリの上限を守りながら、サポートされているメカニズムを1つのポリシーにまとめてください。

SPFレコードで使えるDNSルックアップは何回までですか？

1回の評価で使えるのは、再帰的な処理全体を通して、DNSクエリを発生させるinclude、a、mx、ptr、exists、redirectの項が最大10個までです。上限を超えるとpermerrorになります。ip4、ip6、allのメカニズムを直接使う場合は、この上限を消費しません。

SPFがpassすればDMARCもpassしますか？

必ずしもそうとは限りません。DMARCがSPFを利用できるのは、成功したMAIL FROMのIDが、設定されたstrictまたはrelaxedモードの下で表示上のFromドメインとアライメントしている場合に限られます。アライメントした検証済みのDKIM署名が、代わりの認証済み識別子になることもあります。

オンラインのSPFルックアップの結果が、受信したメッセージと食い違うのはなぜですか？

ツールが表示上のFromドメインを確認していた、別のクライアントIPを使っていた、別のDNSキャッシュを参照していた、あるいはネストしたエラーを省略していた可能性があります。ツールの入力値を、実際のメッセージのエンベロープID、接続経路、受信側の認証結果と比較してください。

メールプロバイダーを変更した後は何を確認すべきですか？

新旧すべてのMAIL FROMドメイン、SPFの再帰的な依存関係、DNSクエリ数、実際の送信元IP、プロバイダーのフォールバック、受信時のSPFの結果、DMARCアライメントを確認します。古い許可を削除したりトラフィックを増やしたりする前に、メッセージの種類ごとにテストしてください。

出典

さらに学ぶ

アプリケーションメールのDMARCチェック方法DNSルックアップと配信を混同することなく、DMARCレコードの検出、構文、SPFとDKIMのアライメント、ポリシー、レポート、実際のアプリケーションメッセージを確認します。SMTPプロトコルとは？アプリケーションメールが届く仕組みSMTPのサブミッション、リレー、エンベロープ、応答コード、TLS、再試行、メッセージの内容が、アプリケーションのメールワークフローにどう関わるかを解説します。