自社ブランドをなりすましから守るDMARC ポリシー”reject”の運用

　DMARCポリシーを段階的に引き上げ、p=rejectでの運用を行うまでの手順を、本連載第2回で解説しました。p=none運用時やポリシーの引き上げ後も、引き続き集計レポート（Aggregate Report, RUA）を受け取ることができます。このレポートを読み解くことで、自社ドメインから送信されたメールがどのIPアドレスから送られ、SPFやDKIMにPASS（合格）したかFAIL（失敗）したか、といった情報を把握できます。

　今回は、レポートの内容と見方について詳細に説明します。

DMARC集計レポート（XML形式）の一例（Googleより送信されたレポート）

　上図はDMARCレポートのXML例です。メール受信サービス（ここではGoogle）がレポート送信者（org_name）となり、対象ドメイン（<policy_published>内のdomain）や適用ポリシー（p）、集計期間（date_range）などのメタデータが示されています。

　その下の<record>セクションに、送信元IPアドレスごとの集計結果が記録されています。例では、送信元IPアドレス192.0.2.0から12通のメールが送信され、dkim=passかつspf=passであったことが分かります。<policy_evaluated>のdispositionはnoneとなっていますが、これは「受信側で特別な処置をしなかった」ことを意味します（このドメインはp=quarantineだったものの、認証がPASS（合格）だったため通常配信されたことを示す）。

　一方、もし認証がFAIL（不合格）だった場合は、dkimやspfの値がfailとなり、適用されたdispositionがポリシーに応じてquarantineやrejectと記録されます。各レコードにはメールのヘッダFromドメイン（<header_from>）も記載されており、どのドメインのメールについての結果か確認できます。

　レポートを読むポイントは、自社の正規メール送信が全てpassになっているか、逆にfailになっている送信元がどこかを把握することです。

　前回の手順で正規送信元の対応を済ませていれば、残るfailは基本的に不審な送信だけになっていくはずです。なお、レポートはXML形式で読みづらいため、必要に応じて専門のツールやサービス（DMARC解析ツール、Excelやスクリプトでの解析など）を使って可視化するとよいでしょう。レポート内容はドメイン管理者にとってDMARC運用を調整するための重要な情報であり、仮に正当なメールが誤って拒否された場合に備えて原因を分析する助けにもなります。

確認すべき重要ポイント

• 対象期間（<date_range>）
  beginとendはUnix時間（UTC基準）で表記される。
• 送信元IPと正規サービスの突合
  <record><row><source_ip>が自社や利用サービスの正規IPか確認。
  不明なIPはなりすましの可能性がある。
• SPF/DKIMの認証と最終評価の違い
  <auth_results>：実際の認証検証結果（どのドメインでpass/failしたか）。
  <policy_evaluated>：DMARCルールに基づいた最終評価（Fromドメインとの整合性を加味）。
  正規メールが最終的にfailしていないかを重点的に確認する。

メールヘッダ上での認証結果の確認

　個々のメールについて、受信メールのヘッダ情報からSPF・DKIM・DMARCの結果を確認することも可能です。多くのメールクライアント（Gmailなど）では「メールのソースを表示（表示オプション内 Show originalなど）」機能があり、そこに受信サーバーが付加した認証結果を含むヘッダ全文が表示されます。ヘッダ内の「Authentication-Results」行に注目すると、spf=pass/dkim=pass/dmarc=passといった結果が記載されています。

Gmailのメールヘッダ例（SPF・DKIM・DMARC全て認証に合格したケース）

　上記ヘッダ例（GmailのAuthentication-Results）では、dkim=pass、spf=pass、に続けて、次のように記述されています。

　これはヘッダFromドメインでDMARCにPASS（合格）したことを示します。言い換えれば、このメールはSPFおよびDKIMが正常に検証・整合し、受信側は送信ドメインが本物であると確認できたということです。

　もしDMARCがFAIL（不合格）であれば、同じ箇所にdmarc=failと表示され、受信側でそのメールが隔離あるいは拒否された可能性が高いと判断できます。

　このようにメールヘッダを直接調べる方法は、設定変更後の挙動をスポットチェックしたい場合に有用です。例えば新しくDKIMを有効化した後に自分宛てにテストメールを送り、ヘッダ上でDKIM=passになっているか確認するといった使い方ができます。ただし大量のメールの傾向をつかむには先述の集計レポートの方が便利なので、ヘッダ確認は個別検証・トラブルシューティング用と位置付けるとよいでしょう。

トラブルシューティングのヒント

　DMARC導入・ポリシー強化の過程で直面しがちな問題と対策をまとめます。

まとめ：安全な導入のための推奨手順とスケジュール

　DMARC導入とポリシー強化は、適切に段階を踏めばリスクなく実施可能です。

　GMOブランドセキュリティの社内導入およびGMOインターネットグループ約50社への展開支援の経験からも、慎重なアプローチにより正規メールが拒否されるトラブルは発生しませんでした。

　特にp=noneでの監視期間を設けることで、事前に問題を洗い出し設定を修正できたことが成功のポイントです。

　推奨スケジュール
企業規模にもよりますが、DMARCポリシー”none”で最低2～4週間程度はレポートを収集・分析する段階を設けることをおすすめします。

　その後、問題が解消したら”quarantine”で数週間運用テストを行い、最終的に”reject”へ移行します。

　例えば中小規模のドメインであれば、概ね1～2カ月内にrejectまで到達できるケースもあります。一方、大規模組織では関係部署との調整も必要なため3～6カ月程度かけ段階的に進める方が安心でしょう。
重要なのは、レポートを確認しながら慎重に進める姿勢です。レポート監視により、社内ヒアリングだけでは把握できない送信元も発見できるため、このプロセスを省略することはお勧めしません。

連載のまとめ

　最後に、DMARC導入を完了しp=rejectまで引き上げた暁には、ぜひ企業ロゴ付きメール（BIMI）表示などのメリットを活用しましょう。受信者の受け取るメールに自社の認証済みブランドロゴが表示されることで、メールの開封率向上やフィッシング対策の周知にもつながります。DMARCの段階的導入は、メールセキュリティ強化とブランド価値向上を両立する「リスクゼロの手段」です。

　自社ドメインを守るため、本ガイドの手順に沿ってDMARCポリシーの引き上げをぜひ検討してください。