DMARC レポートの読み方と分析

DMARC を設定すると、Google、Microsoft、Yahoo などから XML 添付が届く場合があります。そこで気になるのが、DMARC レポートと仕組み自体の違いです。

DMARC はドメイン認証、ポリシー、報告のプロトコルです。DNS レコードはその設定を公開します。一方、レポートは対応する受信側によるメール検証後の観測結果です。設定と実際の報告は同じではありません。

構築中なら独自ドメインメールの作成が参考になります。転送で認証が崩れる場合はドメインメールの Gmail 転送も確認してください。ここでは設定後のレポート分析を説明します。

XML は最初は分かりにくく感じられます。公開後すぐ届く場合もありますが、翌日や全受信側からの報告は保証されません。レコード、ポリシー、宛先、失敗データを混同すると、原因が分からないまま DNS を変更してしまいます。

以下にレポートとレコードの違い、主要フィールドの意味を整理します。転送、構成不備、悪用の可能性を分けるには追加の確認が必要です。

DMARC レポートとは

受信メールシステムが設定された宛先へ送るフィードバックです。集計レポートは観測したメールの SPF、DKIM、アライメント、ポリシー処理をまとめますが、全メールを網羅しません。

レポート自体はポリシーではありません。対応する受信側が自社の From を使うメールを検証し、rua に集計を送れます。RFC 7489 は認証結果、修正、ポリシーの影響を理解する集計フィードバックを定義しています。提供は任意です。

DMARC レポートと DNS レコード

プロトコルは公開した DNS 設定を利用し、レポートは個々の受信側が実際のメールで観測した結果を示します。

項目	内容	場所	役割
DMARC レコード	`_dmarc.yourdomain.com` の TXT	自社の DNS	ポリシー、アライメント、レポート宛先を公開する
DMARC レポート	通常は集計 XML	レポート受信箱や分析サービス	観測した送信元、認証、処理を示す
DMARC ポリシー	`p=none`、`quarantine`、`reject`	DMARC レコード内	DMARC 失敗時の処理を要求する
RUA アドレス	`rua=mailto:dmarc@example.com` など	DMARC レコード内	要求する集計レポートの宛先を指定する

修正方法は原因次第です。不適切なレコードは意図したポリシーの処理を妨げます。DNS が正しくても、正規送信の構成不備、転送、未許可の送信などで失敗し得ます。

レポートに含まれる情報

集計は送信元と結果でメッセージを分類します。重要なのは IP、件数、SPF、DKIM、アライメント、報告された処理です。

XML では auth_results の元の認証結果と、policy_evaluated のアライメントを考慮した SPF、DKIM を区別します。少なくとも一方が成功して From に対応すれば DMARC は成功します。Disposition は処理の報告で、単独の認証成功証明ではありません。

SPF 失敗がひとつあっても全メールの障害とは限りません。DKIM が成功してアライメントを満たせば DMARC は成功できます。

次の順で確認しましょう。

送信元 IP と報告する組織を確認する。
件数を判断する。一通と 20,000 通は異なる調査になるが、一通でも重要な場合がある。
Disposition の none、quarantine、reject を確認する。None は DMARC 成功の証拠ではなく、必ずしも監視ポリシーを意味しない。
XML の該当部分を考慮して SPF と DKIM を合わせて読む。
実際の From とのアライメントを確認する。

集計レポートと個別の失敗レポート

通常は rua で要求する集計を指します。ruf の失敗レポートは個別メールに関わることがあり、対応が限定的で機微な情報を含み得ます。

種類	タグ	形式	用途	2025-2026 年の状況
集計	`rua`	XML の概要	継続監視と送信元一覧の照合	利用できる場合が多いが、範囲と周期は異なる
個別の失敗	`ruf`	個別メールの失敗サンプル	特定の問題の調査	対応が不統一でプライバシーの制限がある

集計の監視には管理する rua 宛先が適しています。アクセスを制限し、外部宛先の DNS 承認も確認します。Google の送信者ガイドラインは適用される認証要件と制限を説明します。レポートは運用確認を補い、実メールのテストを置き換えません。

レポート宛先のあるレコードを公開する

_dmarc に TXT を公開し、適切なポリシーと管理する宛先を設定します。未検証の送信では、制限要求の前に監視から始められます。

次の例は任意の厳密アライメントを使い、全環境で安全な初期設定ではありません。厳密では完全一致、緩和では組織ドメインの一致を確認します。

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

次の代替例はすでに制限を要求します。一覧、ログ、低頻度の重要な処理をテストしてから、以前のレコードを置き換えます。

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

残る失敗を確認してから Reject を検討できます。問題の見えないレポートだけでは全送信元の確認にならず、問題があれば戻せる変更計画も必要です。

公開した DNS 値は検索できます。

dig TXT _dmarc.example.com +short

