DMARC 失敗レポート（RUF）：その概要、仕組み、および安全な有効化方法

DMARCレコードの DMARCレコードの公開 は、ドメインをなりすまし、フィッシング、および不正なメール利用から保護するための重要なステップです。しかし、真の運用上の価値は、正当な送信者が メール認証に合格しているか を通過しているか、またどこで失敗が発生しているかを示すレポートにあります。

多くの企業チームは、ドメイン全体の健全性を監視するためにDMARCの集計レポートを活用していますが、こうした要約情報だけでは、インシデント対応、コンプライアンス調査、あるいは複雑なサードパーティ送信者に関するトラブルシューティングを行う上で、十分な詳細情報が得られない場合があります。DMARC失敗レポート（RUF）にはメッセージレベルのコンテキストが含まれており、セキュリティチームやITチームが認証失敗の原因をより迅速に特定するのに役立ちます。 

このガイドでは、RUFレポートとは何か、集計データとどう異なるのか、そしてそれらを効果的に活用する方法について解説します。

DMARC失敗レポートとは何ですか？

DMARC失敗レポート（失敗レポートまたはRUFレポートとも呼ばれる）は、メッセージがDMARC認証に失敗した際に、受信側のメールサーバーから送信される、詳細かつほぼリアルタイムの通知です。このレポートには、認証結果、送信元、メッセージヘッダーなど、メッセージ単位の診断情報が含まれており、ドメイン所有者はこれを利用して、なりすまし攻撃の可能性を調査したり、メール認証に関する問題をトラブルシューティングしたりすることができます。

用語に関する注記： 「DMARC失敗レポート」、「DMARC失敗レポート」、「RUFレポート」という用語は、すべて同じレポートタイプを指します。その基盤となるフォーマットは、RFC 6591で定義されているAFRF（Authentication Failure Reporting Format）であり、これはARF（Abuse Reporting Format、RFC 5965）のDMARC固有の拡張です。業界では、これらの用語はしばしば同じ意味で使用されています。

• 誰が生成するのか？ 受信メールサーバー、ISP、企業のメールゲートウェイ、セキュリティアプライアンスなどが生成しますが、RUFに対応しており、認証の失敗を検出した場合に限られます。ドメイン所有者は「ruf=」タグを介してレポートをリクエストしますが、レポートを送信するかどうかは、受信側のプライバシーポリシーや設定に基づいて決定されます。
• どこに送信されるのですか？ DMARC DNSレコードのruf=タグで指定されたメールアドレス宛に配信されます。
• どのような形式が使用されていますか？ XMLファイルとして配信される集計レポートとは異なり、RUFレポートでは、認証失敗レポート形式（AFRF）を使用し、認証失敗に関する詳細データを、より人間が読みやすい形式で提供します。

DMARCの失敗レポートにはどのような情報が含まれていますか？

RUFだから DMARCレポートは は詳細なトラブルシューティングを目的として設計されているため、集計レポートには記載されていない、配信に失敗したメッセージに関する具体的なメタデータが含まれています。一般的なRUFレポートには、以下の情報が含まれます：

• 送信元のIPアドレス： メッセージの送信を試みた正確なIPアドレス
• 「From」および「Return-Path」のアドレス： ヘッダーの「From」およびエンベロープ送信者
• 件名： 送信に失敗したメールの実際の件名
• 認証結果： その理由に関する具体的な詳細 SPF または DKIM が失敗した理由や、 DMARCアラインメント が達成されたか
• メールヘッダー： メッセージのフィードバックヘッダーの全文
• 受信時刻： メッセージが受信サーバーに到着した時点のタイムスタンプ
• 適用されたDMARCポリシー： メッセージに適用されたポリシー（「なし」、「隔離」、「拒否」のいずれか）
• 配信結果： メッセージが配信されたか、隔離されたか、または拒否されたか
• 個人を特定できる情報（PII）： これらのレポートには件名や受信者アドレスが含まれる可能性があるため、多くの場合、PIIが含まれています

プライバシーに関する注意事項

