SiteKensa

DMARCレポートが届かない原因|外部のアドレスに送るには受け側の許可が要ります

公開日 更新日 DMARCメール独自ドメイン
DMARCの集計レポートが届くために送る側のruaと受け側の許可レコードの両方が要ることを示す図

DMARCレコードに rua=mailto:... を書いたのに集計レポートが1通も届かない。監視サービスを契約したのに管理画面が空のまま。この状態には設定の書き方とは別のところに原因があることがあります。

レポートを自分のドメイン以外のアドレスへ送らせる場合、受け取る側のドメインにも許可のレコードが必要です。これが無いと送信側は、レポートを送りません。設定した側からは正しく見えるため、気づきにくい失敗です。

実際にどれくらい起きているかを調べました。.jpドメイン19,065件のうち、外部のアドレスにレポートを送らせているドメインは、2,901件あり、そのうち735件(25.3%)は、指定した宛先すべてで許可レコードが見つかりませんでした(集計値と測定方法は、実測データのページにまとめてあります)。この記事ではその仕組みと確認手順を説明します。

確認するのは4か所です

レポートが届かないとき、順に見ていく場所は、4つです。

確認する場所 よくある状態
rua タグ ポリシーだけ書いて、レポートの送り先を書いていない
受け側の許可レコード 別のドメインのアドレスを指定したが、受け側に許可が無い
URIの書き方 mailto: 以外の形式で書いている
経過時間と送信量 設定は、正しいが、まだ集計されていない

そもそもDMARCレコード自体が無い場合は、レポート以前に指示も出せていない状態です。その場合は、DMARCを設定していないリスクと最初に置く設定から確認してください。

自分のドメインの現状は、診断で確認できます。

ドメインを診断する

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 から先へ進む判断ができなくなります。

これから rua を置く場合の書き方と置かなくてよい場合の条件は、DMARCレポートを受け取る設定にまとめてあります。

外部のドメイン宛に送らせていないか

ここがこの記事の中心です。上の例のように自分のドメインのアドレスを指定した場合、追加の設定は、要りません。問題になるのは別のドメインのアドレスを指定した場合です。

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._dmarcexample.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: を使ってください。

rua 以外のタグも含めたレコード全体の書式については、DMARCレコードの書式エラーで扱っています。

設定は正しいのに届かない場合

上の3点を確認しても届かない場合、次の可能性があります。

まだ集計されていない

集計レポートは、日次が基本です。RFC 9990 は、「daily (or more frequent) feedback reports」と述べており(セクション3.1)、報告期間は通常、UTCの1日を単位にします(同 セクション3.1.1.4)。設定してすぐに届くことを前提にしないでください。

その受信事業者に報告する対象が無い

集計レポートは、受信した側が「あなたのドメインをFromに使ったメールを処理した」ときに作られます。報告期間中にそのメールが1通も無ければ、その事業者から送られるレポートは、ありません。

送信量が少ないドメインではレポートが届く事業者と届かない事業者が分かれます。まったく送っていない事業者からは届きません。なお、「1日あたり何通未満なら送られない」という共通の基準は、DMARCの仕様には定められていません。

DNSにまだ反映されていない

レコードを追加した直後は、再帰リゾルバのキャッシュが残っていて、外からは見えない状態が続くことがあります。確認方法は、DNSが反映されないときの確認方法で扱っています。

直したあとに確認する

許可レコードを追加したら、次の順で確かめてください。

  1. 追加したレコードが外から引けるかを確認します。レポートを送らせる側のドメインを診断すると外部宛の宛先について、許可の有無を判定します
  2. 1日から2日ほど待ちます。集計レポートは、日次で作られるため、追加した直後には届きません
  3. それでも届かない場合、宛先のメールボックスが受け取れる状態か(容量、迷惑メールフォルダ、フィルタ)を確認します

診断で確認できるのは DNS上で許可レコードが引けるかどうかまでです。実際にレポートが届くかは宛先のメールボックス側の状態にも左右されます。

届いたレポートは、XMLで、そのままでは読めません。展開したXMLをDMARC集計レポート解析に貼り付けると送信元ごとの認証結果と通過率の表になります。貼り付けた内容は、ブラウザの中だけで処理され、送信されません。

レポートを読んで dmarc=fail が出ている送信元を見つけたら、原因は2つに分かれます。1つはSPFもDKIMも通っていない場合で、もう1つは通っているのにドメインがFromと揃っていない場合です。後者の切り分けはSPFはpassなのにDMARCがfailするときで扱っています。

ドメインを診断する

まずは全体を診断してみましょう

専門知識がなくてもいまの設定状況と具体的な対処方法をわかりやすく確認できます。

ドメイン設定を診断する

利用中のDNS事業者が分かっているなら事業者別の設定手順から直接進めます。