[mail] DMARCレポートの読み方

作成:2024年12月1日 　最終更新:2024年12月9日

本記事は「【CPaaS】SMS・メール機能の開発・運用でのやらかし談＆失敗エピソード募集 by ネクスウェイ Advent Calendar 2024」の初日（2024年12月1日）向けに書きました。
https://qiita.com/advent-calendar/2024/cpaas-now

2024年はGmailによる強制もあってSPF/DKIM/DMARCが一気に普及しました。
しかしDMARCは設定後もレポートを受信・確認する必要があります。受信はアドレスを設定するだけですが、問題は確認。

DMARCレポート解析サービス（有料）もありますが、1回ぐらいは自分で目を通しておくと判断に役立つでしょう。

ということで、本稿はDMARCレポートの読み方の話です（最後にちょっと宣伝も入ります）。

■DMARCレポートの標準

DMARCはRFCで規定されています。

RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
https://datatracker.ietf.org/doc/html/rfc7489

DMARCレポートは "7.2. Aggregate Reports" に規定があります。主にメールの受信側（つまりレポート送信側）向けですが、次の点は頭に入れておくといいかもしれません。

・DMARCレポートは原則1日に1回以上送信する（"7.2. Aggregate Reports"）
・DMARCレポートはMIMEパートに格納される、つまり、添付される（"7.2.1.1. Email"）
・DMARCレポート本体はXMLファイルで、GZIP圧縮するべき（"7.2.1.1. Email"）
※実際のDMARCレポートはGZIPではなくZIP形式で送られてくる場合があります（例:Gmail）。一方GZIP(.gz)はWindows 11で標準対応されました。

そしてDMARCレポート本体の形式は、本RFCの付録Cに記載されています。XML Schemaで記載されているので慣れないと読みづらいと思います。記述順序が末端側から上位側に向かうことに留意が必要です。とりあえず項目一覧を階層リスト形式で記載します。

なお項目名末尾にオプション項目は「*」、複数件ありうる項目は「+」をつけています。「*+」はゼロ件・複数件ありえます。

また、この記述はあくまでRFCの内容であり、実際のDMARCレポートは必ずしもこれに準拠していません（ここで必須の項目がなかったり、ここにない項目があったりします）。

  • feedback DMARCレポートのルート要素
    • version DMARCレポートのバージョン（現状では1.0）
    • report_metadata このレポートに関する（主に送信側に関する）メタデータ
      • org_name
      • email
      • extra_contact_info *
      • report_id
      • date_range
        • begin このレポートの範囲の起点
        • end このレポートの範囲の終点
    • policy_published あなたのドメインが公開するDMARCポリシー（DMARCについて書かれたページの多くで説明しているのでここでは割愛）
      • domain
      • adkim
      • aspf
      • p
      • sp
      • pct
      • fo
    • record + 認証結果一覧
      • row
        • source_ip 送信サーバIPアドレス
        • count 本項目に含まれるメール数
        • policy_evaluated 認証結果
          • disposition 受信側での措置 none | quarantine | reject
          • dkim DKIM最終結果 pass | fail
          • spf SPF最終結果 pass | fail
          • reason * dispositionを決定した理由
            • type 理由の種類 forwarded | sampled_out | trusted_forwarder | mailing_list | local_policy | other
            • comment typeの補足情報
      • identifiers
        • envelope_to * いわゆる「エンベロープto」のドメイン
        • envelope_from いわゆる「エンベロープfrom」のドメイン
        • header_from メールヘッダのFrom欄のドメイン
      • auth_results 個別の認証結果
        • dkim *+
          • domain
          • selector *
          • result DKIM単体の認証結果 none | pass | fail | policy | neutral | temperror | permerror
          • human_result
        • spf +
          • domain
          • scope
          • result SPF単体の認証結果 none | neutral | pass | fail | softfail | temperror | permerror

（補足）beginとendは1970-01-01T00:00:00Zからの経過秒数なので、JavaScriptなら new Date(begin*1000) でDateオブジェクトに変換できます。


■DMARCの結果

DMARCレポートで最初に見たいのは「結果」でしょう。結果はXMLで [feedback > record > row > policy_evaluated] にあります。