個人を特定できる情報（PII）が含まれているため、多くの大手メールプロバイダーは、ユーザーのプライバシーを保護するためにRUFレポートの送信を停止しています。PowerDMARCは、以下の機能をサポートすることでこの問題に対処しています。 PGP暗号化 に対応しており、機密データは暗号化されたまま、お客様のみがアクセスできるようになっています。RUFレポートを送信する受信者の中には、本文や件名の機密部分を事前に伏せ字処理するケースがあり、そのため一部の失敗レポートが空の状態、あるいは[REDACTED]という文字列のみを含む状態で届くことがあります。

DMARC失敗レポートの例：各フィールドの見方

内部で何が起きているかを理解するには、生データを確認してください。メールの配信に失敗すると、受信側はAFRF形式のレポートを生成します。以下は、RFC 5737に準拠した予約済みドメインおよびIP範囲を使用した代表的な 例です。

フィールドごとの解釈

実用的なヒント

RUFレポートを確認する際は、以下の4つの質問を順に検討してください。送信元IPアドレスは承認済み送信者リストに含まれていますか？SPFまたはDKIM、あるいはその両方の検証に失敗しましたか？Original-Mail-Fromは自社のドメインと一致していますか？これは転送エッジのケースやメーリングリストのリレーのように見えますか？これらの質問に確信を持って答えられない場合は、調査のためにレポートをセキュリティチームに転送してください。

DNSにおけるレコードの表示例

これらのレポートを受信するには、DMARCレコードに「ruf=」タグを含める必要があります。代表的な例は以下の通りです：

自身のドメインとは異なるドメインにレポートを送信する場合、送信先のドメインは、あなたに代わってレポートを受信することを許可するDNSレコードを公開している必要があります。タグの内訳は以下の通りです：

• v=DMARC1: DMARCプロトコルを識別する標準のバージョンタグ
• p=none: 監視モード。メッセージは拒否も隔離もされず、受信者に対して認証結果の報告が求められる
• rua=: すべての認証アクティビティをまとめた日次集計レポートの保存先
• ruf=: 障害報告の送信先。一般的な受信箱ではなく、安全で専用の処理プラットフォームへ転送してください
• fo=1: SPFまたはDKIMのいずれかが失敗した場合、受信側にレポートを生成するよう指示します

DMARCの集計レポートと失敗レポート：RUAとRUF

どちらのレポートタイプも、同じDMARCレコード内で設定されますが、その目的は異なります。RUAはドメイン全体にわたる経時的な可視性を提供し、RUFは特定の失敗に関するメッセージレベルの詳細情報を提供します。より詳細な違いについては、以下の RUAとRUFレポートの比較を参照してください。

DNSレコードでDMARC失敗レポートを有効にする方法

RUFを有効にするには、DNS上の既存のDMARC TXTレコードを更新する必要があります。以下の手順に従ってください。

1. DNSプロバイダーにアクセスしてください。 ドメインのDNS管理コンソールにログインしてください。
2. DMARCのTXTレコードを確認してください。 _dmarc.yourdomain.com に公開されている TXT レコードを探してください。
3. RUFの送信先を追加します。 サポート対象の障害報告の送信先となる ruf=mailto: アドレスを挿入してください。
4. 障害時のオプションを設定します。 fo= タグを追加して、レポートを生成するタイミングを定義します。これについては次のセクションで説明します。
5. 安全な処理を行ってください。 レポートは、汎用の受信トレイではなく、PowerDMARCなどのセキュアなプラットフォームに転送してください。
6. 保存して、変更が反映されるのを待ちます。 DNSの変更が全世界に反映されるまで、最大48時間かかる場合があります。

RUFレポートを標準の受信トレイに送信すると、不要な情報が混在し、データ漏洩のリスクが高まります。レポートプラットフォームは、DMARCデータを一元管理し、生の認証データを分かりやすいダッシュボードに変換するとともに、失敗事例をSPF、DKIM、DMARCの整合性結果と関連付けることで、チームが問題をより迅速に特定できるようにします。

DMARC for Tag の解説：失敗レポートがトリガーされる場合

