用語 · DMARCチェック

アプリケーションメールのDMARCチェックはどのように行うのか

DMARCチェックでは、4つの事項を個別に検証する必要があります。有効なポリシーをDNSで検出できること、必須タグが正しく解析されること、実際のメッセージで、認証済みのSPFまたはDKIMの識別子の少なくとも1つが表示されるFromドメインとアライメントしていること、そしてポリシーを適用する前に正当なアプリケーションの送信者がすべて把握されていることです。_dmarcの名前を照会してレコードを確認し、そのうえで管理されたテスト送信のメッセージ認証結果を調べます。DMARCのパスはドメインの使用が許可されていることを検証するものであり、配信や受信トレイへの到達を証明するものではありません。

DMARCチェックは1回のルックアップではなく4つのテストとして扱う

有用なチェックは4つの層で構成されます。1つ目は、メッセージの作成者ドメインに適用されるポリシーを検出することです。2つ目は、DNSが返したテキストをそのまま受け入れるのではなく、TXTレコードをDMARCポリシーとして検証することです。3つ目は、実際のメッセージで識別子のアライメントをテストすることです。SPFで認証されたMAIL FROMドメイン、または検証済みのDKIM署名ドメインが、表示されるFromヘッダーのドメインとアライメントしている必要があります。4つ目は、そのドメインを使うすべての正当なアプリケーション、プロバイダー、リージョン、メッセージの種類から送信して、運用上のカバー範囲を確認することです。DNSルックアップで問題がなくても、カバーできるのは最初の2層の一部だけです。プロバイダーが意図したドメインで署名していること、カスタムのReturn-Pathが有効であること、転送によってSPFの挙動が変わったかどうか、見落とされたシステムがポリシーの適用後も問題なく動くかどうかは、それではわかりません。

正しいDNS名を照会し、ポリシーの検出手順に従う

まず、RFC5322のFromヘッダーにある正確なドメイン、いわゆる作成者ドメインから始めます。_dmarcにそのドメインを続けた名前でTXTを照会します。alerts@notify.example.testからのメッセージであれば、Webサイトのホスト、MXホスト、Return-Pathのドメインではなく、_dmarc.notify.example.testから始めます。RFC 9989では、ポリシーの検出を1回のルックアップ以上のものとして定義しています。作成者ドメインに有効なレコードがない場合、受信側はDNSツリーをたどって、該当する組織ドメインまたはパブリックサフィックスのポリシーを見つけることができます。サブドメインの扱いは、何が存在し、どこでポリシーが見つかったかによって、sp、np、pのいずれかのタグから決まります。そのため、チェッカーは照会した名前と実際に選択したポリシードメインの両方を報告すべきです。「レコードが見つかりました」とだけ示す結果では、継承の誤りや、想定される扱いを変えてしまう明示的なサブドメインポリシーが見えなくなることがあります。

ポリシーを解釈する前にレコードの構造を検証する

DMARCポリシーレコードはタグと値の構文を使用します。RFC 9989では、v=DMARC1が必須で、大文字小文字を区別し、先頭に置く必要があります。有効なpタグは要求された評価ポリシーを示します。一般的なポリシー値はnone、quarantine、rejectです。オプションのタグは、レポート送信先、サブドメインの動作、strictまたはrelaxedのSPFおよびDKIMアライメントを記述します。スペルミスのタグ、欠けたp値、重複または競合するレコード、不正な区切り文字、DNSプロバイダーの引用符によるアーティファクトを含む値を、暗黙に修正しないでください。恒久的な評価エラーは、DMARCのpassまたはfailではなく、修正が必要な結果として扱います。また、一時的なDNSルックアップエラーと不正なレコードを区別してください。一時的なリゾルバー障害は管理された経路を通じて再試行しますが、権威DNSを確実にクエリできるまで、そのドメインにはポリシーがないと主張してはいけません。

実際のメッセージでSPFとDKIMのアライメントを確認する

