DMARC レポートの読み方｜はじめてのメール管理者向け

DMARC（Domain-based Message Authentication, Reporting, and Conformance）の導入において、多くの管理者が最初の壁として感じるのが「レポートの読み方」です。DNS に p=none のレコードを公開した後、Google や Microsoft などから毎日届く XML 形式のファイル。これらをどう解析し、どう実務に活かすべきか、具体的な手順を解説します。

DMARC レポートとは何か：管理者が向き合うべき「通信の通知表」

DMARC レポートは、あなたのドメインを送信元と称してメールを送ったサーバーが、どの IP アドレスから、どの程度の頻度で、SPF（Sender Policy Framework）や DKIM（DomainKeys Identified Mail）の認証を通過したかを集計したものです。

なぜ XML 形式なのか？

DMARC レポートは人間が読むことではなく、プログラムで処理することを前提としているため XML 形式で生成されます。1通のメールごとに送られるのではなく、通常は24時間単位の集計データとして届きます。このため、エディタで直接開くと非常に難解なコードの羅列に見えますが、構造さえ理解すれば、自社のメール運用状況を完璧に把握できる「通知表」となります。

RUA（集計レポート）と RUF（失敗レポート）の違い

DMARC レポートには大きく分けて2種類あります。実務で主に扱うのは RUA（Aggregate Report） です。

• RUA (Aggregate Reports): 送信ドメイン認証の統計データ。どの IP から何通送られ、認証が成功したか失敗したかの集計が含まれます。
• RUF (Failure/Forensic Reports): 認証に失敗した個別のメールに関する詳細レポート。ただし、プライバシーの観点から現在、主要な受信側プロバイダ（Google 等）はこのレポートの送信を控える傾向にあります。

2024年以降、レポート確認が「必須」になった背景

2024年2月、Google や 米国 Yahoo! が発表した「メール送信者のガイドライン」により、大量送信者（1日5,000通以上）に対して DMARC の導入が義務化されました。単にレコードを設定するだけでなく、認証失敗を確認して適切なポリシー（隔離や拒否）へ移行することが、ドメインの信頼性を維持するために不可欠となっています。

XML 構造を解剖する：主要タグの意味と読み方

XML ファイルをテキストエディタで開いた際、特に注目すべきタグとその意味を整理します。

1. <report_metadata>：レポートの送信元情報

誰がこのレポートを作成したかを示します。org_name が https://www.google.com/search?q=google.com であれば Google が、https://www.google.com/search?q=messaging.microsoft.com であれば Microsoft が受信・集計したデータであることを意味します。

2. <policy_published>：自社の公開ポリシー

メール受信時に適用されていたあなたのドメインの DMARC レポート設定です。

• p: 適用ポリシー（none / quarantine / reject）
• adkim / aspf: アライメントのモード（r: relaxed / s: strict）

3. <record>：最も重要な送信実績データ

ここが解析の核心部です。1つの <record> ブロックが、特定の送信条件（送信元 IP や認証結果の組み合わせ）を表します。

• <row> > <source_ip>: メールを送信したサーバーの IP アドレス。
• <row> > <count>: その IP から送信されたメールの通数。
• <policy_evaluated>: 受信側が DMARC ポリシーをどう適用したか。
  • disposition: 最終的な処理（none: 通過、quarantine: 隔離、reject: 拒否）。
  • dkim / spf: それぞれの認証結果（pass / fail）。
• <auth_results>: SPF/DKIM の詳細な認証ステータス。アライメント（送信者ドメインの一致）を確認するために重要です。

実務で使える DMARC レポート解析ツール比較

XML をそのまま読むのは非効率です。実務では以下のツールを用いて可視化するのが一般的です。

特に自社でデータ基盤を保有している場合、DMARC レポートをデータレイクに蓄積し、他のセキュリティログと統合分析するアプローチは非常に有効です。例えば、社内のあらゆる SaaS コストや利用状況を可視化する取り組みの一環として、DMARC レポートから「未承認のメール配信ツール（シャドーIT）」を発見することも可能です。

このようなデータ連携の考え方は、バックオフィス全体の最適化にも通じます。
SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付） の記事で解説しているような、不要なツールの「剥がし方」を検討する際の有力なエビデンスにもなり得ます。

【実践】レポートから「設定ミス」と「なりすまし」を見分ける手順

レポートを解析ツールに読み込ませたら、以下のステップで現状を確認します。

ステップ1：送信件数（count）の多い IP アドレスを特定する

まず、大量にメールを送っている IP アドレスを抽出します。自社の Google Workspace サーバーや、利用している MA ツール（Salesforce, Hubspot 等）の IP であれば問題ありません。一方で、全く身に覚えのない海外の IP から大量に送信されている場合、それはなりすましの攻撃である可能性が高いです。