・disposition : メール受信側（レポート送信側）で最終的にメールをどう扱ったか（そのまま通した | 隔離した | 拒否した）
・dkim : DKIMの最終結果
・spf : SPFの最終結果
・reason : dispositionが通常想定される結果と違う場合の理由。例えば「ARCヘッダが設定された転送/メーリングリストメールなのでSPFやDKIMがfailだが通した」といったこと。

基本的には"disposition"が"none"ならいい、と言いたいところですが、設定に不備があっても通してくれているというケースだと困るので、"dkim"と"spf"も確認しておきたいところです。

DMARCはDKIMとSPFのうち片方だけでもpassすれば全体としてはpassになる仕組みです。ですからレポートの"dkim"と"spf"のうち片方だけでも"pass"になっていればOKですが、実際の環境だと設定はOKなはずなのにサーバへの通信がタイムアウトして"fail"になる可能性もあるので、できれば両方とも原則"pass"にしたいところです。

なお、ここでの"dkim"や"spf"の結果はアライメント(alignment)も評価したものです。

"dkim" : DKIM設定そのもの && DKIMアライメント評価
"spf" : SPF設定そのもの && SPFアライメント評価

アライメントについては詳細は他ページをご覧いただくとして、要するにメールヘッダのFrom欄のドメインがDKIMやSPFで使うドメインと一致するかどうかという話です。DKIMやSPF自体が正しく設定されていても、アライメントが不整合なら、この項目の"dkim"や"spf"は"fail"になってしまいます。

前項の結果が全て満足なもの（"disposition"が"none"、"dkim"と"spf"が"pass"の場合）であれば、それ以上レポートを見る必要はあまりないでしょう。

■DMARCの結果の理由を探る

例えばDKIM設定してるのに"dkim"が"fail"など想定と違う場合は、レポートの他の部分を見ていく必要があります。

見るべき部分のひとつは [feedback > record > row > source_ip] です。送信に使われたSMTPサーバのIPアドレスですが、あなたが使っているSMTPサーバのIPアドレスと一致するか確認します。

調査方針を表にまとめます。

レポートのIPアドレスは、あなたのSMTPサーバのIPアドレスには無い あなたが把握していないSMTPサーバがないか洗い出す。本当になければspamなので件数を注意
レポートのIPアドレスが、あなたのSMTPサーバのIPアドレスと一致する DMARCレポート"auth_results"のresultがpassっぽい DKIMやSPFのアライメントを確認する
DMARCレポート"auth_results"のresultがfailっぽい DKIMやSPFそのものの設定とアライメントの両方を確認する


■あなたのSMTPサーバのIPアドレス以外からメールが送信されている場合

この場合、可能性は2種類あります。


前者の可能性については、頑張って洗い出すしかないと思います。頻繁に同じIPアドレスが使われている場合、ドメインをひいてみると見当がつくかもしれません。

その上で、どれにも当てはまらないものは、迷惑メールとしてカウントします。数が多いようなら、あなたのドメインの評価を上げるためにも、DMARCポリシーの"p"を"none"から"quarantine"や"reject"に変更することを検討するといいでしょう。

■あなたのSMTPサーバからメールが送信されている場合

この場合、先ほどの表に書いたように [feedback > record > auth_results > dkim|spf > result] を確認します。

この値、実は結構バリエーションがありますが、RFC8601で示されています（たぶんこれでいいと思うんですが、違っていたら教えてください）。

Message Header Field for Indicating Message Authentication Status
2.7. Defined Methods and Result Values
https://datatracker.ietf.org/doc/html/rfc8601#section-2.7

ざっくりした意訳を以下に示します。

DKIM (2.7.1.)

none
メッセージに署名がついていない
pass
要するにOK
fail
署名が検証に通らなかった
policy
署名がADMD(公的管理ドメイン)で受け入れ不能だった（すみません。意味が分かってません。2.4.を読む限りSPFのpolicyと同様のような気がしますが、2.7.1.にはそうは書いていません）
neutral
署名に形式的エラーがある、もしくはその他の問題がある
temperror
おそらく一時的な問題で署名が検証できなかったので後ほど再検証する可能性がある
permerror
署名が検証できなかった（必須のヘッダ項目が欠損している場合など）

SPF (2.7.2.)

