DMARCレポートが届かない原因と確認方法
目次
この記事でわかること
- DMARC集計レポート（rua）が届かない代表的な4つの原因
- 外部ドメインに送信させる場合に必要な「認可レコード」の仕組みと書き方
- digコマンドと受信メールヘッダで原因を切り分ける具体手順
「設定したのに、レポートが1通も来ない」
DMARC（ディーマーク）を p=none; rua=mailto:[email protected] で設定し、翌朝メールボックスを開いたものの、Google や Microsoft からのレポートが見当たらない。設定から数日経っても状況が変わらない。こうした問い合わせは運用現場で珍しくありません。
DMARCレポートは、設定が正しくても受信側プロバイダ・DNS・メールサーバーのいずれかで条件が崩れると、簡単に止まってしまいます。本記事では、レポートが「届くべきなのに届いていない」状態を切り分け、どこを直せばよいかを判断するための材料を整理します。なお、レポートが届いた後の解析方法については、DMARCレポートの見方を先に確認しておくと役立ちます。
原因1: 外部ドメインへの送信に「認可レコード」が必要
最も多いのがこのパターンです。DMARCの仕様（RFC 7489）では、rua/ruf の送信先メールアドレスのドメインが、DMARCを設定したドメインと異なる場合、送信先ドメイン側に認可レコード（External Destination Verification）を置かないと、受信プロバイダはレポートを送信しません。
たとえば example.co.jp のDMARCに rua=mailto:[email protected] と書いた場合、example.net 側に次のTXTレコードを追加する必要があります。
example.co.jp._report._dmarc.example.net. IN TXT "v=DMARC1"
ホスト名は「<送信元ドメイン>._report._dmarc.<受信ドメイン>」、値は最低でも v=DMARC1 の1行です。これがないと Google や Microsoft はレポートを送る権限がないと判断し、無言で破棄します。
レポート受信を外部のSaaS（dmarcian、Postmarkなど）に委託しているケースもこの条件に当てはまり、各サービスのドキュメントには認可レコードの設定手順が記載されています。社内ドメイン宛（rua=mailto:[email protected]、つまり同一ドメイン）であれば、このレコードは不要です。
digコマンドで存在を確認
dig +short TXT example.co.jp._report._dmarc.example.net
"v=DMARC1" が返らなければレコードが存在しません。Cloudflare、Route 53、お名前.com など、実際にDNSを管理している事業者の管理画面で、TXTレコードを追加してください。
原因2: レポート送信元が SPF / DMARC でブロックされている
レポートは [email protected] や各社の no-reply アドレスから送られてきます。受信側のメールサーバーで以下のような設定になっていると、レポートそのものが受信前に拒否されることがあります。
- 自社で運用するメールゲートウェイで「件名にXMLを含む添付」を一律ブロック
- スパムフィルタが google.com / outlook.com からの大量メールを誤検知
- SPFやDMARCをreject運用している社内ドメインで、自分宛のメールが整合性エラーになる
特に、rua 受信用アドレスを「自社ドメインのメンバー」にしている場合、自社の厳格なDMARCポリシーが影響して受信側で拒否されているケースがあります。専用の受信用エイリアス（例: [email protected]）を作り、フィルタの除外設定を入れることで多くは解決します。
メールサーバーのログで noreply-dmarc-support を検索し、reject や spam の記録がないかを確認してください。Microsoft 365 / Google Workspace の管理画面では、メールトレーシング機能で過去2週間程度を遡って追跡できます。
原因3: 受信メールアドレスが存在しない・容量超過
単純なミスですが、運用現場で実際に起きるパターンです。
rua=mailto:[email protected]（example のスペルミス）- 退職者のメールアドレスを指定したまま、アカウントを削除した
- 共有メールボックスの容量上限に達して新規受信ができない
DMARCレコードに書いたメールアドレスへ、社内から手動で1通テストメールを送ってみると、すぐに切り分けられます。バウンスが返ってくれば原因はメールアドレス側にあります。
_dmarc レコード自体に文字化けやタイプミスがないかも、digで確認しておきましょう。
dig +short TXT _dmarc.example.co.jp
セミコロンの位置、mailto: の綴り、ダブルクォート閉じ忘れなどは、目視レビューよりも実機で取得して確認する方が確実です。
原因4: 迷惑メールフォルダに振り分けられている
Gmail や Outlook は、毎日大量に届くXML添付メールを「販促・自動通知」と判定して迷惑メール扱いにすることがあります。受信者がメインの受信トレイしか見ていないと、「届いていない」と誤認します。
- Gmail: 検索バーに
from:noreply-dmarc-supportを入力 - Outlook: 「迷惑メール」フォルダ + 「その他」タブを直接確認
- 共有メールボックス: ルール設定でフォルダ振り分けされていないかを確認
該当するメールが見つかったら「迷惑メールではない」「常に受信トレイに表示」と学習させます。さらに、送信元ドメイン（google.com、outlook.com、yahoo-inc.com など）をホワイトリストに追加しておくと安定します。
受信ヘッダで「届いた事実」を裏付ける
「迷惑メールフォルダにも何もない」場合は、本当にレポートが送られていないのか、それとも自社ゲートウェイで止まっているのかを切り分けます。
メールサーバーのログまたは管理画面のメッセージトレースで、過去48時間以内に dmarc-support 系の差出人アドレスから着信があったかを検索してください。着信記録があれば原因はフィルタ・振り分け側、なければ原因はDMARCレコードか認可レコード側、という判断ができます。
なお、レポートは送信から24〜48時間遅れて届くこともあります。設定変更の翌日に「届かない」と判断するのは早いので、最低でも丸2日は待ってから切り分けに入るのが現実的です。
まとめ：3つだけ覚える
- 外部ドメインにレポートを送らせるなら、
<送信元>._report._dmarc.<受信ドメイン>のTXTを忘れずに置く - 受信側のフィルタ・迷惑メール・容量で止まっていないかを、メールサーバーのログで先に確認する
- 設定後、最低2日は待ってから判断する。digでDMARCレコード本体のスペルも実機確認
DMARCの基礎やp=quarantine / rejectへの段階的な強化方針については、DMARCポリシーの段階的な強化方法で詳しく扱っています。
レポートが届き始めたら可視化ツールを使う
rua= の不達が解消してレポートが届き始めたら、生 XML を手で開き続けるのは続きません。可視化ツールに任せると一気に運用が楽になります。主要 7 製品の比較は DMARC レポート解析ツール おすすめ 7 選、現在の DMARC レコードの中身を日本語で逐語解説してほしい場合は無料の SPF / DKIM / DMARC 設定確認ツール をご利用ください。
自社の状況を確認してみませんか
設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。 判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。