TrekMail のウィザードは必要な MX、SPF、DKIM、DMARC を示し、DNS の競合を見つける助けになります。全経路が自動的に検証されるわけではありません。ドメインの追加とメールが迷惑メールに入る場合の資料は実メールのテストを補います。

早急に結論を出さずに読む

予想される転送変化と未知の送信元を追加情報で確認します。知らない基盤だからといって自動的になりすましとは言えません。

報告内容	考えられる原因	確認
SPF fail, DKIM pass, DMARC pass	転送や中継	有効で対応する署名と実際の経路を確認する
提供元 IP の SPF fail, DKIM fail, DMARC fail	許可、署名、転送の問題	実際のエンベロープ、DKIM、Return-Path を確認する
未知の海外 IP から両方失敗	悪用、共有基盤、正規の転送などがあり得る	一覧とログを照合し、無条件に許可や遮断をしない
自社アプリサーバーの大量失敗	忘れた経路や構成不備	システムを特定して適切な認証をテストする

レポートは頻度と受信処理の手掛かりです。処理は信頼の判断ではなく、すべての受信側が同じようにポリシーを適用した証明にもなりません。

転送でデータが分かりにくくなる理由

転送先が見るのは転送サーバーの IP なので、元は正規のメールでも SPF が失敗し得ます。

一般のメールサービスや ISP の中継 IP を推測で SPF に追加しないでください。SPF は実際のエンベロープドメインの許可を確認します。DKIM は署名が有効でアライメントを満たし、署名対象が正規化規則のもとで保たれれば助けになります。

SRS は書き換えたエンベロープの SPF を助けますが、元の From との対応を自動的に復元しません。ARC はローカルな例外を助け得ますが、DMARC fail を pass に変えません。メール転送の設定と修正も参考になります。

DNS 変更が必要と判断する場面

正規送信元と実際の原因を特定してから変更します。単独の報告結果だけでは修正内容は決まりません。

具体的な確認例です。

実際のエンベロープドメインの SPF が利用中の送信提供元を許可していない。
DKIM が From に対応せず、他に成功して対応する認証もない。
アプリが現在の構成と合わない古い SMTP 経路を使っている。
レコードに rua がない、構文が無効、またはポリシーが検証済みの送信状態に合わない。

Gmail や Outlook の転送 IP の SPF 失敗だけでは、その IP を許可する理由になりません。

共通の画面はレジストラー、XML、五つの外部送信サービスの整理に役立ちます。TrekMail はプランに応じてドメイン、DNS、メールボックス、移行、独自または管理された SMTP をまとめられます。IMAP と SMTP の設定はクライアントテスト、マルチドメインメールホスティングは管理モデルの参考です。DNS 状態は全送信の検証を代替しません。

すべて手作業で読むべきか

小規模なら最初は手動分析が可能です。規模が増えたら分析ツールと管理する宛先を使い、アクセスとプライバシーも確認します。

ひとつのドメインと少数の送信元なら導入中に手動で読めます。十ドメインでは作業が増え、五十ならさらに負担になります。分析ツールと記録した送信経路で整理できますが、毎日の完全な報告は保証されません。

想定される結果には成功して対応する送信元、転送変化、報告された制限があります。ただし全経路の網羅や、失敗がすべて悪用だったことは証明しません。

レポート分析の運用手順

公開、監視、一覧の照合、アライメント修正、テスト後の制限検討という順序です。レポートは情報源であり、導入を決める唯一の基準ではありません。

p=none と管理する宛先を公開する。ローカルフィルターは残る。
数日間、利用できるレポートを集める。全受信側の提供は期待せず、低頻度の処理も別にテストする。
失敗を既知の正規送信、転送変化、未確認の悪用の可能性として調べる。
正規の構成を修正し、転送は有効で対応する DKIM で検証する。無条件に無視しない。
一覧、ログ、重要なテスト後に quarantine、次に reject を検討し、単一ポリシーを置き換える。

新ツールは適切な SPF、DKIM、Return-Path が必要です。SPF は実際のエンベロープドメインで送信サーバーを許可し、入れ子の DNS を必要とするメカニズムと修飾子も評価上限に数えます。トラッキングドメインだけでは Return-Path は変わらず、提供元の有効化と実メール検証が必要です。

TrekMail と一貫した DNS 管理

TrekMail は DMARC を置き換えませんが、ドメイン管理を集約できます。DNS 公開と個別の送信検証は引き続き必要です。

プランに応じて独自ドメイン、IMAP メールボックス、キャッチオール、転送、IMAP 取り込み、独自または管理された SMTP を利用できます。代理店は共通の管理と共有容量を使えますが、リソースと機能の上限を確認します。IMAP はメールをコピーし、MX やアプリの切り替えを代替しません。

共通の管理を、ユーザー課金や分散した転送ルールと比較する際は送信元一覧も考慮します。節約は保証されません。有料プランの価格目安は月額 $3.50 からです。Nano はカード不要の無料オプションがあり、有料プランには 14 日間試用が提供されています。現在の条件は TrekMail の料金で確認してください。