DMARC集計レポート送信先（ruaタグ）とは？設定方法・診断基準・届かない原因

DMARC集計レポート送信先（rua）とは

DMARC集計レポート送信先とは、DMARCレコードの rua タグで指定する、**集計レポート（Aggregate Report）**の受け取り先です。集計レポートは、受信側（Gmail、Microsoft、国内ISPなど）が作成し、「どのIPアドレスから、自ドメインを名乗るメールが何通届き、SPF/DKIM/DMARCの結果がどうだったか」をXML形式でまとめたものです。

_dmarc.city.example.lg.jp. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@city.example.lg.jp"

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、メールの差出人ドメイン（ヘッダーFrom）が正当な送信元から送られたかを、SPF・DKIMの結果と「ドメインの整合（アライメント）」によって受信側が判定する仕組みです。ドメイン所有者は _dmarc.ドメイン のTXTレコードに方針を公開し、受信側はそれに従って隔離・拒否などの処理を行います。

rua がないと、ドメイン所有者は自組織名義のなりすましメールの規模も、自組織の正規システム（庁内メール、メルマガ配信、防災メール、委託先の予約システム等）の認証失敗も把握できません。この項目は、DMARCレコードが存在する場合に、その中に rua による集計レポートの受信先が設定されているかを確認します。

DMARCレコードそのものの有無は「DMARCレコード」、p=quarantine／p=reject への強化は「DMARC強制ポリシー」で別に確認します。このページは、レポートの送り先である rua に絞って解説します。

ruaタグの書式（RFC 9989）

DMARCレコードは「タグ=値」をセミコロンで区切った文字列です。

• rua の値はカンマ区切りの「DMARC報告URI」のリストで、受信側は mailto: URIへの対応が必須とされています。
• RFC 9989の構文では、= の前後に空白（WSP）を置くことが許容されています（equals = *WSP "=" *WSP）。したがって rua = mailto:... も有効です。
• RFC 7489では mailto:addr!10m のようにサイズ上限を付ける記法がありましたが、RFC 9989では廃止された記法（obs-dmarc-uri）という位置付けになり、レポート送信側はサイズ指定を無視するものとされています。既存レコードに残っていても直ちに無効にはなりませんが、新規設定では付けないでください。
• RFC 7489にあった ri（レポート間隔）、pct、rf タグはRFC 9989で削除されました。集計レポートは実運用上おおむね1日単位で送られますが、RFC 9990は「daily（またはそれ以上の頻度）」という性格を説明するにとどまり、送信間隔を厳密に義務付けてはいません。

集計レポートには何が書かれているか

集計レポートはXMLで、概ね次の情報を含みます（形式はRFC 9990で定義）。

個々のメール本文や宛先は含まれないため、集計レポートは失敗レポートに比べて個人情報の扱いが軽いのが特徴です。それでも送信元IPや通数は運用情報であり、取扱いのルールを決めておく必要があります。

DMARC集計レポート送信先はなぜ必要か

外部ドメインを送信先にする場合の承諾レコード（RFC 9990 第4節）

rua に自ドメイン以外のアドレス（例: 委託先のDMARC分析サービス）を指定する場合、受信側は「その外部ドメインが本当にレポート受領を承諾しているか」を確認します。RFC 9990 第4節（Verifying External Destinations）では、送信先ドメイン側に次の形式のTXTレコードを置くことで承諾を示します。

city.example.lg.jp._report._dmarc.dmarc-vendor.example. IN TXT "v=DMARC1"

このレコードがないと、受信側はその送信先へのレポート送付を省略することがあり、「ruaは書いてあるのにレポートが届かない」原因になります。これは第三者にレポートを大量送付する迷惑行為を防ぐための仕組みです。

DMARC集計レポート送信先についてよくある誤解

• 「ruaを設定するとなりすましが止まる」：ruaは監視のための設定であり、メールの受け取り拒否は p=quarantine / p=reject の役割です。ruaは、その強化を安全に進めるための「目」にあたります。
• 「ruaは個人の受信箱で受ければよい」：大手受信事業者から毎日XML（多くはZIPやgzip圧縮）が届くため、個人の受信箱はすぐ埋もれます。専用アドレスや分析サービスを用意するのが一般的です。
• 「ruf（失敗レポート）も必須」：失敗レポート（RFC 9991）は個別メールの情報を含むためプライバシー上の配慮から送らない受信事業者も多く、本項目の対象外です。

DMARC集計レポート送信先の診断基準（セキュリティAIチェッカー）

取得方法

• 診断の最終URL（リダイレクト追跡後）のホスト名から先頭の www. を取り除いたものを「メールドメイン」とみなします（例: www.city.example.lg.jp → city.example.lg.jp）。
• Google Public DNSのDNS over HTTPS（JSON API, https://dns.google/resolve）で _dmarc.メールドメイン のTXTレコードを照会します。通信失敗・非2xx応答時は短い待機を挟んで最大3回試行します。
• TXTの値のうち、先頭が v=DMARC1 で直後が ; または末尾であるもの（= 前後の空白を許容。値 DMARC1 は大文字小文字を区別するため v=dmarc1 は対象外）を有効なDMARCレコードとみなします。有効なレコードがちょうど1件のときだけ採用します。RFC 9989は、同じ名前に複数のDMARCレコードがある場合はすべて破棄すると定めているためです。
• 対象ドメインに有効なレコードが1件もなく、メール受信設定（MX）があり、_dmarc の照会自体は成功している場合は、RFC 9989 第4.10節のDNS Tree Walkにならって親ドメインの _dmarc を最大7件たどり、組織ドメイン（無ければ psd=y を宣言した公開サフィックスドメイン）のレコードを採用します。親側でも、有効なレコードがちょうど1件の階層だけを候補にします。
• 採用したレコードに有効な p（none／quarantine／reject）も rua の mailto: もない場合は、受信側で処理されないレコードとして「DMARCなし」と扱います。

