DMARCレポートの読み方：XMLに溺れずに

DMARCレポートとは実際に何か

rua=のアドレスを書いたDMARCレコードを公開すると、メールプロバイダーが集約レポートを送ってきます。プロバイダーごとに1日1つのXMLファイルで、あなたのドメインを名乗って送信したすべてのIP、それぞれが何通送ったか、SPFとDKIMが通ってアラインしていたかが並んでいます。

開く前に知っておくとよいことが2つあります。

• 集約レポートにメールの中身は入っていません。件名も宛先も本文もなし。送信元IPごとに集計した件数です。だから安全に集められますし、だからどのメールが失敗したのかは分かりません。
• フォレンジックレポートとは別物です。ruf=のアドレスはメール単位の失敗サンプルを求めるもので、ヘッダーやそれ以上が含まれます。プライバシー上の理由で、いまはほとんどのプロバイダーが送っていません。つまり実務上、DMARCの可視性とは集約レポートのことです。

これが与えてくれるのは、ほかの手段では得られない唯一のものです。世界中であなたのドメインを名乗って送信しているすべてのものの一覧——誰も設定を覚えていない社内のシステムも含めて。この棚卸しこそが目的のすべてで、これがあるから強制ポリシーへ安全に進めます。

まずレポートを受け取る

データを集めるだけで、配送には何も影響しない最小のレコードはこれです。

v=DMARC1; p=none; rua=mailto:dmarc@example.com

_dmarc.example.comにTXTレコードとして置きます。p=noneは「ポリシーは適用しない、知らせるだけ」という意味で、正しい出発点であり、配送を損なうことはありません。届かないレポートを待ち続ける前に、レコードが本当に公開され読める状態かをDNSクエリツールで確認してください。

実務的な注意が2つ。レポートは毎日まとまった数が届くので、自分の受信箱ではなく専用のメールボックスに送ってください。そして別ドメインのアドレスで受け取りたい場合、そのドメイン側が自分のDNSレコードで許可する必要があります——この許可の欠落が、レポートがいつまでも届かない最も多い原因です。

XMLを読む：3つのブロック

どの集約レポートも形は同じです。一度見てしまえば、もう身構える必要はありません。

ブロック1：誰が送ったレポートか

<report_metadata>には報告元の組織名、レポートID、対象期間が入ります。注目すべきは期間です。レポートはたいてい24時間分で、1〜2日遅れて届きます。つまり見ているIPが送信したのは過去のことです。

ブロック2：相手が見たポリシー

<policy_published>は、そのプロバイダーが読んだあなた自身のDMARCレコードです。p（ポリシー）、sp（サブドメイン用）、pct（適用を求めた割合）、そしてアラインメントの方式。ここは点検に使えます。公開したつもりの内容と食い違っていれば、レコードに文法上の問題があるか、まだ伝わっていないということです。

ブロック3：本題の行

続いて<record>要素が並びます。それぞれは1つのIPから同じ結果になったメールのグループであって、1通のメールではありません。中には送信元IPと件数を持つ<row>、DMARCの結果とプロバイダーが実際にどうしたかを示す<policy_evaluated>、その下のSPFとDKIMの結果を持つ<auth_results>があります。

1行を実際に読む

この順にたどれば、行は自分で答えてくれます。

1. そのIPは誰のものか。調べてください。見覚えのあるメール配信基盤の名前なら自社のサービス、知らないネットワークなら調査対象です。
2. 何通か。2通ならノイズ。2万通ならシステムです。
3. <policy_evaluated><disposition>は何と言っているか。none、quarantine、reject——プロバイダーが何をしたか。
4. SPFとDKIMは通ったか、そしてアラインしていたか。この組み合わせが診断のすべてで、次の節の内容です。

4つの組み合わせと、その意味

DMARCは、SPFかDKIMのどちらかが通り、かつ見えるFrom:ドメインとアラインしていれば通ります。そこから4通り。

• SPF通過＋DKIM通過。正しく設定された自社の送信元。することはありません。
• SPF通過、DKIM失敗。たいていは、許可されたIPから署名せずに送っているサービスです。DKIM署名を有効にしてください。SPF単体は脆く、メールが転送された瞬間に壊れます。
• SPF失敗、DKIM通過。多くは正当な転送メールです。転送側のIPはあなたのSPFレコードにありませんが、署名は生き残った。DKIMだけでDMARCが通る——これは設計どおりに動いている姿です。
• 両方失敗。設定されたことのない自社の送信元か、あなたをかたる誰か。その見分け方が次の節です。

XMLの落とし穴に注意してください。<auth_results>にpassと出ていてもDMARCは失敗することがあります。認証されたドメインがFrom:ドメインとアラインしていなかった場合です。自社ドメインで署名する配信基盤がまさにこれを生みます。分かりにくければ、SPFが通ることがDMARCが通ることではない理由がアラインメントを詳しく扱っています。

自社の送信元となりすましを見分ける

