## この記事でわかること

- DMARC集計レポート（rua）が届かない代表的な4つの原因
- 外部ドメインに送信させる場合に必要な「認可レコード」の仕組みと書き方
- digコマンドと受信メールヘッダで原因を切り分ける具体手順

## 「設定したのに、レポートが1通も来ない」

DMARC（ディーマーク）を `p=none; rua=mailto:dmarc@example.com` で設定し、翌朝メールボックスを開いたものの、Google や Microsoft からのレポートが見当たらない。設定から数日経っても状況が変わらない。こうした問い合わせは運用現場で珍しくありません。

DMARCレポートは、設定が正しくても受信側プロバイダ・DNS・メールサーバーのいずれかで条件が崩れると、簡単に止まってしまいます。本記事では、レポートが「届くべきなのに届いていない」状態を切り分け、どこを直せばよいかを判断するための材料を整理します。なお、レポートが届いた後の解析方法については、[DMARCレポートの見方](/blog/dmarc-report-reading)を先に確認しておくと役立ちます。

![DMARCレポート不達の原因切り分けフロー](/blog/dmarc-rua-not-receiving/troubleshooting-flow.svg)

## 原因1: 外部ドメインへの送信に「認可レコード」が必要

最も多いのがこのパターンです。DMARCの仕様（RFC 7489）では、**rua/ruf の送信先メールアドレスのドメインが、DMARCを設定したドメインと異なる場合、送信先ドメイン側に認可レコード（External Destination Verification）を置かないと、受信プロバイダはレポートを送信しません**。

たとえば `example.co.jp` のDMARCに `rua=mailto:reports@example.net` と書いた場合、`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:dmarc@example.co.jp`、つまり同一ドメイン）であれば、このレコードは不要です。

### digコマンドで存在を確認

```
dig +short TXT example.co.jp._report._dmarc.example.net
```

`"v=DMARC1"` が返らなければレコードが存在しません。Cloudflare、Route 53、お名前.com など、実際にDNSを管理している事業者の管理画面で、TXTレコードを追加してください。

## 原因2: レポート送信元が SPF / DMARC でブロックされている

レポートは `noreply-dmarc-support@google.com` や各社の no-reply アドレスから送られてきます。受信側のメールサーバーで以下のような設定になっていると、レポートそのものが受信前に拒否されることがあります。

- 自社で運用するメールゲートウェイで「件名にXMLを含む添付」を一律ブロック
- スパムフィルタが google.com / outlook.com からの大量メールを誤検知
- SPFやDMARCをreject運用している社内ドメインで、自分宛のメールが整合性エラーになる

特に、`rua` 受信用アドレスを「自社ドメインのメンバー」にしている場合、自社の厳格なDMARCポリシーが影響して受信側で拒否されているケースがあります。専用の受信用エイリアス（例: `dmarc-reports@example.co.jp`）を作り、フィルタの除外設定を入れることで多くは解決します。

メールサーバーのログで `noreply-dmarc-support` を検索し、reject や spam の記録がないかを確認してください。Microsoft 365 / Google Workspace の管理画面では、メールトレーシング機能で過去2週間程度を遡って追跡できます。

## 原因3: 受信メールアドレスが存在しない・容量超過

単純なミスですが、運用現場で実際に起きるパターンです。

- `rua=mailto:dmarc@exmaple.co.jp`（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日は待ってから切り分けに入るのが現実的です。

![_report._dmarc 認可レコードの構造](/blog/dmarc-rua-not-receiving/external-report-record.svg)

### まとめ：3つだけ覚える

- 外部ドメインにレポートを送らせるなら、`<送信元>._report._dmarc.<受信ドメイン>` のTXTを忘れずに置く
- 受信側のフィルタ・迷惑メール・容量で止まっていないかを、メールサーバーのログで先に確認する
- 設定後、最低2日は待ってから判断する。digでDMARCレコード本体のスペルも実機確認

DMARCの基礎やp=quarantine / rejectへの段階的な強化方針については、[DMARCポリシーの段階的な強化方法](/blog/dmarc-policy-tightening)で詳しく扱っています。

## レポートが届き始めたら可視化ツールを使う

`rua=` の不達が解消してレポートが届き始めたら、生 XML を手で開き続けるのは続きません。可視化ツールに任せると一気に運用が楽になります。主要 7 製品の比較は [DMARC レポート解析ツール おすすめ 7 選](/blog/dmarc-report-tool-comparison)、現在の DMARC レコードの中身を日本語で逐語解説してほしい場合は無料の [SPF / DKIM / DMARC 設定確認ツール](/tools/dns-auth-explainer) をご利用ください。

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。