DMARCレポートを受け取る設定｜ruaの書き方と設定しなくてよい場合

診断で「集計レポートの送信先 (rua) が設定されていません」と表示された場合、レコードの書き方が間違っているわけではありません。rua は、仕様上の必須項目ではなく、書かないことも有効な設定です(RFC 9989 セクション4.7 が OPTIONAL と定めています)。

ただし、書いていない状態には確実な帰結が1つあります。受信側は、そのドメインについて、集計レポートを生成しません。RFC 9989 セクション4.7 は、「If the tag is not provided, Mail Receivers MUST NOT generate aggregate feedback reports for the domain」(タグが指定されていない場合、メール受信者はそのドメインの集計レポートを生成してはならない)と定めています。届いていないのではなく、作られていません。

設定済みなのに届かない場合は、原因が別のところにあります。その切り分けは、DMARCレポートが届かない原因で扱っています。

この記事では設定すべきかどうかの判断から書き方と受け取る前に決めておくことまでを説明します。

あなたのドメインは rua を設定すべきですか

先に分岐があります。診断が警告として、出していても設定しなくてよい場合が2つあります。

2行目は、レポートが無くても保護そのものは、成立しているためです。rua は、仕様上も任意なので、この状態を誤りとして、直す必要はありません。

3行目のドメインでは診断も警告ではなく情報として、表示します。名乗られたメールがあっても届かないよう既に閉じてあるため、レポートは、「なりすましの試行を把握できる」という任意の価値にとどまります。メールを使わないドメインの閉じ方は、Null MXとは？メールを使わないドメインの正しい閉じ方で説明しています。

なお、MXレコードを . にするNull MXは、「このドメインではメールを受け取らない」という、宣言で、送信しないことの宣言ではありません。送信の可否を宣言するのはSPFです。診断が表示を弱めるのはSPF側を見たときで、Null MXの有無では変わりません。

以降は、設定する場合を前提に進めます。

rua の書き方

DMARCレコードは、ドメインごとに1本です。すでに _dmarc にTXTレコードがあるなら2本目を作らず、いまの値に rua を足した1本に置き換えてください。2本以上あるとどちらも適用されません。

v=DMARC1; p=none; rua=mailto:{報告の宛先}

{報告の宛先} は、利用者が決める値です。ここに書く値によって、手順が変わるため、この記事では具体的なアドレスを埋めた完成形を載せていません。自分のドメインを診断するといまのレコードに rua を足した値がそのまま生成されます。

ドメインを診断する

宛先を複数にする場合は、カンマで区切ります。

v=DMARC1; p=none; rua=mailto:{1つ目の宛先},mailto:{2つ目の宛先}

指定できるURIは、mailto: だけではありませんが、集計レポートを送る受信側に対応が必須(MUST)とされているのは mailto: です(RFC 9989 セクション4.7)。対応していない形式は、無視されるとも定められているため、特別な理由がなければ mailto: を使ってください。

値を書かずに rua= だけを残さないでください。

v=DMARC1; p=none; rua=

これは、rua を指定していない状態と同じに扱われ、レポートは、生成されません。書式としては、通ってしまうため、設定したつもりで止まりやすい形です。

受け取る前に決めること

RFC 9989 は、レポートを受け取る用意をしてからDMARCレコードを公開する順序を示しています。セクション5.1.3 が「集計レポートを受け取るメールボックスを用意する」、セクション5.1.4 が「SPF・DKIM・集計レポートのメールボックスがすべて整ってから、DMARCポリシーレコードを公開する」です。すでに公開済みのドメインでも順序の考え方は、同じで、受け口を決めてから rua を足します。

どのアドレスで受けるか

集計レポートは、XMLファイルが添付されたメールとして、届きます。報告する受信事業者ごとに届くため、普段のやり取りに使うアドレスとは分けておくほうが扱いやすくなります。分ける理由は、量であって、内容の秘匿ではありません。

RFC 9990 セクション7.2 は、集計レポートには個人を特定する情報が含まれないと述べています。「No personal information such as individual mail addresses, IP addresses of individuals, or the content of any messages is included in reports」(個々のメールアドレス、個人のIPアドレス、メッセージの内容といった個人情報は、レポートに含まれない)とあり、ドメイン単位の認証結果が中心です。

ただし、まったく気にしなくてよいわけではありません。レポートには送信元IPアドレスや通数が含まれます（RFC 9990 セクション3.1.1.8）。RFC 9990 セクション7.1 は、レポートを外部の監視事業者へ送らせる場合について、自組織の規程がその利用や送信を制限していないかを確認するよう求めており、受け取った側がトラフィックの傾向を分析できる余地にも触れています。

組織ドメインが異なるアドレスを指定する場合は、受け取る側のドメインに認可のレコードが必要です(RFC 9990 セクション4)。これが無いとレポートは、送信されません。監視サービスを契約したのに届かない場合の、よくある原因です。追加するレコードの形と確認手順は、DMARCレポートが届かない原因にあります。

読む手段を決めておく