ステップ2：IP アドレスから送信元サービスを逆引きする

IP アドレスだけでは判別がつかない場合、コマンドプロンプトやターミナルで nslookup [IPアドレス] を実行し、PTR レコードを確認します。例えば、***https://www.google.com/search?q=.outbound.protection.outlook.com であれば Microsoft 365 からの送信であることが分かります。

ステップ3：SPF fail かつ DKIM fail の原因を調査する

DMARC 認証が失敗（fail）している場合、以下の2パターンを疑います。

• 正当な送信元だが設定が漏れている: 新しく導入した SaaS や、部署単位で契約したメルマガ配信ツールが SPF レコードに含まれていない、あるいは DKIM 署名が有効になっていないケースです。
• メールの転送が発生している: 受信者がメールを他の中継サーバーへ転送すると、SPF 認証はほぼ確実に失敗します。このため、DKIM 署名が正しく行われていることが DMARC 通過の生命線となります。

特に CRM や SFA から自動送信されるメールは、設定ミスが起きやすいポイントです。
【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』 を参考に、自社のシステム構成図と照らし合わせながら、どのツールがどのドメインでメールを投げているかを整理することをお勧めします。

ステップ4：アライメント（Alignment）エラーの解消方法

SPF も DKIM も単体では「Pass」しているのに、DMARC が「Fail」になることがあります。これが「アライメントエラー」です。
DMARC では、メールの Header From（ユーザーに見える送信元アドレス） と、Envelope From（SPF で利用するドメイン） または DKIM 署名ドメイン が一致している必要があります。外部サービスを利用する際は、このドメイン一致の設定（カスタムドメイン設定など）が正しく行われているかを確認してください。

DMARC ポリシーを「p=none」から引き上げる判断基準

いつまでも p=none（監視モード）のままでは、なりすましメールを防ぐことはできません。しかし、性急に p=reject へ変更すると、必要なビジネスメールが届かなくなるリスクがあります。

認証成功率 99% 以上の達成を目指す

目安として、全送信通数のうち、正当な業務メール（自社運用ツールからの送信）の DMARC 認証成功率が 99% 以上 に達したタイミングでポリシー強化を検討します。残り 1% 未満が「転送による失敗」や「正体不明の IP からの攻撃」であれば、ポリシーを引き上げても業務への影響は軽微です。

隔離（quarantine）をテスト導入する期間の目安

いきなり拒否（reject）にするのではなく、まずは p=quarantine; pct=10; （10% の失敗メールを隔離）のように、影響範囲を限定して開始します。2週間から1ヶ月程度この状態でレポートを監視し、不達のクレームが発生しないかを確認します。

こうしたセキュリティ基盤の整備は、単独の課題解決に留まりません。社内の ID 管理や SaaS 統制が取れていることが前提となります。
SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ で解説しているような、統合的な ID 管理体制を整えることで、メール送信元の把握（どの部門がどのツールを使っているか）もより容易になります。

よくあるトラブルと FAQ

Q：レポートが届かない場合のチェックリストは？

• DNS レコードの rua=mailto:***@https://www.google.com/search?q=example.com の記述が正しいか確認してください。
• 自社ドメイン以外のメールアドレス（例：解析サービスの受信用アドレス）にレポートを送る場合、送信先のドメイン側で「レポート受け入れ」を許可する DNS レコード（External Domain Verification）が必要です。

Q：特定の受信先（キャリアメール等）だけ認証が失敗する

日本の携帯キャリアメールの中継サーバーや、古い企業用ゲートウェイでは、DKIM 署名を壊したり、SPF チェックの挙動が特殊だったりする場合があります。レポートを精査し、その受信先が自社にとってどの程度重要かを判断基準に含めてください。

Q：サードパーティ製ツールの DKIM 設定ミスはどう見つける？

レポート内の <auth_results> ブロックを確認し、dkim タグの domain が自社ドメイン（あるいはサービス提供元ドメイン）になっているか、かつ result が pass になっているかをチェックします。もし fail や none になっている場合は、そのツールの管理画面で DKIM 設定（通常は CNAME レコードの追加）が完了しているか再確認が必要です。

まとめ：DMARC レポートは「守り」の資産

DMARC レポートは、単なるエラーログではなく、自社ドメインのブランド価値を守るための「資産」です。毎日届く XML ファイルを可視化し、認証状況を 1% ずつ改善していくプロセスこそが、フィッシング詐欺から顧客を守り、メール到達率を最大化する唯一の道です。

まずは解析ツールを導入し、現在自社ドメインがどこで、どのように使われているかを可視化することから始めてください。その一歩が、企業の信頼性を支える強固なコミュニケーション基盤の構築へと繋がります。