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 §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を設定していないリスクと、最初に置く設定から確認してください。

ドメインを診断する