メールボックスを作るだけでは足りません。RFC 9989 セクション5.1.5 は、集計レポートは、人が読める形式ではないため機械的な解析が推奨されるとしたうえで「setting up a mailbox involves more than just the physical creation of that mailbox」(メールボックスの用意とは、物理的に作ること以上のものを含む)と述べています。

解析の手段は、3通りあります。解析サービスに送らせる、自分で処理する仕組みを用意する、そして社内の事情で受け取れない場合に外部の処理事業者へ集約する方法です。3つ目は、RFC 9990 セクション7.2 が明示的に認めています。どれを選ぶかを決めてから宛先を書くとあとから宛先を変えずに済みます。

レポートが無いとポリシーを引き上げる判断ができません

rua を設定する実務上の理由は、ここにあります。

RFC 9989 セクション5.1.6 は、集計レポートによって明らかになった正規の送信元の不備について、「these shortcomings MUST be addressed prior to any attempt by the Domain Owner to publish a Domain Owner Assessment Policy of Enforcement」(これらの不備は、ドメイン所有者が強制のポリシーを公開しようとする前に対処されなければならない)と定めています。

何を直すべきかは、レポートを見なければ分かりません。自社が把握していない送信経路・外部サービス経由の送信・部署ごとに契約された配信ツールなどが、p=none の間に集計レポートへ現れます。それを見ないまま p=quarantine や p=reject へ上げると正規のメールが届かなくなります。

どれくらいの期間が必要かは送信の頻度によって変わり、何か月もかかることがあります。RFC 9989 セクション5.1.7 は、「it may take many months of consuming DMARC aggregate reports」(集計レポートを読み続けるのに何か月もかかることがある)と述べています。何日で上げてよいという、基準は、ありません。

診断が rua の欠落を「要修正」ではなく「要確認」として、扱っているのもこの理由です。保護そのものは、p の値で成立しており、レポートは、次の段階へ進むための材料になります。

実測: DMARCを公開しているドメインの41.4%が rua を持ちません

Majestic Millionに掲載されている .jp ドメイン19,065件について、2026年7月27日にDNSを調べました(再現用のスクリプトは、scripts/measure-dmarc-rua.mjs にあります)。

この41.4%は、「DMARCレコードが見つかった10,103件」を分母にした割合です。.jp ドメイン全体でも日本の主要な企業ドメイン全体でもありません。母集団は、被リンクの多い順に並んだ一覧からの抽出で、規模の大きい組織に偏ります。集計値と測定方法は、実測データのページにまとめてあります。

4割が設定していないという、数字は、設定しなくてよいという、根拠にはなりません。上の判断表のとおり p=reject で運用が固まっているドメインでは不要ですが、p=none のまま止まっているドメインが多数を占めている可能性もあります。この測定ではポリシー値との突き合わせまでは行っていないため、どちらが多いかは、分かりません。

設定してもすぐには届きません

rua を書くことでできるのはレポートの送信を依頼することです。届くことが保証されるわけではありません。

RFC 9989 セクション5.3.8 は、受信側が24時間に1回以上の頻度で集計レポートを生成・送信することを SHOULD(推奨)としており、MUST(必須)ではありません。同じ節は、受信側がレポートの送信を見送る主な理由として、資源の制約・データ共有を制限する自組織の方針・利用者のプライバシーへの配慮を挙げています。

また、集計レポートは、その事業者があなたのドメインを名乗るメールを処理したときに作られます。報告期間中にそのようなメールが1通も無ければ、その事業者からのレポートは、ありません。送信量が少ないドメインでは届く事業者と届かない事業者が分かれます。

設定した当日には届かないと考えてください。数日待っても1通も届かない場合の切り分けはDMARCレポートが届かない原因にあります。

レポートの間隔は指定できません

古い解説には ri タグでレポートの送信間隔を指定できると書かれていることがあります。このタグは、RFC 9989 で削除されました(Appendix C.5.2「Tags Removed」に ri が挙げられています)。書いても無視されるため、間隔を短くする目的で追加しないでください。

RFC 9989 と RFC 9990 は、2026年5月に公開され、それまでの RFC 7489 を置き換えています。2024年以前に書かれた解説には現在は存在しないタグの説明が残っていることがあります。

設定できたか確認する

追加したあとの確認は、2段階です。

1. DNSに公開された値が外から引けるかを確認します。診断するとrua が読み取れているか、外部のアドレスを指定した場合は、受け側の認可があるかまで判定します
2. 実際にレポートが届くかを数日おいて確認します。1で問題が無くても上に書いたとおり届く時期と事業者は、送信の状況によって、変わります

DNSに書いた直後は、再帰リゾルバに以前の応答が残っていて外から見えないことがあります。その見分け方は、DNSが反映されないときの確認方法で扱っています。

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

届き始めたレポートは、XMLの圧縮ファイルです。展開した中身をDMARC集計レポート解析に貼り付けるとどの送信元から何通送られ、そのうち何通が認証を通ったかが表になります。

ドメインを診断する