DMARC レポート: 読み方と設定の確認

DMARC レポートは、ドメインの観測された送信元、SPF と DKIM の認証やアライメント、受信側が報告した処理を示します。偽装の疑いやプロバイダーの設定ミスを調べるのに役立ちますが、参加する受信側のデータに限られます。完全な送信元一覧や、制限の適用にリスクがないことを証明するものではありません。

DMARC を公開して rua= をメールボックスに向けても、XML を見なければ設定ミスが残る場合があります。基本は小規模企業のビジネスメールと独自ドメインのメール作成をご覧ください。その後、レポートを送信システムの台帳を補う資料として使います。全トラフィックを記録するものではありません。

レポートを集め、正規送信元を特定し、認証とアライメントを直します。DKIM が成功しても、転送経路を確認してから問題がないか判断します。十分なデータとテストを得て、段階的にポリシーを変更しましょう。

DMARC レポートとは

参加する受信側が、ドメインを From に使うメールを検証した後で送る情報です。認証結果、アライメント、送信元 IP、ポリシー処理を含み、安全性や配信の調査に役立ちます。ただし全受信側を網羅しません。

主に二種類あります。

集計レポートは rua タグで要求し、通常は XML の要約として届きます。受信側、送信元 IP、認証結果、処理などで分類され、Google Workspace、Microsoft 365、SendGrid、Mailchimp、アプリサーバー、不明な送信元を調べられます。

失敗レポートは ruf で要求し、認証失敗の個別メール情報を含む場合があります。送信条件は設定に依存し、最終的な DMARC 失敗だけに限定されません。プライバシーなどの理由で対応は限定的です。全体の基盤ではなく追加情報として使います。

運用では次の確認に役立ちます。

どの送信元がドメインを使っていると観測されたか。
そのメールは SPF または DKIM が成功しアライメントを満たすか。
どのメールが受信側で隔離や拒否の対象になったか。
p=quarantine や p=reject で正規の処理に影響が出る可能性はあるか。

DMARC レポートを要求する仕組み

_dmarc.yourdomain.com に TXT を公開し、ポリシーと集計や失敗レポートの送信先を指定します。参加する受信側はそこにデータを送れます。外部のレポート用ドメインでは、DNS による追加の許可が必要な場合があります。

次は任意の厳格アライメントを含む監視設定の例です。

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

DMARC による制限は求めず監視し、集計レポートを dmarc@example.com に要求します。adkim=s と aspf=s は対応するアライメントで完全に同じドメインを要求します。厳格設定は任意で、既定は組織ドメインによる緩和アライメントです。実際の送信元に合わせて選びます。

主なタグです。

v=DMARC1: 必須のバージョン。
p=: DMARC 失敗時に求める処理。
rua=: 集計レポートの送信先。
ruf=: 対応する失敗レポートの送信先。
pct=: DMARC 失敗メールに求める制限の適用割合。受信側の処理は異なる場合があります。
adkim と aspf: DKIM と SPF のアライメント方式。

書式とポリシーのロジックは RFC 7489 にあります。元のレポートは圧縮 XML の添付で届くことが多く、読みやすい形への整理が必要です。

集計 DMARC レポートの項目を理解する

報告組織、送信元 IP、件数、認証、処理が記録されます。元の認証と DMARC 評価は区別してください。auth_results は SPF と DKIM の検証結果、policy_evaluated はアライメントを含む DMARC 向けの評価を示します。

通常含まれる項目です。

Google や Microsoft など、レポートを作成した受信側。
観測期間。
メールを送った送信元 IP。
その送信元で観測された件数。
SPF の検証結果。
DKIM の検証結果。
表示上の From とアライメントを含む SPF 評価。
表示上の From とアライメントを含む DKIM 評価。
DMARC 処理: none、quarantine、reject。

SPF 失敗がすべて基本設定の問題とは限りません。転送で送信 IP が変われば SPF は失敗する場合がありますが、DKIM が成功しアライメントを満たせば DMARC は成功します。

受信側: gmail.com
送信元 IP: 198.51.100.24
件数: 842
ヘッダー From: example.com
SPF: fail
DKIM: pass
DMARC: pass
処理: none

正常な転送に対応する結果かもしれませんが、送信元と経路を確かめます。認証成功は内容の安全性や送信意図の正当性を証明しません。

受信側: outlook.com
送信元 IP: 203.0.113.77
件数: 314
ヘッダー From: example.com
SPF: fail
DKIM: fail
DMARC: fail
処理: quarantine

こちらは調査が必要です。送信元の設定不足、新サービスの未設定、転送中の変更、なりすましなどが考えられ、結果だけで原因を確定できません。

集計レポートと失敗レポートを比べる

集計レポートは参加する受信側が見たトラフィックを広く示し、失敗レポートは個別の情報を含む場合があります。集計データが主な基盤になりますが、それだけでポリシー変更のリスクがないと判断できません。

種類	要求タグ	内容	用途	2025-2026 年の実情
集計	`rua=mailto:...`	多くは日次の送信元、認証、処理の XML 要約	送信元台帳、アライメント、ポリシー導入	重要ですが完全ではないデータ
失敗 / フォレンジック	`ruf=mailto:...`	個別の失敗情報、一部削除や伏せ字の場合もある	特定の失敗や悪用の調査	対応が限られ、少数か未送信の受信側もある