判定条件

スコアはpass=1.00、warn=0.45、fail=0.00の重み付き平均で、naは分母から除外されます。本項目に × 要改善（fail）はありません。DMARCがない状態を二重に減点しないよう、DMARC未設定は対象外としています。

判定しないこと

• 親ドメインをたどるのは、対象ドメインにMXがある場合だけです。MXのないサブドメインのサイトで、親の組織ドメインにだけDMARCがある場合は対象外になります。
• rua に mailto: が1つもない場合（例: https: のURIだけ）は △ になります。受信側に対応が義務付けられているのは mailto: だけです。先頭が https: でも後続に mailto: があれば ○ です。
• 外部送信先の承諾レコード（_report._dmarc）の有無は確認しません。外部の分析サービスを使っている場合は、レポートが実際に届いているかを運用側で確認してください。
• レポートが実際に読まれているか、どのような頻度で確認しているかは公開情報からは分かりません。

自治体サイトでの判定例

DMARC集計レポート送信先がないとどんなリスクがあるか

• なりすましの放置：自治体名義のフィッシングメール（「給付金のお知らせ」「税の還付」等）が大量に送られていても、レポートがなければ発生規模や送信元IPを把握できず、住民への注意喚起や関係機関への通報が遅れます。
• 強化の停滞：p=none から p=quarantine / p=reject へ強化する際、正規の送信システム（委託先のメール配信、施設予約システム、防災メール等）がSPF/DKIMで整合しているかをレポートで確認するのが一般的な進め方です。レポートがないと「強化すると正規メールが届かなくなるかもしれない」という不安から p=none のまま止まりやすくなります。
• 委託先システムの認証不備の見逃し：外部サービスが自治体ドメインを名乗って送信している場合、その認証失敗はレポートでしか気づけないことが多くあります。

なお、個別の自治体での被害事例は公開情報で確認できたもののみを扱う方針のため、ここでは一般的な攻撃シナリオにとどめます。

DMARC集計レポート送信先の設定方法と運用

1. 受信体制を決める

• 専用アドレス（例: dmarc-report@メールドメイン）を作成し、担当課と委託事業者が確認できるようにします。
• 量が多い場合はDMARCレポート分析サービス（XMLを集計・可視化するもの）を利用します。

2. DNSレコードを更新する

; 自ドメインで受ける場合
_dmarc.city.example.lg.jp. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@city.example.lg.jp"

; 分析サービスと自組織の両方に送る場合（カンマ区切り）
_dmarc.city.example.lg.jp. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@city.example.lg.jp,mailto:abc123@dmarc-vendor.example"

外部の分析サービスを指定する場合、多くのサービスは自社側で _report._dmarc の承諾レコードを用意していますが、念のためサービスの案内を確認してください。

3. 段階的に導入する

1. p=none + rua で2〜4週間程度レポートを収集し、正規の送信元を洗い出す。
2. SPFへの送信元追加、DKIM署名の設定を正規送信元すべてに行う。
3. p=quarantine へ移行し、レポートで正規メールの失敗がないことを確認する。
4. p=reject へ移行する。移行後も rua は残し、監視を続ける。

4. 設定後の確認方法

# Linux/macOS
dig +short TXT _dmarc.city.example.lg.jp

# Windows
nslookup -type=TXT _dmarc.city.example.lg.jp

# DoHで確認（本診断と同じ取得経路）
curl -s "https://dns.google/resolve?name=_dmarc.city.example.lg.jp&type=TXT"

設定を変えたら、セキュリティAIチェッカーで再診断し、根拠欄が「ruaを確認しました。」になっていることを確認します。

5. 運用のチェックポイント

• 週1回程度、レポートの送信元IP一覧を確認し、「知らない送信元で認証成功しているもの」「既知の送信元で認証失敗しているもの」を洗い出す。
• 委託先や新システムの導入時に、送信元をSPF/DKIMに追加する手続きを調達仕様書・チェックリストに組み込む。
• 担当者の異動に備え、受信アドレスは個人ではなく共有の役割アドレスにする。

設定時の注意点（ガードレール）

• _dmarc のTXTレコードは1つだけにします。複数あるとDMARCの方針が適用されません。既存レコードを編集し、追記で2本目を作らないでください。
• セミコロンとカンマの区切りを誤ると、rua が無視されたりレコード全体が無効と扱われたりします。設定後に上記コマンドで文字列を確認してください。
• TXTが255文字を超える場合、DNS上は複数の文字列に分割されます。DNS事業者の管理画面の仕様に従ってください。
• レポートにはIPアドレスや送信量などの情報が含まれます。受け取ったレポートの保存期間・閲覧者を決めておきます。

よくある質問（FAQ）

参考資料

• RFC 9989 Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9990 Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting
• RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• DMARCbis（RFC 9989）の経緯（IETF Datatracker）
• JSON API for DNS over HTTPS (DoH)（Google Public DNS）
• @IT「RPKI」「DNSSEC」「DMARC」のガイドライン策定に込められた思い

「DMARC集計レポート送信先」と関連する診断項目

• DMARCレコードhigh
• DMARC強制ポリシーmedium
• SPFの一意性・構文・DNS参照数high
• SMTP TLSレポート（TLS-RPT）low
• SPFレコードmedium
• SPFの終端ポリシーmedium
• CAAレコードlow
• DNSSECmedium