
DMARCレポート、放置してない?|集計レポート(rua)の読み方と分析のすすめ方
「Gmailに届かなくなると困るから、とりあえずDMARCを設定した」
ここまでは多くの会社がやっています。2024年に Gmail と Yahoo が大量送信者に DMARC を必須にし、2025年には Microsoft(Outlook.com)も続いたので、慌てて p=none で入れた人も多いはずです。
でも、そのあと毎日届く DMARC レポート、ちゃんと見ていますか?
DMARC は「設定して終わり」ではなく、レポートを見て、問題を直して、ポリシーを強くしていくところまでやって初めて意味があります。この記事では、レポートの読み方と分析のすすめ方を紹介します。
DMARCのおさらい
DMARC は、メールの From に書かれたドメインが「本物かどうか」を受信側が判定するためのしくみです。判定には SPF と DKIM を使います。
| しくみ | 何を確認するか |
|---|---|
| SPF | 送信元のIPアドレスが、そのドメインの送信サーバとして登録されているか |
| DKIM | メールに付いた電子署名が正しいか(途中で改ざんされていないか) |
| DMARC | SPF か DKIM のどちらかが合格し、しかも From のドメインと一致しているか |
ポイントは最後の「一致しているか(アライメント)」です。SPF や DKIM 自体が合格していても、それが From とは別のドメインに対する合格だと、DMARC では不合格になります。
たとえばメール配信サービスを使うと、SPF は配信サービス側のドメインで合格していて、From の自社ドメインとは一致していない…ということがよくあります。
DMARC のポリシー(p=)は3段階です。
| ポリシー | 不合格のメールをどうするか |
|---|---|
p=none |
何もしない(レポートを送ってもらうだけ) |
p=quarantine |
迷惑メールフォルダに入れる |
p=reject |
受信を拒否する |
なりすましメールを本当に止められるのは quarantine 以上です。p=none のままだと、なりすましメールもそのまま届いてしまいます。
DMARCレポート(rua)とは
DMARC レコードの rua= にメールアドレスを書いておくと、Google や Microsoft などの受信側から、1日1回程度、集計レポートが届きます。
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
レポートは zip や gzip で圧縮された XML ファイルで、中身はこんな感じです(主要な部分だけ抜粋)。
<feedback>
<report_metadata>
<org_name>google.com</org_name>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>none</p>
</policy_published>
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result></dkim>
<spf><domain>bounce.mailer.example.net</domain><result>pass</result></spf>
</auth_results>
</record>
</feedback>
レポートの読み方
<record> 1つが「この送信元IPから、このドメインを名乗るメールが何通来て、認証結果はこうだった」という1行分の集計です。見るべきところは次のとおりです。
| 項目 | 意味 |
|---|---|
source_ip / count |
どのIPから何通送られたか |
header_from |
From に書かれていたドメイン |
policy_evaluated の dkim / spf |
From と一致したうえで合格したか(DMARCとしての判定) |
auth_results |
SPF・DKIM そのものの結果と、どのドメインで検査したか |
disposition |
受信側が実際にどう扱ったか(none / quarantine / reject) |
上の例を読むと、こうなります。
- SPF は
bounce.mailer.example.netで合格しているが、From のexample.comと一致しないので、DMARC 上はspf: fail - DKIM は
example.comで署名されていて一致しているので、dkim: pass - どちらかが合格していればよいので、このメールは DMARC 合格
このように、auth_results では合格なのに policy_evaluated では不合格、というズレを見つけるのがレポート分析の基本です。
分析のすすめ方
レポートを見ながら、次の順番で進めるのがおすすめです。
- まずは
p=noneで集める:最低でも2〜4週間はレポートをためて、自社ドメインを名乗っている送信元を洗い出します - 送信元を「自社のもの」と「知らないもの」に分ける:社内のメールサーバ、Microsoft 365 や Google Workspace、メール配信サービス、基幹システムからの通知メールなど、意外なところから自社ドメインのメールが送られていることがあります
- 自社の送信元で失敗しているものを直す:
- SPF が通らない → SPF レコードに送信元を追加する
- SPF は通るがドメインが一致しない → 配信サービス側で自社ドメインでの DKIM 署名を設定する(いちばん確実)
- 知らない送信元で SPF・DKIM ともに失敗しているものは、なりすましの可能性が高いので、そのまま失敗させておいてOK
- 合格率が安定したら、ポリシーを強くする:
p=quarantineにして様子を見て、問題がなければp=rejectへ。いきなりrejectにすると、見落としていた正規メールが届かなくなるので、段階的に進めます
手で見るのは正直つらい
理屈はシンプルですが、実際にやってみると手作業ではかなり大変です。
- レポートは受信側ごとに毎日届くので、すぐに数十〜数百通たまる
- 1通ずつ zip を解凍して XML を読むのは現実的ではない
- IPアドレスだけでは、どのシステムから送られたメールかわからない
- 複数のドメインを管理していると、さらに倍々で増える
そこで、レポートを自動で集計して見やすくしてくれるツールを使うのが一般的です。有料・無料のSaaSや、Cloudflare で DNS を管理しているなら Cloudflare の DMARC Management のような選択肢もあります。
ただ、「外部のサービスにレポートを渡したくない」「自分のサーバで手軽に動かしたい」という場合もありますよね。
こういうツールもあります:DMARC ダッシュボード
筆者が自作して GitHub で公開している DMARC ダッシュボード も、選択肢のひとつとして紹介させてください。
DMARC 集計レポートのメールを取り込んで SQLite にため、ブラウザのダッシュボードで分析できるツールです。サンプルデータを表示すると、こんな画面になります。

