DMARCレポートが届かない原因｜外部のアドレスに送るには受け側の許可が要ります
DMARCレコードに rua=mailto:... を書いたのに、集計レポートが1通も届かない。監視サービスを契約したのに管理画面が空のまま。この状態には、設定の書き方とは別のところに原因があることがあります。
レポートを自分のドメイン以外のアドレスへ送らせる場合、受け取る側のドメインにも許可のレコードが必要です。これが無いと、送信側はレポートを送りません。設定した側からは正しく見えるため、気づきにくい失敗です。
実際にどれくらい起きているかを調べました。.jpドメイン19,065件のうち、外部のアドレスにレポートを送らせているドメインは2,901件あり、そのうち735件（25.3%）は、指定した宛先すべてで許可レコードが見つかりませんでした。この記事では、その仕組みと確認手順を説明します。
確認するのは4か所です
レポートが届かないとき、順に見ていく場所は4つです。
| 確認する場所 | よくある状態 |
|---|---|
rua タグ |
ポリシーだけ書いて、レポートの送り先を書いていない |
| 受け側の許可レコード | 別のドメインのアドレスを指定したが、受け側に許可が無い |
| URIの書き方 | mailto: 以外の形式で書いている |
| 経過時間と送信量 | 設定は正しいが、まだ集計されていない |
自分のドメインの現状は診断で確認できます。
rua が設定されているか
まず基本的なところです。DMARCレコードに rua タグが無ければ、レポートは生成されません。
v=DMARC1; p=none
これはポリシーだけを宣言した状態で、仕様上は有効なレコードです。ただしレポートは届きません。RFC 9989 §4.7 は rua タグについて「If the tag is not provided, Mail Receivers MUST NOT generate aggregate feedback reports for the domain」（タグが指定されていない場合、メール受信者はそのドメインの集計レポートを生成してはならない）と定めています。
送り先を追加した形は次のようになります。
v=DMARC1; p=none; rua=mailto:dmarc@example.jp
rua タグ自体は任意です。付けなくてもなりすまし対策としては成立します。ただし、どの送信元が認証に失敗しているかが分からないため、p=none から先へ進む判断ができなくなります。
外部のドメイン宛に送らせていないか
ここがこの記事の中心です。上の例のように自分のドメインのアドレスを指定した場合、追加の設定は要りません。問題になるのは、別のドメインのアドレスを指定した場合です。
v=DMARC1; p=none; rua=mailto:abc123@monitor.example.com
DMARC監視サービスを使うと、このような形になります。自社の別ドメインや、担当者の個人アドレスを指定する場合も同じです。
受け側の許可が要る理由
この仕組みは、悪用を防ぐために設けられています。RFC 9990 §4 は次のように説明しています。
Without checks, this would allow a bad actor to publish a DMARC Policy Record that requests that reports be sent to a victim address and then send a large volume of mail that will fail both DKIM and SPF checks to a wide variety of destinations; the victim will in turn be flooded with unwanted reports.
確認する仕組みが無ければ、攻撃者は「レポートを被害者のアドレスへ送れ」と書いたDMARCレコードを公開し、認証に失敗する大量のメールをばらまくことで、被害者に大量のレポートを送りつけられてしまいます。これを防ぐため、受け取る側が「このドメインからのレポートを受け入れます」と表明する必要があります。
追加するレコードの形
受け取る側のドメインに、次のTXTレコードを追加します。
| 項目 | 値 |
|---|---|
| ホスト名 | example.jp._report._dmarc（example.jp はレポートを送らせる側のドメイン） |
| 種別 | TXT |
| 値 | v=DMARC1 |
monitor.example.com 側のDNSに example.jp._report._dmarc.monitor.example.com という名前でこのレコードが存在すれば、認可されたと判定されます。
DMARC監視サービスを契約している場合、このレコードはサービス側が用意していることがあります。契約後にレポートが届かないときは、まずサービスの案内を確認してください。一方、自社の別ドメインや個人のアドレスを指定した場合は、自分で追加する必要があります。
すべての宛先に許可が要るわけではありません。多くの宛先を指定していても、許可があるものにだけレポートが届きます。
実際にどれくらい欠けているか
Majestic Millionに掲載されている.jpドメイン19,065件について、2026年7月27日に実際のDNSを調べました。手順はRFC 9990 §4に沿っています（再現用のスクリプトは scripts/measure-dmarc-rua.mjs にあります）。
| 項目 | 件数 |
|---|---|
| DMARCレコードを持つ | 10,103 |
うち rua を設定している |
5,921 |
| うち自分の組織の外へ送らせている | 2,901 |
| そのうち、指定した宛先すべてで許可が見つからない | 735（25.3%） |
| そのうち、一部の宛先だけ許可が無い | 102（3.5%） |
宛先ごと（URI単位）で数えると、外部宛3,258件のうち857件（26.3%）に許可がありませんでした。前者はレポートが1通も届かないドメイン、後者は設定の誤り率に近い数字です。引用する際はどちらの単位かを確かめてください。
この母集団は被リンクの多いサイトを集めたリストであり、.jpドメイン全体や、メールを送っているドメイン全体の無作為抽出ではありません。組織の内外の判定にはPublic Suffix List（sha256の先頭16桁が 084a5674d77c1d14 の版）を使いました。
mailto: 以外の書き方をしていないか
rua に指定できるURIの形式は mailto: だけではありません。RFC 9989 §4.7 は「Any valid URI can be specified」としたうえで、集計レポートを送る受信者には mailto: への対応を必須（MUST）としています。同時に「URIs involving schemes not supported by Mail Receivers MUST be ignored」とも定めています。
つまり、https: などを指定しても仕様違反ではありませんが、対応していない受信者からは無視されます。相互運用性が確実なのは mailto: なので、特別な理由がなければ mailto: を使ってください。
設定は正しいのに届かない場合
上の3点を確認しても届かない場合、次の可能性があります。
まだ集計されていない
集計レポートは日次が基本です。RFC 9990 は「daily (or more frequent) feedback reports」と述べており、報告期間はUTCで区切られます（§3.1.1.4）。設定した当日にすぐ届くものではありません。
その受信事業者に報告する対象が無い
集計レポートは、受信した側が「あなたのドメインをFromに使ったメールを処理した」ときに作られます。報告期間中にそのメールが1通も無ければ、その事業者から送られるレポートはありません。
送信量が少ないドメインでは、レポートが届く事業者と届かない事業者が分かれます。まったく送っていない事業者からは届きません。なお、「1日あたり何通未満なら送られない」という共通の基準は、DMARCの仕様には定められていません。
DNSにまだ反映されていない
レコードを追加した直後は、再帰リゾルバのキャッシュが残っていて、外からは見えない状態が続くことがあります。確認方法はDNSが反映されないときの確認方法で扱っています。
直したあとに確認する
許可レコードを追加したら、次の順で確かめてください。
- 追加したレコードが外から引けるかを確認します。レポートを送らせる側のドメインを診断すると、外部宛の宛先について許可の有無を判定します
- 1日から2日ほど待ちます。集計レポートは日次で作られるため、追加した直後には届きません
- それでも届かない場合、宛先のメールボックスが受け取れる状態か（容量、迷惑メールフォルダ、フィルタ）を確認します
診断で確認できるのは、DNS上で許可レコードが引けるかどうかまでです。実際にレポートが届くかは、宛先のメールボックス側の状態にも左右されます。