DMARC rua と ruf の違い｜使い分け
目次
この記事でわかること
- DMARC の
rua=（aggregate report）とruf=（forensic report）の構造的な違い - 2026 年時点で主要メールプロバイダがどちらに対応しているかの最新状況
- 中小企業の実務では
ruaのみ監視すれば十分と言える理由
「rua と ruf、両方設定すべき？」という疑問
DMARC（ディーマーク）のレコードを書こうとすると、v=DMARC1; p=none; rua=mailto:...; ruf=mailto:... のように 2 種類のレポート送信先を指定できることに気づきます。
設定例を検索すると rua と ruf の両方を書いているサンプルが多く、「両方設定したほうが安全なのでは」と考えがちです。しかし結論から言うと、2026 年現在、実務では rua のみで十分です。ruf を設定してもほとんどのプロバイダから何も届きません。
本記事では、両者の構造的な違いと最新のプロバイダ対応状況を整理し、設定方針を判断できるようにします。DMARC そのものの設定手順はDMARC 設定方法を徹底解説を、レポートの読み方はDMARC レポートの見方をご参照ください。
rua と ruf の構造的な違い
DMARC の仕様（RFC 7489）は 2 種類のレポートを定義しています。
rua（aggregate report、集計レポート）
24 時間分のメール配信結果を、送信元 IP・認証結果ごとに集計した XML です。各受信プロバイダが 1 日 1 回を目安にまとめて送ってきます。中身は通数や認証の成否などの統計データのみで、個別メールの本文や件名は含まれません。
プライバシー上の問題が起きにくいため、Gmail・Outlook・Yahoo など主要なプロバイダがほぼすべて対応しています。日々の運用は基本的にこのレポートを前提に進めます。XML の読み方はDMARC 集計レポート（rua）の読み方で詳しく解説しています。
ruf（failure report、失敗レポート）
認証に失敗した個別メール 1 通ごとのサンプルが、ほぼリアルタイムで送られてくる形式です。件名・ヘッダー・本文の一部が含まれるため、機微情報として取り扱う必要があります。
設計思想としては「なりすましの実例を即座に確認して対処する」ことを想定していました。しかし後述のとおり、プライバシー懸念から多くのプロバイダが送信を停止しています。仕様面の詳細はDMARC ruf（forensic report）の概要を参照してください。
2026 年時点の主要プロバイダ対応状況
実務判断で最も大事なのが「実際に届くかどうか」です。下表に主要プロバイダの送信状況を整理しました。
ポイントは次のとおりです。
- Gmail / Outlook / Yahoo はいずれも
rufを送信しない。Gmail は早い時期から送信停止、Microsoft は Outlook 系で標準では送らない方針。Yahoo も停止傾向 - 国内 ISP も多くが
rufを送らない。一部対応していたプロバイダも、プライバシー保護の観点から段階的に停止している ruaは主要プロバイダがほぼすべて対応。指定すれば翌日から XML が届き始める
つまり ruf を設定しても、現実には「ほとんど届かない」または「届くプロバイダから一部だけ届く」状態になります。ruf を運用前提に置くと判断材料が不足し、かえって誤った打ち手につながります。詳しい移り変わりの背景は姉妹記事のDMARC forensic レポート停止の流れと代替策で扱っています。
中小企業の実務では rua のみで十分な理由
「ruf がないと個別メールの調査ができないのでは」と心配される方もいますが、実務では次の理由で rua のみで困りません。
理由 1: rua の統計から原因の当たりは付けられる
rua には送信元 IP・通数・SPF/DKIM の検証結果・DMARC の最終判定（disposition）が記録されています。「どの IP から何通、どのドメインを From として送られて、SPF と DKIM のどちらが落ちたか」までは特定できます。
未把握の SaaS や転送経路が原因のことが多く、IP の逆引きと社内棚卸しで大抵の問題は追跡できます。rua の活用ステップはDMARC レポートの見方の「見るべき 3 つのポイント」を参考にしてください。
理由 2: 個別メールの中身は Authentication-Results で確認可能
ruf の代わりに、Gmail などで実際に受信したメールの「メッセージのソースを表示」を開けば、Authentication-Results ヘッダーで認証結果を 1 通単位で確認できます。社内テスト送信を組み合わせると、ruf がなくても挙動を検証できます。
理由 3: プライバシーと社内ポリシーの観点で受け取らないほうが安全
ruf には件名や本文の一部が含まれるため、業務メールの内容が外部レポート経由で社内に流入する形になります。受信ボックスの管理者が情シス以外にいる場合、社内ガバナンス上扱いづらいケースがあります。届かない前提なら、わざわざ設定して受信先を整備するメリットは小さいです。
それでも ruf を設定するなら
特殊な調査要件があり ruf も使いたい場合は、次の点に留意してください。
- DKIM 鍵の長さ・選択肢を絞った上で運用する。ruf には DKIM 検証に必要な情報の一部が含まれるため、漏れた場合の影響を最小化する
- 受信先メールボックスを情シス専用にする。共有受信箱では機微情報の取り扱いが難しい
- External Destination Verification を忘れない。外部ドメインを受信先にする場合は
_report._dmarc.<送信元>の DNS レコードが必要（RFC 7489 Section 7.1） - ruf=mailto に加えて fo= タグも指定する。
fo=1（SPF または DKIM どちらか失敗で送信）が一般的だが、プロバイダ側が無視するケースも多い
詳細な仕様は RFC 7489 の公式参照を推奨します。
よくある質問
ruf を設定しても届かないのは設定ミスですか
多くの場合、設定ミスではなくプロバイダ側が送信していないだけです。Gmail・Outlook・Yahoo は通常 ruf を送りません。rua が届いているのに ruf だけ届かない場合は、まず正常と考えてよいでしょう。
rua の送信先が届かない場合はどうしたらいいですか
External Destination Verification の DNS レコード不足が典型的な原因です。詳しい確認手順はDMARC rua レポートが届かない時に確認することを参照してください。
rua レポートをどのツールで可視化すればいいですか
無料で始められる選択肢をDMARC ツール おすすめ 7 選比較とDMARC 解析ツールの選び方にまとめています。
まとめ
ruaは 24 時間の集計、rufは個別メールの失敗サンプル- 2026 年時点で Gmail / Outlook / Yahoo は
rufを送らない。多くの国内 ISP も停止傾向 - 中小企業の実務では
ruaのみで十分。ruf設定は届かない前提で考える - 個別メールの認証結果は受信側の
Authentication-Resultsヘッダーで補える
まずは自社の rua 受信状況を確認しませんか
自社ドメインに DMARC が設定されているか、rua の送信先が正しく動作しているかは、ドメイン番人の無料診断で数秒で確認できます。rua の運用設計やレポート可視化ツールの選定で迷う場合は、お問い合わせフォームから状況をお知らせください。専門家が一緒に整理いたします。