ARFとは？ 不正利用報告フォーマットとDMARC失敗レポート（RFC 5965）
by
最終更新日:
9 読了時間：約9分
主なポイント
- ARF（Abuse Reporting Format）は、RFC 5965で定義されている、電子メールの不正利用を報告するための標準化された機械可読形式です。これは、DMARCの失敗レポートやISPのフィードバックループの基盤となる形式です。
- 「フォレンジックレポート」、「障害レポート」、「ARFレポート」は、いずれも同じアーティファクトを指します。この用語は、2026年5月に公開された新しいDMARC RFCセットに伴い変更されました。
- 2026年5月現在、DMARC自体は、RFC 9989（コアDMARC）、RFC 9990（集計／RUAレポート）、およびRFC 9991（失敗／RUFレポート）の3つの文書で定義されています。これら3つを合わせて、元のRFC 7489は廃止されました。その基盤となるARFワイヤ形式は、依然としてRFC 5965のままです。
- RFC 9991 では、失敗レポートに必須の「Identity-Alignment」フィールドが追加されました。このフィールドは、どのメカニズム（SPF、DKIM、あるいはその両方）が整合した識別子の生成に失敗したかを正確に示します。
- Gmail や Yahoo を含むほとんどのメールサービスプロバイダーは、依然として失敗レポートを十分な量で送信していません。集計（RUA）レポートは、依然としてほとんどのドメイン所有者にとって信頼できるデータソースとなっています。
ARF（虐待報告フォーマット）とは何ですか？
ARFは「Abuse Reporting Format（不正利用報告フォーマット）」の略称です。これは、電子メールが問題を引き起こしたことを送信者に通知するための、標準化された機械可読形式です。2010年にRFC 5965で定義されました。当時は、不正利用報告のほとんどが形式の統一されていないプレーンテキストのメールであり、メール管理者が手作業で読み解かなければなりませんでした。報告件数が少ないうちは問題ありませんでしたが、プロバイダーが何らかの処理を自動化しようとした途端、この方式は機能しなくなりました。 ARFは、受信者、ISP、メールボックスプロバイダーに共通の構造を提供し、スクリプトやパーサーが容易に処理できる形式で、ドメイン所有者や送信者に不正利用の事象を報告できるようにしました。
現在、ARFは主に以下の4つの場所で利用されています：
- DMARC 失敗レポート– メッセージが DMARC 認証に失敗した場合、受信側は、具体的にどのような問題が発生したかを説明する ARF レポートを送信することができます。
- ISPのフィードバックループ– 受信者が「これはスパムです」をクリックすると、一部のプロバイダはその苦情をARF形式で送信者に通知します。
- アブーズデスクへの苦情– 自動アブーズ処理システムを経由して転送された、不正利用に関する手動による報告。
- フィッシングおよび詐欺の報告– 単に迷惑なメッセージではなく、詐欺であると判断されたメッセージに関する報告。
あらかじめ明確にしておきたいのですが、このARFは、皆さんが思い浮かべるかもしれない他の頭字語とは一切関係ありません。電子メールの世界では、ARFは常に「Abuse Reporting Format（不正利用報告フォーマット）」を指します。
ARFレポートの構成（3つの部分）
RFC 5965 では、ARF を MIME の multipart/report メッセージとして定義しています。これは、ARF が 3 つの異なる構成要素を組み合わせた電子メールであることを意味します。各構成要素は、それぞれ異なる読者向けに設計されています。1 つは人間向け、1 つは機械向け、そしてもう 1 つは証拠として機能するものです。
第1部：人間が読みやすい要約（text/plain）
最初の部分は、受信トレイをざっと目を通す人を想定したプレーンテキストのブロックです。通常、何が起きたかを1行か2行で要約しているため、レポートをざっと目を通すだけでも、大まかな内容を把握するために機械可読フィールドを解析する必要がありません。
第2部：機械可読レポート（message/feedback-report）
これがレポートの中核であり、自動システムが実際に解析する部分です。ここには、Feedback-Type、Version、User-Agent、Source-IP、Arrival-Date といったキー・バリュー形式のフィールドに加え、Auth-Failure のような認証関連のフィールドが含まれています。レポートの診断的価値は、まさにこの部分に集約されています。
第3部：元のメッセージ（message/rfc822 または text/rfc822-headers）
最後の部分には、送信者の設定や、受信者がどの程度の詳細情報を共有する意思があるかによって、元のメッセージ全文、あるいはヘッダーのみが含まれます。メッセージ本文には個人情報が含まれている可能性があるため、多くの受信者は、レポートを転送する前に、これをヘッダーのみに絞り込んだり、一部を伏せたりします。
ARFのフィードバックの種類
「フィードバックの種類」フィールドには、現在表示されているレポートの種類が表示されます：
| フィードバックの種類 | 意味 | 使用例 |
|---|---|---|
| 虐待 | スパムや迷惑メールに関する苦情 | ISPのフィードバックループ |
| 認証失敗 | 認証に失敗しました | DMARCの失敗レポート |
| 詐欺 | フィッシングまたは詐欺 | 不正・ブランド権の濫用に関する通報 |
| ウイルス | マルウェアが検出されました | ウイルス対策／セキュリティゲートウェイ |
| その他 | 上記で言及されていない事項 | その他、ベンダー固有の用途 |
DMARCに関しては、ここに表示される値は常に「auth-failure」のみです。新たなユースケースが登場した場合は、IANAに追加のフィードバックタイプを登録することも可能ですが、DMARCのユースケースにおいては、導入当初から一貫して「auth-failure」のみが使用されています。
ARF、AFRF、RUF、法医学報告書：用語の整理
DMARCレポートに関する記事を読んでいて、ARF、AFRF、RUF、そして「フォレンジックレポート」という用語がほぼ同じ意味で使われているのを見かけたなら、それは気のせいではありません。これらの用語は確かに重なり合っており、実際の関係は以下の通りです：
- ARFは、RFC 5965で定義された基本ワイヤ形式です。これは汎用的なものであり、DMARC専用として定義されたことはありません。
- AFRF（Authentication Failure Reporting Format）は、RFC 6591で定義された拡張仕様であり、SPF、DKIM、およびDMARCの認証失敗を報告するためにARFを特別に適合させたものです。
- RUFとは、メッセージごとのエラーレポートを特定の宛先に送信するよう要求するために、DNSレコードに設定するDMARCタグ（ruf=）のことです。
- 「フォレンジックレポート」とは、この同じアーティファクトの旧称であり、元のDMARC仕様であるRFC 7489から引き継がれたものです。現在のRFCシリーズでは、代わりに「失敗レポート」と呼ばれています。
つまり、誰かが「フォレンジックレポートの例」を尋ね、別の誰かがそれを「DMARC失敗レポート」と呼んだとしても、両者は同じものを指しています。名称が変わったのは規格に合わせてであり、その根底にある仕組みが変わったわけではありません。
ARFとDMARC：失敗レポートの解説
DMARC DNSレコードに「ruf=」タグを追加すると、自分のドメインからのものだと主張するメッセージがDMARCの検証に失敗した際に、受信メールサーバーからレポートを送信するよう要求することになります。1日分のトラフィックを1つのXML要約にまとめて報告する集計レポートとは異なり、失敗レポートは失敗が発生した直後に生成され、単一のメッセージを対象とするものです。
DMARCの失敗レポートには、集計レポートでは得られない情報が記載されています。具体的には、その特定のメッセージの認証結果、どのメカニズムで失敗したかの詳細、送信元に関する情報、そしてメッセージ本文またはヘッダーのいずれか（実際の送信元を追跡できるようにするため）です。こうした詳細な情報があるからこそ、失敗レポートは（実際にレポートを受信できた場合に限りますが）なりすまし攻撃をほぼリアルタイムで検知するのに役立ちます。これについては、次のセクションで詳しく説明します。
RFC 9991による変更点（2026年版）
2026年5月、IETFは、元のRFC 7489に代わる一連の新しいDMARC文書、すなわちRFC 9989（コアDMARC）、RFC 9990（集計／RUAレポート）、およびRFC 9991（失敗／RUFレポート）を公開しました。これら3つの文書により、RFC 7489は廃止されました。 失敗レポートに関して実際に変更された点は以下の通りです：
- RFCの体系に変更がありました。RFC 9991では、障害報告に関する規定が盛り込まれ、RFC 7489の障害報告に関するセクションは廃止されました。また、RFC 6591（AFRF）についても、必須フィールドをより詳細に規定する形で更新されています。
- ARFのワイヤ形式自体は変更されていません。RFC 5965が依然として基本となる形式です。
- 新しい必須フィールド：「Identity-Alignment」：DKIM または SPF のいずれのメカニズムが整合した識別子の生成に失敗したかをコンマ区切りで列挙したリスト。整合した識別子によって認証が成立した場合は「none」と指定されます。このフィールドは、レポートを読む人にとって最も有用な情報源となります。なぜなら、設定ミスのためなのか、あるいは完全ななりすましなのかを直接的に示してくれるからです。
- 新しい「Auth-Failure」タイプ：dmarc：一般的なSPFやDKIMの失敗とは異なり、メッセージの認証に一致する識別子が存在しなかった場合に特に使用されます。
- アラインメントの失敗を診断するための新しい必須フィールド：アラインメントされたDKIM署名の検証に失敗した場合は、DKIM-Domain、DKIM-Identity、およびDKIM-Selectorが必須となります。アラインメントされたSPFチェックに失敗した場合は、SPF-DNSが必須となります。
- 詳細情報を追加するための新しいオプションフィールド：「Delivery-Result」および「DKIM-Canonicalized-Header/Body」のペア。受信者がより詳細な診断情報を含めたい場合に利用可能です。
アイデンティティの整合性がなぜそれほど重要なのか
DMARCは、SPFやDKIMが個別に検証に合格したかどうかを実際に確認しているわけではなく、認証された識別子が、表示されている「From:」アドレスのドメインと一致しているかどうかを確認しています。メッセージは、技術的にはSPFとDKIMの両方が検証に合格していても、どちらも「From:」ドメインと一致していない場合、DMARCの検証に失敗することがあります。このフィールドは、その点を明確に示しています。
RUA 対 RUF：集計レポート 対 障害レポート
| RUA（集計値） | RUF（失敗） | |
|---|---|---|
| 形式 | XML | ARF |
| 周波数 | 通常は毎日 | メッセージ単位のニアリアルタイム |
| コンテンツ | 送信元IPアドレスごとの集計結果と結果の概要 | 特定のエラーメッセージに関する詳細情報 |
| プライバシーの侵害 | 低 | 高 |
| 受信機間の採用 | 幅広い | 限定 |
| 定義されている場所 | RFC 9990 | RFC 9991 |
推奨事項（前回と同様）
DMARCレコードでは、必ず「rua=」を設定してください。主要なメールプロバイダーはDMARCアグリゲートレポートを広くサポートしており、認証状況を監視するために必要な日々の可視性を提供しています。「ruf=」の設定は任意であり、追加の診断情報を得ることができますが、多くの受信側はフォレンジックレポートを送信しないため、これらは補助的なデータソースとして扱うようにしてください。
ARFレポートの読み方（項目ごとの例）
以下は、ダイレクトドメインスプーフィング（攻撃者が有効なSPFやDKIMを設定せずに、あなたのドメインを装ってメールを送信するケース）におけるDMARC失敗レポートの例です。
Feedback-Type: auth-failure Version: 1 User-Agent: MailReceiver/2.1 Auth-Failure: dmarc Identity-Alignment: dkim, spf Original-Mail-From: <[email protected]> Reported-Domain: yourdomain.com Source-IP: 198.51.100.44 SPF-DNS: v=spf1 include:_spf.yourdomain.com ~all Authentication-Results: mx.receiver.example; dmarc=fail (p=reject) header.from=yourdomain.com; spf=fail smtp.mailfrom=spoofed-source.net; dkim=none Arrival-Date: Wed, 22 Jul 2026 09:14:02 +0000
最も大切な野原を歩きながら：
- 「フィードバックの種類：auth-failure」という表示から、これはスパムや不正利用の報告ではなく、認証に関する問題であることが確認できます。
- 認証失敗：dmarcによると、この失敗は具体的には RFC 9991 で導入されたタイプの DMARC アラインメントの失敗であるとのことです。
- IDの整合性：dkim、spfが重要な診断項目です。どちらのメカニズムも整合した識別子を生成できず、これに加え、有効なDKIM署名が存在せず、SPFチェックにも失敗していることから、これは貴社側の設定ミスではなく、明らかななりすましである可能性が極めて高いと考えられます。
- 「Source-IP」と「Original-Mail-From」は、メッセージが実際にどこから送信されたかを示しており、ブロックリストへの登録やさらなる調査に役立ちます。
- 「Reported-Domain」は、どのドメインが標的となったかを確認できる機能で、複数のドメインを管理している場合に便利です。
- SPF-DNSには、受信側が評価に使用したSPFレコードが表示されます。これにより、自身のレコードが正しく読み取られたかどうかを確認することができます。
もしこれが、承認するのを忘れていた正当なサードパーティの送信者だった場合、通常は「Identity-Alignment」の項目に1つのメカニズムのみが表示され、もう一方は「合格」と表示されるため、これは攻撃ではなく設定の修正が必要であることを示唆しています。
失敗レポートが届かない可能性がある理由
ruf=を設定したにもかかわらず、レポートがまったく表示されない、あるいはごくわずかしか表示されない場合、それにはいくつかの正当な理由が考えられます：
1. 大手プロバイダーの多くは、それらを送ってこない
ほとんどのドメインにとって最大の受信メール源であるGmailやYahooは、通常、配信失敗レポートを生成しません。
2. プライバシーと情報の黒塗り
エラー報告には、メッセージのヘッダーや本文に含まれる個人情報が含まれている可能性があり、これにより送信者はGDPRやCCPA上のリスクにさらされることになります。RFC 6590では、不正利用報告から機密データを削除することについて規定されていますが、その削除処理を行うと、そもそもその報告が有用であった理由の多くが失われてしまう可能性があります。
3. 外部の宛先は確認が必要です
ruf=アドレスが自組織のドメイン外を指している場合、RFC 9991では、受信側がその宛先に何かを送信する前に、外部宛先検証チェック（RFC 9990で集計レポートについて定義されているのと同じ仕組み）を実行することが義務付けられています。この認証レコードが設定されていないと、レポートは届きません。
4. レート制限が発生する見込みです
RFC 9991では、報告者に対し、特定の受信者1人に対して送信する障害報告の数を制限するよう求めています。これは、受信箱への過剰な送信を防ぐためであると同時に、報告のループを防ぐためでもあります。
5. 不具合がなければ、報告もなし
正当なメールの認証が問題なく行われているのであれば、そもそも失敗レポートが送信されるような要因は存在しません。
6. foタグの設定
fo=タグは、レポートがいつ生成されるかを正確に制御します。fo=0（デフォルト）は、SPFとDKIMの両方が失敗または不一致となった場合にのみレポートを生成し、fo=1はどちらか一方が失敗した場合にレポートを生成し、fo=dはDKIMの失敗についてのみレポートを生成し、fo=sはSPFの失敗についてのみレポートを生成します。実際に有用な診断情報を得たいと考えるドメインの多くは、fo=1を設定しています。
電子メールによるフィードバックループとARF
ARFが登場するのは、エラー報告だけではありません。ISPのフィードバックループ（Yahoo!の「Complaint Feedback Loop」 やMicrosoftの「JMRP/SNDS」プログラムなど）でも、まったく同じARF形式が使用されています。ただし、Feedback-Typeが「auth-failure」ではなく「abuse」に設定されている点が異なります。
これらのレポートは、受信者がメッセージをスパムとしてマークした際に生成され、DMARCとはまったく関係がないものの、配信性の問題を示す有用な早期の兆候となります。
ドメインのARF／障害報告を設定する方法
ご自身のドメインに関する障害報告の収集を開始したい場合は：
1. 専用のメールボックスまたは報告用アドレスを指すように、DMARC DNSレコードに「ruf=」タグを追加してください。
2. SPFまたはDKIMのいずれかが失敗した場合のレポートも受け取りたい場合は、fo=1に設定してください。両方が失敗した場合のみレポートを受け取る設定とは異なります。
3. ruf=アドレスが組織のドメイン外にある場合は、外部宛先認証レコードが正しく設定されていることを確認してください。そうしないと、受信者はその宛先に何も送信しません。
4. 主要なISPのフィードバックループプログラムには、それぞれ個別に登録してください。これらはDMARCの枠組みとは全く別個に運用されているためです。
5. これらを手作業で大量に読み込むことは想定しないでください。たとえ少量のメールであっても、手作業で解析するには現実的ではないほどの量の未加工のARFレポートが生成される可能性があります。こうした場合、自動化されたDMARCレポート解析ツールが作業を簡素化してくれます。
まとめ
障害レポートは、DMARCにおけるARFの具体的な活用例の一つです。RUFはメッセージの受信時にメッセージごとの詳細な情報を提供しますが、受信者のかなりの割合がこれを送信していないため、集計（RUA）レポートが、日常的に信頼できる可視性の情報源となります。 RFC 9989、RFC 9990、およびRFC 9991を通じてDMARC規格が正式に策定された今、用語や詳細を正確に把握することは、これまで以上に重要になっています。特に、単なる設定ミスではなく、実際のなりすましインシデントのトラブルシューティングを行う場合には、その重要性がさらに高まります。
初めてレポート設定を行う場合や、生のARFメッセージを自分で解析せずにこのデータを確認したい場合は、当社のDMARCレポートアナライザーがまさにそのニーズに対応しています。今すぐ無料トライアルに登録して、複雑な作業なしにレポートを確認しましょう！
よくあるご質問
DMARC失敗（フォレンジック）レポートとは何ですか？
これは、電子メールがDMARC認証に失敗した際に生成される、メッセージごとのARFレポートです。このレポートには、どの認証メカニズムが失敗したか、また「From:」ドメインと一致する識別子が生成されたかどうかなど、そのメッセージに関する詳細情報が含まれています。「フォレンジックレポート」とは、RFC 7489から引き継がれた、これと同じものを指す旧称です。
DMARCにおけるRUAとRUFの違いは何ですか？
RUA（集計）レポートは、あるドメインから受信されたすべてのメールを網羅する日次XML要約レポートであり、現在はRFC 9990で定義されています。RUF（失敗）レポートは、送信に失敗した個々のメッセージに関するほぼリアルタイムのARFレポートであり、RFC 9991で定義されています。RUAは広くサポートされていますが、RUFはオプションであり、送信状況は一貫していません。
DMARCの失敗レポートは誰が送信するのですか？
そもそもこれらを生成する受信サーバーはごく一部に限られており、GmailやYahoo!メールなどの主要なメールサービスプロバイダーは、一般的に生成しません。対応状況は受信サーバーによって異なり、プライバシー上の懸念、レート制限の要件、およびRFC 9991に基づく宛先検証ルールなどが相まって、実際に届く頻度はさらに低下しています。
ARFとXARFの違いは何ですか？
ARF（RFC 5965）は、DMARCの失敗レポートやISPのフィードバックループで広く使用されている、IETFで標準化されたフォーマットです。XARFは、解析を容易にするためにJSONペイロードを追加した、ベンダー独自の拡張仕様です。これはIETFの標準ではなく、主要なプロバイダーによるDMARCレポートには使用されていません。
なぜDMARCの失敗レポートが届かないのでしょうか？
考えられる原因としては、レポートを生成しない主要なプロバイダーへの送信、プライバシー保護のための情報削除によりレポートの内容が削られていること、ruf=アドレスがドメイン外の場合に外部宛先検証レコードが欠落していること、受信側での強制的なレート制限、あるいはそもそも報告すべき認証失敗が発生していないことなどが挙げられます。また、fo=タグの設定によって、レポートがいつトリガーされるかが決まります。
ドメインおよびメールセキュリティの専門家（所属： PowerDMARC
AhonaはPowerDMARCのマーケティングマネージャーで、サイバーセキュリティのトピックについて5年以上の執筆経験があり、ドメインと電子メールのセキュリティを専門としている。ジャーナリズムとコミュニケーションの卒業後学位を取得し、2019年からセキュリティ分野でキャリアを固めている。
最新記事 by Ahona Rudra(全て見る)
- ARFとは？ 不正利用報告フォーマットとDMARC失敗レポート（RFC 5965） - 2026年7月24日
- ほとんどの金融機関がDMARCを導入しているが、保護されているところはほとんどない。 - 2026年7月22日
- MFA疲労（プッシュ・ボンビング）とは何か？ - 2026年7月21日