DMARCは、DNSの設定単体ではなく、メッセージの認証に対して評価されます。SPFについては、認証されたMAIL FROMドメインを表示されるFromドメインと比較します。DKIMについては、検証に成功した各署名のd=ドメインを、表示されるFromドメインと比較します。relaxedアライメントでは組織ドメインが同じドメインを許容し、strictアライメントではドメインが完全に一致する必要があります。認証済みの識別子の少なくとも1つが元のメカニズムでパスし、かつアライメントしていれば、メッセージはパスします。たとえば、プロバイダーのReturn-PathによってSPFはプロバイダーのドメインでパスしても、billing.example.testとはアライメントしないことがあります。relaxedアライメントでDKIMがd=example.testで検証されれば、そのメッセージはそれでもDMARCにパスできます。管理された受信者アカウントで生のAuthentication-Resultsヘッダーを取得してください。ただし、このヘッダーは評価した受信側の結果を報告するもので、複数のホップや署名を含むことがあるため、文脈を踏まえて解釈してください。

pass、fail、none、errorの結果を正確に読み取る

DMARC passは、ポリシーレコードが適用され、認証されたSPFまたはDKIM IDが作成者ドメインとアライメントしていることを意味します。failは、ポリシーが適用されるがアライメントした認証済みIDが存在しないことを意味します。noneは、適用可能なポリシーが見つからなかったことを意味します。permerrorとtemperrorはDMARC評価中のエラーを示します。DNSエラーを含むメッセージはDMARCのpassまたはfailとは見なせません。これらの結果は、メールボックスプロバイダーがメッセージをどこに配置したかを示すものではありません。RFC 9989は、passをドメイン所有者の使用が許可されたことの検証に明示的に限定しており、メッセージが安全、望ましい、レピュテーションが高い、または受信トレイにふさわしいとは主張していません。診断とダッシュボードでは、プロバイダーによる受け付け、受信サーバーによる受け付け、DMARC結果、苦情シグナル、観測された配置を別々のフィールドとして保持してください。

ポリシーを適用する前にすべての正当な送信者を把握する

Fromにそのドメインを使うすべてのシステムを洗い出します。本番アプリケーション、認証メール、請求の通知、サポートツール、マーケティングプラットフォーム、監視アラート、CRMのワークフロー、リージョン別のアカウント、緊急時用のシステムなどです。ストリームごとに、表示されるFromドメイン、MAIL FROMドメイン、DKIMのd=ドメインとセレクター、プロバイダーのアカウント、担当者、メッセージの種類、想定される送信量を記録します。通常の本番の経路で管理されたテストメッセージを送信し、認証とアライメントの両方を検証します。DMARCの集約レポートでそのドメインを使っている送信元がわかることもありますが、解釈が必要で、転送や不正なトラフィックが含まれている場合もあります。インベントリが不完全なうちはモニタリングから始め、受信側により強い処理を要求する前に、アライメントしていない正当なストリームを修正してください。1つのアプリケーションの結果を緑にするためだけに共有の組織ポリシーを変更したり、1通のテストメッセージだけを根拠にポリシーの適用に進んだりしないでください。

アプリケーションメールでよくある失敗を診断する

ポリシーが見つからない場合は、値を編集する前にDNSゾーンとレコード名を確認します。レコードに恒久的なエラーがある場合は、有効なポリシー1つにまとめ、タグの順序と構文を確認します。DKIMが失敗する場合は、想定したセレクターが存在するか、テストしたメッセージにプロバイダーが実際に署名したか、転送中に本文や署名対象のヘッダーが変更されていないか、検証されたd=ドメインがアライメントしているかを調べます。SPFはパスしているのにDMARCが失敗する場合は、SPFのパスなら何でも十分だとみなさず、MAIL FROMドメインを表示されるFromドメインと比較してください。転送されたメールだけが失敗する場合は、転送によってエンベロープの経路が変わることが多く、SPFが壊れても有効でアライメントしたDKIM署名は残る場合があることを思い出してください。展開によって拒否が発生した場合は、失敗したヘッダーと受信側の応答を保存し、それ以上のポリシーの強化を止め、関係のない認証の制御を弱めるのではなく、原因となっているストリームを修正してください。

プロバイダー固有のアライメントのルールを意図して適用する

サードパーティの送信者には、認証済みの識別子を組織が管理するドメインに結びつける設定が必要です。Amazon SESは2つの方法を文書化しています。SPF用にアライメントしたカスタムMAIL FROMドメインを使う方法と、アライメントしたDKIM署名ドメインを使う方法です。デフォルトのプロバイダー所有のReturn-PathではSPFの認証には成功しても、表示されるFromドメインとはアライメントしないことがあるため、カスタムMAIL FROMドメインを設定していない限り、実際にアライメントを取れるメカニズムはDKIMになることが多いです。他のプロバイダーでは、Return-Path、バウンス用ドメイン、ドメイン認証、署名IDに別の名前を使っています。ダッシュボードの検証済みバッジがDMARCを成立させると決めつけず、実際に出力されたメッセージを検証してください。現在のGmailの送信者ガイドラインでも、該当するトラフィックに認証とアライメントを求め、DMARCレポートを推奨しています。受信側の要件やプロバイダーの機能は変わることがあるため、リリース時とインシデントのレビュー時に公式ドキュメントを再確認してください。

