DMARC集計レポートの読み方と、p=rejectへ安全に移行する方法

DMARC集計レポートは、メールボックスプロバイダーが通常1日1回お送りするXMLファイルで、お客様のドメインを名乗って送信されたすべての送信元と、それぞれがSPF、DKIM、アラインメントを通過したかどうかが記載されています。これを読むことで、正当な送信元をすべて把握し、失敗しているものを修正し、なりすましている相手を発見できるため、正当なメールをブロックすることなくp=noneからp=rejectへ移行できます。

要点まとめ

1. レポートを要求する。ポリシーがp=noneのうちに、DMARCレコードにruaアドレスを追加します。
2. 待って収集する。月次の送信を含め、2〜4週間分のレポートを集めます。
3. 送信元を分類する。各送信元IPを、正当でアラインしているもの、正当だが失敗しているもの、不明なものに分けます。
4. 失敗を修正する。正当な各サービスに、アラインしたDKIM署名またはReturn-Pathを設定します。
5. 段階的に適用する。低い割合でquarantineを始め、割合を上げてから、rejectに移行します。

レポートを要求するDMARCレコード

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

タグ	意味
p	失敗したメールに対するポリシー:none(監視)、quarantine、reject
rua	集計レポートの送信先。1つ以上のmailto:アドレスで指定
adkim, aspf	アラインメントモード:r はリラックス(サブドメインも一致可)、s はストリクト(完全一致)
sp	pと異なる場合のサブドメイン用ポリシー
pct	ポリシーを適用する、失敗したメールの割合

別のドメインにレポートを送る

ruaアドレスが、レポート対象のドメインとは別のドメインにある場合、その別のドメインが受信を許可するレコードを公開している必要があります。そうでないと、プロバイダーはレポートを送信しません。example.comに関するレポートをreports.example.netに送る場合は次のとおりです。

example.com._report._dmarc.reports.example.net.  3600  IN  TXT  "v=DMARC1"

レポートの中身

レポートは、通常gzipまたはzipで圧縮された添付ファイルとして届きます。開くと、レポートの送信者に関する情報、プロバイダーが確認したポリシー、そして送信元IPと結果の組み合わせごとに1行ずつの一覧という3つの部分があります。

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <report_id>1234567890</report_id>
    <date_range><begin>1759708800</begin><end>1759795199</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain><adkim>r</adkim><aspf>r</aspf><p>none</p><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>1250</count>
      <policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>pass</spf></policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><selector>mail1</selector><result>pass</result></dkim>
      <spf><domain>bounce.example.com</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

フィールド	分かること
org_name	レポートを送ったメールボックスプロバイダー
date_range	対象期間(Unixタイムスタンプ)
policy_published	プロバイダーが確認したDMARCポリシー。レコードが有効になっているかの確認に使える
source_ip と count	送信元サーバーと、その期間に送信したメッセージ数
policy_evaluated	DMARCで重要となる結果。ここでのdkimとspfは、アラインした上での通過または失敗を意味する
auth_results	SPFとDKIMの生の結果と、認証されたドメイン(Fromドメインとは異なる場合がある)
header_from	表示上のFromアドレスのドメイン

すべての送信元を3つのグループに分類する

グループ	見え方	対処
正当でアラインしている	既知のサービスで、policy_evaluatedでDKIMまたはSPFがアラインしている	何もしない。その状態を維持する
正当だが失敗している	既知のサービスで、auth_resultsは通過するがpolicy_evaluatedは失敗する	そのサービスにアラインしたDKIMまたは独自のReturn-Pathを設定する
不明	見覚えのないIPで、多くの場合、失敗が多数ある	調査する:忘れられたシステム、転送元、またはなりすまし。正体が分かるまで承認しない

送信元の特定方法

• 逆引きDNS:dig -x 203.0.113.10 +shortで、プロバイダー名が分かることが多くあります。
• 認証ドメイン:auth_resultsにあるSPFとDKIMのドメインから、サービスが分かる場合がほとんどです。
• 自社の一覧:お客様のドメインとして送信するすべてのツール(マーケティングプラットフォーム、ヘルプデスク、CRM、請求システム、Webフォーム、人事ツール、サーバー)を一覧にします。
• 送信量とパターン:既知のサービスからの少量で安定した件数は正常です。不明なIPからの突然の急増は疑わしいといえます。

短いスクリプトでレポートを集計する

展開済みレポートが入ったフォルダーを最初に確認するには、次のスクリプトで、送信元IPとDMARCの結果ごとにメッセージ数を集計できます。

import glob
import xml.etree.ElementTree as ET
from collections import defaultdict

totals = defaultdict(int)
for path in glob.glob("reports/*.xml"):
    for rec in ET.parse(path).getroot().iter("record"):
        row = rec.find("row")
        ip = row.findtext("source_ip")
        ev = row.find("policy_evaluated")
        key = (ip, ev.findtext("dkim"), ev.findtext("spf"))
        totals[key] += int(row.findtext("count"))

for (ip, dkim, spf), n in sorted(totals.items(), key=lambda x: -x[1]):
    print(f"{ip:18} dkim={dkim:5} spf={spf:5} messages={n}")

アラインメント失敗の修正

レポートのパターン	原因	対処
SPFは通過するがDMARCは失敗する	SPFが認証したのはプロバイダーのドメインで、お客様のドメインではない	ご自身のドメインで独自のReturn-Pathを使う
DKIMは通過するがDMARCは失敗する	署名のd=にプロバイダーのドメインが使われている	ご自身のドメインで署名する:そのサービス用のDKIMセレクターを公開する
既知のサービスで両方とも失敗する	そのサービスがお客様のドメイン用に設定されていない	ドメイン認証を完了する
転送元経由でのみ失敗する	転送によりSPFが壊れ、DKIMが改変された	少数の失敗は残るものと考える。DKIMが存在し、本文に署名していることを確認する
サブドメインで失敗する	サブドメインに専用のレコードがない	そのサブドメイン用にSPFとDKIMを公開する

段階的に適用を強める

正当な送信元がアラインし、失敗するのが不明な送信元だけになったら、ポリシーを徐々に引き上げます。各段階で少なくとも1週間待ち、レポートを確認してから次に進んでください。

ステップ	レコード	動作
1	p=none	監視のみ。レポートを収集する
2	p=quarantine; pct=10	失敗したメールのうち10%のメッセージが迷惑メールに振り分けられる
3	p=quarantine; pct=50	失敗したメールの半分が隔離される
4	p=quarantine	失敗したメールがすべて隔離される
5	p=reject; pct=25	失敗したメールの4分の1が拒否される
6	p=reject	失敗したメールがすべて拒否される。ruaアドレスは残しておく

p=reject後も監視を続ける

• 最初は毎週確認し、その後は毎月確認します。お客様のドメインとして送信する新しいツールは、失敗として現れます。
• オンボーディングに手順を追加する:お客様のドメインとしてメールを送る新しいシステムは、稼働前に認証を行います。
• 未使用ドメインを保護する:送信に使わないドメインには、p=rejectと空のSPFレコードを公開します。
• BIMIへの準備に注意する:将来、受信箱にロゴを表示したい場合、DMARCポリシーの適用が前提条件となります。

参考資料と出典

• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• dmarc.org: DMARCの概要
• Google: DMARCの設定
• RFC 8617: The Authenticated Received Chain (ARC)
• 関連ガイド:送信ドメインの認証、大量送信者の要件。