「fo」タグは、DMARCレコードの構成要素の一つであり、受信サーバーに対して、いつ失敗レポートを生成すべきかを指示するものです。

ほとんどのセキュリティ専門家は、認証失敗に関する情報を最大限に把握できるため、fo=1 を使用しています。とはいえ、fo=1 のレポートは、人間の受信トレイではなく、専用の安全な処理プラットフォームに転送すべきです。自動化を行わないと、生成されるレポートの量が処理しきれないほど膨大になる可能性があり、保護されていない受信トレイに送信すると、機密性の高いメッセージデータの漏洩リスクが高まります。A 特にDKIMの失敗 は特に、レポートが集中して発生する可能性があるため、共有メールボックスから隔離すべきです。

DMARCの失敗レポートが届かない可能性がある理由

RUFを有効にしているにもかかわらず、レポートの送信先が空になっている場合でも、必ずしも設定エラーであるとは限りません。レポートが受信されない原因として、いくつかの一般的な要因が考えられます。

これが、集計値が RUAレポート が、ドメイン全体の健全性監視における権威ある情報源と見なされている一方で、RUFレポートは特定の障害シナリオを調査するための補助的なツールとして機能しています。

プライバシーとセキュリティに関する懸念

RUFレポートには、件名、受信者アドレス、ヘッダー、場合によってはメッセージ本文が含まれる可能性があるため、 GDPR や CCPAなどのプライバシー枠組みの下で慎重に取り扱う必要があります。金融、医療、教育、小売、政府などの規制対象セクターに属する組織においては、失敗データは、プライバシーおよびコンプライアンス上の義務に対応した、セキュリティが確保され、アクセス制御が施されたシステムを通じて処理されるべきです。

Google、Microsoft、PCI DSS、GDPR、あるいは政府による電子メール認証要件への対応に取り組む組織にとって、安全なレポート作成ワークフローは重要です。RUFデータは調査を支援できますが、DMARCの可視性、適用状況、および認証済み送信者の管理を包括的に把握することは、長期的なコンプライアンス体制の整備において依然として不可欠です。

ベストプラクティス

• 専用の安全な報告プラットフォームをご利用ください。
• PGP暗号化を有効にする： 「鍵持ち込み（BYK）」モデルでは、秘密鍵を持つ承認済みユーザーのみが、機密性の高い障害報告の内容を閲覧できます。
• 役割および運用上の必要性に基づき、障害データへのアクセスを制限する。
• 適用されるプライバシー規制に従い、保存されているRUFデータに関するデータ保持ポリシーを策定する。
• データ保護に関する要件が厳しい法域では、RUFを有効にする前に法的審査を実施してください。

RUFレポートを使用してなりすましを検知し、障害を修正する方法

失敗データの受信が始まったら、各レポートを「決定的な結論」ではなく、「調査の手がかり」として扱うようにしてください。是正措置を決定する前に、承認済みの送信者リスト、DMARCの集計傾向、メールゲートウェイのログ、および脅威インテリジェンスと照らし合わせて、調査結果を検証してください。5つのシナリオで、失敗データから明らかになる事象の大部分を網羅しています。

ドメインのなりすましの検出

エラーレポートで、ヘッダーの「From」アドレスに自社ドメインが使用されているにもかかわらず、認識されない送信元IPが特定された場合は、これを調査対象として扱ってください。まず、承認済みの送信者リスト、集計された傾向、ゲートウェイのログ、および脅威インテリジェンスと照らし合わせて、その送信元を検証してください。不正なものであることが確認された場合は、そのIPをブロックリストに追加し、セキュリティオペレーションセンターに通知することができます。

正当な失敗の修正

サードパーティの送信者の設定が正しく行われていない、DKIMセレクタの設定に誤りがある、あるいはドメインのSPFレコードが複雑になりすぎているといった理由により、正当なメールの配信に失敗することがあります。レポートプラットフォームを活用することで、チームはこうした失敗を文脈に沿って特定し、ホスト型SPFや自動フラット化機能によってSPF管理を簡素化できるため、新しいSaaSツールを追加する際の配信トラブルのリスクを低減できます。

転送に関連する障害の診断