プロバイダーの証拠をDMARC判定として扱わずに使用する

SendHQは、検証済みドメイン送信、配信イベント、サプレッション、Webダッシュボードをサポートしています。メッセージストリームの調査には送信ドメインと配信情報を使用し、その後、受信側のAuthentication-ResultsヘッダーでDMARCを検証して、SPF、DKIM、アライメントの証拠を分離してください。プロバイダーによる受け付けと配信イベントは、受信トレイ到達率を証明しません。

監査可能なDMARCチェックの結果を記録する

長く使える結果には、作成者ドメイン、照会時刻、リゾルバー、照会した_dmarcの名前、選択されたポリシードメイン、正規化したレコードそのもの、ポリシーとアライメントのモード、DNSのステータス、そして解析の結果が有効な構文、permerror、temperrorのどれだったかを含めます。管理されたテストメッセージごとに1行を追加し、機密性のないメッセージ識別子、送信システム、表示されるFromドメイン、認証されたSPFドメインとその結果、検証されたDKIMドメインとセレクター、アライメントの判定、最終的なDMARCの結果、受信側を記録します。生のヘッダーはアドレス、ルーティングの詳細、内部の識別子を露出させる可能性があるため、アクセスを制限したストレージに保管してください。各指摘事項を担当者と修正予定日に紐づけます。DNSのTTLの期限切れ、プロバイダーの設定変更、鍵のローテーション、新しいメッセージストリームの追加、ポリシーの強化のあとには再チェックします。こうした証拠によってチェックを再現できるようになり、元の設定が変わったあともスクリーンショットやツールのバッジが永続的な証拠として扱われることを防げます。

よくある質問

DMARCレコードはどこでチェックすべきですか？

まず、_dmarcに表示されるFromアドレスの正確なドメインを続けた名前でTXTを確認します。最初に照会した名前に有効なレコードがない場合は組織ドメインやサブドメインのポリシーが適用されることがあるため、現在のDMARCの検出ルールによって選択されるポリシードメインも特定してください。

v=DMARC1が見つかれば、DMARCにパスしていることになりますか？

いいえ。v=DMARC1は有効なポリシーレコードの要素の1つにすぎません。メッセージがパスするのは、表示されるFromドメインとアライメントしたドメインでSPFまたはDKIMが認証に成功した場合です。実際のメッセージでテストし、受信側の認証結果を確認してください。

SPFがアライメントしていなくてもDMARCにパスできますか？

はい。検証に成功したDKIM署名があれば、DMARCに必要なアライメントした認証済みの識別子になります。その逆も可能で、DKIMがパスしなくても、アライメントしたSPFでパスできます。ただし、1つのメカニズムだけに頼ると耐障害性が下がります。

DMARCにパスすれば受信トレイへの到達が証明されますか？

いいえ。証明されるのは、そのメッセージについて作成者ドメインの使用が許可されていることです。受信側は、メッセージを受け入れる、拒否する、隔離する、分類する際に、レピュテーション、コンテンツ、受信者、不正利用、独自のポリシーといったシグナルを引き続き適用できます。

アプリケーションはいきなりp=rejectに移行すべきですか？

通常、インベントリと監視の証拠がなければできません。正当な送信者をすべてマッピングし、管理されたメッセージでアライメントを検証し、集計レポートを確認し、失敗を修正して、より強い処理を要求する前にドメイン所有者とポリシー変更を調整してください。

メールプロバイダーを切り替えたあとは何を再確認すべきですか？

各Fromドメインについて検出されるポリシー、プロバイダーのMAIL FROMドメインとDKIMドメイン、セレクターのDNS、SPFとDKIMの結果、relaxedまたはstrictのアライメント、集約レポート、そして管理されたテストで送るアプリケーションのすべてのメッセージの種類を、本番のトラフィックを増やす前に再確認してください。

出典