違いを説明できる分析ツールを選びます。重要なのは、データから具体的な確認や改善につなげられることです。

DMARC レポートを効率的に読む

件数の多い送信元を先に業務システムへ対応付けます。主要なエラーを直しながら、制限前には低頻度でも重要な処理を見落とさないようにします。

手順の例です。

集計レポートの大きな送信元から始める。
Google Workspace、Microsoft 365、マーケティング、アプリ、ヘルプデスク、不明な送信元へ対応付ける。
表示上の From に対し、SPF または DKIM が成功しアライメントを満たすか確認する。
正規の送信元の失敗をポリシー変更前に直す。
不明な送信元を調査する。共有リレーや転送は悪用の証拠ではありません。

大きな送信元から直すと進めやすくなりますが、件数が少なくても業務上重要な場合があります。まれなメールは個別にテストします。

観測結果	考えられる原因	次の対応
SPF pass、DKIM pass、DMARC pass	認証とアライメントが成功	記録し、正規の送信元か別に確認
SPF fail、DKIM pass、DMARC pass	転送または SPF 経路の問題	DKIM アライメントと署名維持を繰り返し確認
SPF pass、DKIM fail、DMARC pass	SPF はアライメントを満たすが DKIM に問題	特に転送に備え DKIM を修正
SPF fail、DKIM fail、DMARC fail	偽装、サービス設定不足、メール変更	送信元と経路を調査
不明な IP から相当数の送信	未登録サービス、共有リレー、転送、悪用	送信元を特定してから制限を検討

一般的な修正です。

正規の送信元に必要な SPF include を追加。
実際の送信プロバイダーで DKIM を有効にする。
カスタム Return-Path で SPF アライメントを設定。
必要に応じサービスを別のサブドメインへ移す。
SPF だけに頼らず、転送を調査して直す。

DNS 照会は調査を補いますが、実際のメール検証の代わりではありません。

dig TXT _dmarc.example.com +short
dig TXT example.com +short
dig TXT selector1._domainkey.example.com +short

DNS の不明点は TrekMail の必要な DNS レコードと迷惑メールのトラブルシューティングも参考になります。

DMARC レポートで分かる典型的な問題

未完成のサービス認証、アライメント、転送の変更、設定後の分析不足などが分かる場合があります。運用上の不足を具体的に調べる資料です。

新しいツールでドメインから送信を始めても、SPF や DKIM が未設定の場合があります。不明な IP が手掛かりになりますが、実際のサービスに対応するか確認が必要です。

エンベロープドメインで SPF が成功しても、アライメントがなく、成功したアライメント付き DKIM もなければ DMARC は失敗します。適切なカスタムバウンスドメインのないマーケティングやチケットシステムで起こる場合があります。

SPF だけへの依存は転送に弱い構成です。成功したアライメント付き DKIM がなければ DMARC は失敗する場合があります。メール転送の設定と修正を読み、実際の経路をテストしてください。

p=none を公開してもレポートを読まなければ、運用上の改善にはつながりにくくなります。収集だけではエラーを直せません。

早すぎる p=reject は正規の業務に影響する場合があります。送信元を把握し、重要な経路とまれな処理を確認し、障害対応を計画します。

TrekMail が支援する部分

レポートは具体的な修正ができて初めて役立ちます。TrekMail はドメイン、DNS、送信設定の共同管理を支援できますが、外部送信元とアライメントの確認は必要です。

複数ホスト、別々の SMTP、共有レポートメールボックスでは、新しい送信元を追加するたびに調整が増えます。

TrekMail の共通画面は、複数ドメインのホスティング、DNS 確認、持ち込みか管理型の SMTP、メールボックス操作、転送、移行を扱えます。利用できる機能はプランと設定に依存します。顧客環境では複数ドメインのメールホスティングが参考になります。

TrekMail はプランに応じて独自ドメイン、IMAP メールボックス、キャッチオール、転送、サーバー側 IMAP 移行、API、DNS 確認を提供します。Nano は持ち込み SMTPの手順で設定できます。対象の有料プランには管理型 SMTP があり、Starter の価格目安は月額 $3.50 からです。Nano は無料でカード不要の選択肢として案内されています。有料プランは 14 日間の試用を提供する場合があり、クレジットカードが必要です。最新の条件を確認してください。

レポート自体は設定を自動修正しません。共通画面で一部の作業を簡単にできても、原因調査は省けません。

p=none から Quarantine や Reject に移る時期

レポートは判断材料であり、完全な安全性の証明ではありません。台帳と実際のテストで正規の送信元を確認します。不明な失敗を、調査せず悪意や無関係なものと扱わないでください。

次のレコードは各段階の代替例で、同時に公開するものではありません。

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"

複数のレポート周期と、まれでも重要なメールを確認します。認証成功とアライメント、転送での署名対象データ維持を検証します。割合指定は受信側で扱いが異なり、処理はローカルポリシーにも依存します。

Google は個人用 Gmail への通常の直接送信元に SPF または DKIM を要求します。一括送信者には SPF と DKIM、および少なくとも一つの成功経路でアライメントを満たす DMARC が必要です。受信側の説明はGmail 送信者ガイドライン FAQをご覧ください。