メールの転送では、転送サーバーのIPアドレスが元の送信者のSPFレコードに記載されていないため、SPF検証に失敗することがよくあります。RUFレポートで、既知の転送サービスやメーリングリストの中継サーバーからの失敗が報告された場合、その原因はスプーフィングの試みではなく、SPF検証の失敗である可能性が高いです。このような場合は、DKIM署名は通常、転送後も有効なままであるため、DKIMが依然として有効かどうかを確認するとともに、DKIMのアラインメントのみによってDMARCポリシーを満たせるかどうかを確認してください。

シャドウITや不正な送信元の発見

RUFレポートでは、ITチームが承認していない、あるいは認識していない送信元が明らかになることがあります。例えば、SPFレコードを更新せずに新しい自動化ツールを接続してしまったマーケティングチームなどが挙げられます。失敗レポートに、最近導入したSaaSプラットフォームに属するIPアドレスからの失敗が示されている場合、これは攻撃ではなく設定上の不備です。そのサービスを承認済み送信元リストに追加し、それに応じてDMARCレコードを更新してください。

調査のワークフロー

1. RUFレポート内の送信元IPアドレスを特定してください。
2. 権限の確認：このIPアドレスは、貴組織が利用しているツールやサービスに関連付けられていますか？
3. 整合性を確認する：Authentication-Results フィールドの SPF および DKIM の結果を確認してください。
4. 転送やメーリングリストの動作を確認する：SPFエラーが中継サーバーに起因するものかどうかを評価する。
5. リスクを分類する：設定ミスのある承認済み送信者、未承認の送信者、転送による副産物、またはシャドーITの発生源。
6. 是正措置：承認されているが検証に失敗している場合は、SPFまたはDKIMの設定を修正してください。承認されていない場合は、DMARCポリシーをp=quarantineまたはp=rejectに設定して保護を適用してください。
7. 集計レポートによるモニタリング：その後のRUAレポートを確認し、是正措置が有効であることを確認する。

RUFを有効にするべき場合と、スキップすべき場合

RUFは、すべてのドメインでデフォルトで有効になっているわけではありません。導入する価値があるかどうかは、レポートを誰が読み、どのような目的で利用されるかによって異なります。導入する価値がある状況は3つあり、導入すべきでない状況は2つあります。

• セキュリティチームがデータに基づいて対応できる体制が整っている場合に、この機能を有効にしてください。 SOCアナリストやインシデント対応担当者は、メッセージレベルの詳細情報を利用して、確認されたなりすましを調査します。これが、このレポートの最大の活用方法です。
• トラブルシューティングの最中に有効にしてください。 サードパーティの送信元で繰り返し障害が発生し、集計データだけでは詳細が不十分な場合、具体的なIPアドレスやアライメント結果に関する障害詳細情報を確認することで、診断時間を短縮できます。
• すでに安全な処理体制が整っている規制対象環境において、この機能を有効にしてください。 すでに暗号化され、アクセス制御が施されたレポート運用を行っている場合、調査の深度がさらに深まっても、追加されるリスクはごくわずかです。
• レポートが共有受信箱に届くことになる場合は、その点を再検討してください。 暗号化やアクセス制御がない状態で、個人を特定できる情報（PII）を含むレポートを受信すると、そのメリットを上回るコンプライアンス上のリスクが生じます。
• 出力の責任者がいない場合は、再検討してください。 分析担当者が選別を行わないまま、fo=1の高ボリュームのデータはノイズとなってしまいます。また、ドメインの健全性監視については、集計レポートですでにカバーされています。

ほとんどのチームにとって、デフォルトでは「集計優先」が妥当な選択です。ドメインの状態や対策の進捗状況を確認するには RUA を実行し、調査や頑固な送信者の障害など、メッセージレベルの詳細な分析が必要な場合には、意図的に RUF を有効にして、機密情報の取り扱いに適したプラットフォームにルーティングします。

DMARC失敗レポートの制限事項

RUFレポートで何ができないかを理解することは、何ができるかを知るのと同じくらい重要です。RUFレポートは、DMARCプログラムの意思決定における主要な判断材料ではなく、補助的な調査ツールとして位置づけるべきです。