none
適切なドメイン名、もしくはSPFレコードがない
pass
要するにOK
fail
SPF検証に失敗した（SPFレコード外の送信元からメールが送られている場合）
softfail
SPF検証に「たぶん」失敗した（SPF設定が"~all"になっていて、SPFレコード外からメールが送られている場合）
policy
受信側のローカルポリシーで結果を上書きした場合
neutral
SPFが送信元を確認しない設定("?all")になっている
temperror
一時的な理由（DNS応答タイムアウトなど）で失敗した
permerror
SPF設定が適切に解釈できない


結果が"pass"なら問題なし、"temperror"がたまに出る程度なら、たぶん問題なしです。しかし、送信元IPアドレスが正しいのに"pass","temperror"以外になるなら、DKIMやSPFの設定に問題があると考えるべきでしょう。

なお、この値がpassなのに"policy_evaluated"の"dkim"や"spf"が"fail"になっているのであれば、アライメントが合っていないはずなので確認しましょう。アライメントの比較対象はDKIMもSPFもヘッダfrom（レポートの[feedback > record > identifiers > header_from]）です。

DKIMの比較基準はDKIMシグネチャの"d"パラメータで、DMARCレポートでは[feedback > record > auth_results > dkim > domain] に記載されています。

SPFの比較基準はエンベロープfromで、DMARCレポートでは [feedback > record > auth_results > spf > domain] に記載されています。
（本来なら [feedback > record > identifiers > header_from] にもエンベロープfromがあるはずですが、少なくともGmailからのレポートにはありませんでした）

■補足：転送メールの扱いの例

DMARCの最終結果で、"disposition"が"none"なのに、"dkim"と"spf"が"fail"になる場合があります。

いくつか可能性があるのですが、ここではARCヘッダが設定された実例を紹介します。

<record>
  <row>
    <source_ip>(略)</source_ip>
    <count>2</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
      <reason>
        <type>local_policy</type>
        <comment>arc=pass</comment>
      </reason>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>mekiku.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>googlegroups.com</domain>
      <result>pass</result>
      <selector>20230601</selector>
    </dkim>
    <spf>
      <domain>googlegroups.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>


"dkim"も"spf"も"fail"ですが、"disposition"は"none"で、"reason"の"type"は"local_policy"、"comment"は"arc=pass"。「DKIMもSPFも不成立だがARCヘッダが適切に設定されているので通した」といったところでしょうか。

Google Groupsメーリングリストのようです。転送やメーリングリストはアライメントが通りませんが、ARCヘッダで対応できます。

なおARCヘッダをつけられるソフトがどのくらいあるかはあまり知りません。メーリングリスト「fml」については、ARCヘッダに対応しないままDMARCに通す方法を調べました。

https://mekiku.com/view.php?a=89

■まとめと宣伝

DMARCレポートを受信した後でどう読み、どう対応するかについて、RFCと実際の例を含めつつ紹介しました。ざっくりな手順をまとめると、次のようになります。

・送られてきたGZIP(.gz)もしくはZIP(.zip)ファイルを展開してXMLファイルを抽出する（なお生のXMLが送られてくる可能性もある）
・XMLファイルから"policy_evaluated"を中心に基本的な評価を行う。この際に"source_ip"があなたのSMTPサーバのIPアドレスに含まれるかを考慮する。
・問題がある場合はDKIM設定やSPF設定、アライメントを修正する
・継続的にレポートを評価して、DMARCポリシーを"none"以外にできるか検討する

手動で行うのはかなり大変だと思います。自動評価ツールは自分が見た範囲では有料で、手が出にくいことも多いと思います。

（ここから宣伝）

当サイトでは無料・広告なし・ネットワーク接続なしのシンプルなDMARCレポート可視化ツール m-dmarc を配布しています。

DMARCレポートを固定ディレクトリに配置する必要はありますが、あとはm-dmarcが自動で読み込み、グラフや表として可視化したり、CSVファイルを出力できます。

WindowsとLinuxで利用できますので、ぜひお試しください。

m-dmarc
https://mekiku.com/m-dmarc/

▶（次記事）[mail] Thunderbirdの添付ファイルを自動的に保存する

（一覧）[2.技術情報 (tech)]

(c) mekiku.com