診断と対策を画面で教えてくれる
いちばんの特徴は、ドメインごとに状況を自動で判定して、推奨アクションを出してくれるところです。たとえば次のようなものを検出します。
- SPF / DKIM は通るのにドメインが一致しない送信元(配信サービスの設定不備)
- SPF / DKIM がどちらも失敗している送信元(なりすましの疑い)
p=noneからポリシーを強くできるか、quarantineやrejectで正規メールが落ちていないか- 合格率の急落や、レポートが届かなくなったドメイン
各項目を開くと、「なぜ?」と「対策」が手順つきで表示されます。配信サービスごとの設定場所まで案内するので、メールに詳しくない担当者でも対応しやすいように作っています。

「どのシステムから送られたメールか」で見られる
送信元IPの一覧だけだと、どのシステムのメールなのかがわかりにくいですよね。このツールでは、Envelope From(Return-Path)のドメインごとに集計する「送信システム別」の表があります。
From のドメインと一致していないもの(≠ 印)がひと目でわかるので、先ほどの「SPF は通るのに DMARC では不合格」になっている送信システムをすぐに見つけられます。

推移や内訳もグラフで確認できる
日別のメッセージ数と合格率の推移、認証結果の内訳、レポーター(Google・Microsoft・Yahoo! など)別の集計もグラフで見られます。設定を直したあとに、合格率がちゃんと上がったかを確認するのに便利です。

そのほかの特徴
- Python 3.8 以上の標準ライブラリだけで動く:
pip install不要。Docker でも動かせます - レポートの取り込みが楽:IMAP でレポート用メールボックスから自動取得できるほか、画面へのドラッグ&ドロップや、フォルダの一括取り込みにも対応。
.xml.xml.gz.zip、それらが添付されたメールをそのまま読めます - 複数ドメインに対応:ドメインごとに自動で分けて集計し、並べて比較できます
- 送信元IPを逆引きして、どの送信サービス(SendGrid・Amazon SES・Google など)かを推定します
まずはサンプルデータで試せます
サンプルデータが入った状態で起動できるので、手元で雰囲気をつかむのも簡単です。
git clone https://github.com/outslider/dmarc_dashboard.git
cd dmarc_dashboard
python3 -m dmarc_dashboard demo
python3 -m dmarc_dashboard --db data/demo.sqlite3 serve
ブラウザで http://127.0.0.1:8080/ を開くと、ダッシュボードが表示されます。
本番で使うときは、レポート受信用のメールアドレスを用意して rua をそこに向け、設定ファイルに IMAP の情報を書くだけです。systemd で常駐させる設定例や、Apache でサブディレクトリに公開する設定例もリポジトリに入っています。詳しくは README を見てください。
動かすサーバはどうする?
レポートを1時間ごとに取りに行くので、常に動いているサーバが1台必要です。とはいえ、Python の標準ライブラリと SQLite だけで動く軽いツールなので、メモリ1GBクラスの小さなサーバで十分です。
- まずは無料で試したい → GCP の無料枠(e2-micro)や Oracle Cloud の無料枠
- ただし Oracle Cloud の無料アカウントは、負荷の軽いサーバだと「アイドル状態」と判定されて回収されることがあるので注意
- 業務で止まると困る → 月500円前後の国内格安VPS(IDCFクラウド・KAGOYA など)
無料枠・格安VPSの料金やスペックの違いは、こちらの記事でまとめています。
👉 無料・格安VPSサーバ比較【2026年版】|Oracle Cloud・GCP無料枠からワンコインVPSまで8社を比較
レポートを受け取るときの注意点
ツールを使う・使わないにかかわらず、レポートの受け取りでよくつまずくポイントです。
- 別ドメインのアドレスで受け取るときは、受け取る側にもDNS設定が必要:たとえば
example.comのレポートをexample.netのアドレスで受け取るなら、example.com._report._dmarc.example.netにv=DMARC1の TXT レコードを追加します - 迷惑メールフォルダに入りやすい:zip が添付されたメールなので、フィルタに引っかかることがあります。レポート専用のアドレスを作って、フィルタを無効にしておくと安心です
- メールボックスの容量に注意:毎日届くので、取り込んだ後のメールは定期的に削除しましょう
まとめ
- DMARC は、レポートを見て直して、ポリシーを強くしていくところまでがセット
- レポートでは「
auth_resultsでは合格なのに、policy_evaluatedでは不合格」というズレを探す - 正規の送信元で失敗しているものは、自社ドメインでの DKIM 署名で直すのがいちばん確実
p=none→quarantine→rejectと段階的に進める- 手作業がつらくなったら、ツールに任せる。自分のサーバで動かしたいなら DMARC ダッシュボード もどうぞ(動かすサーバは無料・格安VPSの比較記事を参考に)
p=none のまま止まっている人は、まずはレポートを1週間分ためて、眺めてみるところから始めてみてください。