• プロバイダーによる対応は限定的です： Gmail や Microsoft 365 を含む主要なメールプロバイダーは、プライバシー上の懸念から一般的に RUF レポートを送信しないため、障害のカバー範囲は本質的に不完全です
• 伏せられたデータ： レポートを送信する受信者は、配信前に件名、メッセージ本文、または受信者アドレスを伏せることがあります
• 転送による誤検知： メーリングリストの中継や転送サービスは、認証失敗のように見えるものの、実際にはなりすまし攻撃ではないSPFエラーを頻繁に引き起こします
• レポートの量とノイズ： fo=1の場合、送信量が多い送信者は処理しきれないほどの数のレポートを受信する可能性があり、その多くは真の脅威ではなく、予想される転送動作を反映したものである
• RUAの代替ではない： ドメイン全体の認証状態に関する信頼できる情報源は依然として集計レポートであるため、RUFは継続的なRUAモニタリングに取って代わるのではなく、それを補完するものであるべきです
• 個人識別情報（PII）の漏洩リスク： 暗号化やアクセス制御が行われていない場合、RUFレポートを受領するという行為自体が、GDPR、CCPA、および類似の枠組みに基づくコンプライアンス上の義務を生じさせる可能性があります

MSPがクライアントのドメイン全体でDMARC失敗レポートを活用する方法

MSPやMSSPにとって、顧客からメッセージの未着、なりすましの疑い、または原因不明の認証失敗が報告された場合、障害レポートは貴重な情報源となります。しかし、生のRUFレポートは、大規模な環境では管理が困難です。これらのレポートには機密性の高い顧客データが含まれている場合があり、複数のドメインから同時に送信されることもあり、実用的な対応を行うには他の認証シグナルとの相関分析が必要となるからです。

• マルチドメインの可視性： 一元化されたプラットフォームなしに、数十から数百ものクライアントドメインにわたるレポートを集約するには、多大な手作業が必要となります
• 機密データの取り扱い： クライアントドメインからのRUFレポートには、エンドユーザーの個人識別情報（PII）が含まれている可能性があり、MSPにはコンプライアンス上の義務が生じます
• レポート量の管理： レポートの発生量が多いクライアントドメインでは、大量の障害レポートが生成され、技術者のワークフローに過大な負担をかける可能性があります
• 役割ベースのアクセス制御： 技術者は、割り当てられたクライアントドメインに関するレポートのみを閲覧できるようにすべきです

次のような一元化されたプラットフォーム MSPやMSSP向けのPowerDMARCのような一元化されたプラットフォームは は、サービスプロバイダーがRUFデータを安全に処理し、クライアントドメインを分離し、手動による調査時間を短縮するとともに、機密データを不必要にさらすことなく、技術者がどの送信者、IPアドレス、または認証メカニズムが障害の原因となったかを迅速に把握できるようにします。

PowerDMARCがDMARCエラーレポートの対応にどのように役立つか

PowerDMARCは、DMARCの失敗データを安全に処理し、生の認証失敗情報を実用的な知見へと変換します。機密性の高いRUFレポートを通常の受信箱に送信する代わりに、チームは一元化されたダッシュボードでレポートを確認し、PGP暗号化によって機密データを保護するとともに、失敗情報をSPF、DKIM、およびDMARCの整合性結果と関連付けて分析します。

• 明確な可視性： すべてのドメインにわたって、送信に失敗した送信元、認証結果、および不審なIPアドレスをより迅速に特定します
• 安全な取り扱い： 「BYK（Bring-Your-Own-Key）」モデルを採用したPGP暗号化により、機密性の高い障害データの漏洩リスクを低減するため、PowerDMARCでさえも暗号化された内容を読み取ることはできません
• 一元管理： ツールを切り替えたり、生のXMLを解析したりすることなく、1つのプラットフォームからDMARC、SPF、DKIM、BIMI、MTA-STS、およびTLS-RPTを監視できます
• 迅速な是正措置： ホスト型SPFと自動フラット化機能により、AFRFレポートを手動で解析することなく、正当な送信者による配信失敗やなりすまし試みをトラブルシューティングし、新しいSaaSツールの追加に伴う配信失敗を低減します
• コンプライアンス対応状況： 監査証跡、役割ベースのアクセス制御、およびGoogle、Microsoft、PCI DSS、GDPR、ならびに政府の送信者要件への対応