最初のレポートはほぼ誰にとっても不穏に見えますが、そのほとんどは攻撃ではありません。失敗しているIPを3つの山に分けてください。

• 自社のもので、設定が誤っている。CRM、請求やチケットのシステム、マーケティング基盤、アプリケーションサーバー。手がかりは、IPが見覚えのある事業者に解決すること、件数が日ごとに安定していること、そしてメールが届いていること。対処は、きちんと許可すること——できればDKIMで。
• 転送。件数が少なく、IPが散らばっていて、大学や小さなメールホスト、SPFは失敗しDKIMは通る。問題ではありませんし、こちら側では直せません。
• 本物のなりすまし。見知らぬネットワーク、しばしば一気に、事業と無関係なことが多く、両方の検査に失敗する。安心できるのは、ポリシーを適用していればそのメールはすでに拒否されているという点です。それこそが目的なのですから。

順番が大事です。ポリシーを強める前に、1つ目の山をすべて特定してください。強制は、設定を誤った自社の送信元を「届かないメール」に変えてしまうからです。

なぜ転送が攻撃に見えるのか

これは誰もが一度は戸惑います。メーリングリストやエイリアスは自分のサーバーからあなたのメールを中継するので、あなたのSPFレコードは一度も許可していないIPに対して検査され、失敗します。正しく、です。レポートには、あなたを名乗って送信しながらSPFに失敗する見知らぬIPが並び、それはまさに不正利用のように読めます。

見分ける手がかりは2つ。転送されたメールはたいていDKIMは通ったままです。署名はメールと一緒に運ばれるからで、結果としてDMARCは通ります。そして件数は少なく、関係のない多数のIPに散らばっていて、集中しません。例外はメーリングリストで、件名を書き換えたりフッターを足したりするものがあり、それがDKIM署名を無効にして、正当なメールがすべてに失敗した状態を残します。

レポートを使って強制まで進む

レポートは、この移行を安全にするために存在します。実際に機能する順序はこうです。

• レポートが退屈になるまでp=noneのまま——ふつう数週間です。見つかった正当な送信元がすべて許可され、新しいものが現れなくなるのを待ちます。
• 見つけるそばから送信元を直す、できればDKIMで。DKIMのある送信元は転送を生き延び、SPFだけの送信元は生き延びません。
• p=quarantineへ移る。必要ならpct=で段階的に。失敗したメールは消えるのではなく迷惑メールに入るので、間違えても取り返せます。
• そのうえでp=reject。隔離が静かになってからです。ここで初めて、あなたのドメインをかたるメールが実際に拒否されます。
• その後もレポートを読み続けること。半年後に増えた新しいベンダーは失敗するIPとして現れます。請求書が戻ってきていると誰かに言われる前に、気づきたいはずです。

初日にp=rejectを設定してはいけません。強制を安全にする唯一のものはレポートが与える棚卸しであり、それが揃うには数週間かかります。レコードそのものについてはSPF・DKIM・DMARCのガイドを。

よくある失敗

• レポートを読まずにp=rejectへ飛ぶ。忘れていたシステムは、たいてい顧客に請求を出しているものです。
• 1行を1通として読む。1行は1つのIPから同じ結果になったメールのグループです。
• 失敗したIPをすべて攻撃者とみなす。初期の失敗のほとんどは自社のサービスとふつうの転送です。
• auth_resultsのpassをDMARC通過だと思い込む。From:ドメインとのアラインメントがなければ、そうではありません。
• レポートを人が見る受信箱に送る。数十の事業者から毎日届きます。専用のアドレスを使ってください。
• サブドメインのポリシーを忘れる。sp=がないとサブドメインはpを継承します。展開中はそれが望みでないこともあります。
• SPFだけ直す。SPFは転送で壊れます。そこをDMARCが越えていくのはDKIMのおかげです。
• rejectに到達したらレポートを止める。そこからが早期警戒装置としての本番です。

まとめ

DMARC集約レポートは、あなたのドメインを名乗って送信するすべてのIPを、件数とSPF/DKIMの結果とともに並べた日次のXMLです——メールの中身は入っていません。各行は4段階で読みます。IPを特定し、件数を見て、dispositionを読み、SPFかDKIMが通りかつアラインしていたかを確かめる。初期の失敗の大半はなりすましではなく、未設定の自社サービスとふつうの転送だと見込んでおき、送信元は可能なかぎりDKIMで直し、レポートが静かになってからp=noneを隔離へ、そして拒否へと進めてください。_dmarcレコードが公開され読める状態かは無料のDNSルックアップツールで確認でき、レポートのSPFの結果が矛盾して見えるときはSPFの切り分けガイドが理由を説明します。

関連ツールとガイド：

• DNS検索 — A、AAAA、MX、TXT、NS などの DNS レコードを値と TTL 付きで照会、さらに逆引き DNS も。
• SPFレコードが何度も失敗する理由と直し方 — SPFレコードの読み方、10回のDNS参照上限が静かに壊す仕組み、転送メールが失敗する理由、そして失敗するレコードの直し方を解説します

よくある質問