よくあるご質問

DMARCの失敗レポートとは、具体的にはどのようなものなのでしょうか？

個々のメールが、DMARCポリシーおよび失敗オプションで定義された認証チェックに失敗した際に生成される、ほぼリアルタイムの失敗レポートです。24時間分の全メッセージのアクティビティをまとめた集計レポートとは異なり、メッセージ単位の詳細情報が含まれています。

RUFとRUAの違いは何ですか？

RUAは、すべてのメッセージを対象としたドメイン全体の要約をXML形式で毎日提供します。一方、RUFは、個々の失敗メッセージについてAFRF形式（RFC 6591、RFC 5965のARFを拡張したもの）でほぼリアルタイムに提供され、メッセージ固有の詳細情報を含み、個人を特定できる情報（PII）が含まれる場合があります。RUAにはPIIは含まれません。

これらのレポートを有効にするにはどうすればよいですか？

_dmarc.yourdomain.com の DMARC TXT レコードに「ruf=mailto:[email protected]」を追加してください。SPF または DKIM のいずれかが失敗した際にレポートを受け取るには、「fo=1」を含めてください。レポートは、通常の受信箱ではなく、セキュリティ対策が施されたプラットフォームに転送するように設定してください。

RUFを設定したのですが、何も表示されません。壊れているのでしょうか？

必ずしもそうとは限りません。多くのプロバイダーはプライバシーの理由からRUFを送信せず、メッセージが通過してもレポートは生成されません。集計されたRUAレポートが届いているのであれば、記録は正しい可能性が高いです。その他の原因については、トラブルシューティング表をご確認ください。

すべてのメールボックスプロバイダーがDMARCの失敗レポートを送信しているのでしょうか？

いいえ。Gmail や Microsoft 365 は、ユーザーのプライバシーを理由に、一般的にこの機能に対応していません。対応範囲は、RUF サポートを実装している受信側に限定されており、通常は一部の企業向けメールゲートウェイ、ISP、および独立系メールサーバーなどが該当します。これは重要な制限事項です。

DMARCの失敗レポートを受け取っても安全ですか？

これらのメールには、件名、受信者アドレス、ヘッダーなどの個人を特定できる情報（PII）が含まれている可能性があります。適切な管理措置を講じずにこれらを受信すると、GDPRやCCPAに基づく義務が生じる可能性があります。PGP暗号化、役割ベースのアクセス制御、および保存期間の明確な規定が整備されたセキュアなプラットフォームへ転送するのが最も安全です。

foタグにはどのような役割があるのでしょうか？

これは「Failure Options（失敗時の処理）」の略であり、受信側がレポートを生成するタイミングを定義します。fo=0（デフォルト）では、SPFとDKIMの両方が失敗した場合にレポートが送信されます。fo=1では、いずれかが失敗しただけでレポートが送信されます。fo=dはDKIMの失敗時のみ、fo=sはSPFの失敗時のみレポートをトリガーします。

• について
• 最新記事

ミレーナ・バグダサリャン

コンテンツスペシャリスト（勤務先： PowerDMARCの

ミレーナは、IT、サイバーセキュリティ、バーチャルイベントなどに関する魅力的なコンテンツ制作に7年以上の経験を持つ、熟練したライター兼コンテンツ制作者です。ニューヨーク大学アブダビ校、UWCチャイナ校、カレッジ・オブ・ヨーロッパなどの名門校を卒業。

最新記事 by Milena Baghdasaryan(全て見る)

• DMARC 失敗レポート（RUF）：その概要、仕組み、および安全な有効化方法 - 2026年8月11日
• 世界最大手のAI企業におけるメール認証 - 2026年8月10日
• 2026年のビジネスメール詐欺（BEC）対策ツール トップ5 - 2026年7月31日