← RFC Reference

RFC 6591: 認証失敗レポート (AFRF)

これが存在する理由

SPF、DKIM、DMARCなどのメール認証メカニズムは、偽装またはリマーク許可のないメッセージを検出します。これらのチェックが失敗すると、受信サーバーはアクション(拒否、隔離、または許可)を実行します。しかし、ドメイン所有者(偽装される側)は以下の目的でこれらの失敗について知る必要があります：

• ドメインの無許可使用を検出する(フィッシング、偽装)
• 誤設定された正規送信者を識別する(例：DKIMで署名していないマーケティングプラットフォーム)
• 認証レコードの問題をデバッグする(壊れたSPFインクルード、間違ったDKIMキー)
• DMARCをp=rejectに切り替える前に攻撃パターンの全体像を構築する

DMARCアグリゲートレポート(rua)は統計的なサマリーを提供しますが、メッセージの詳細は含まれません。DMARCフォレンジックレポート(ruf)はこのRFCで定義されたAFRF形式を使用して、メッセージごとの詳細を提供します：実際のヘッダー、認証結果、および特定の失敗理由です。

RFC 6591はRFC 5965 (ARF)を拡張し、Feedback-Type: auth-failureレポートタイプを追加し、認証固有データの追加フィールドを定義しています。

仕組み

AFRFレポートはARFメッセージ(multipart/reportでreport-type=feedback-report)で、マシン可読部分はFeedback-Type: auth-failureを使用し、認証固有フィールドを含みます。

AFRFレポートの例

From: dmarc-reporter@receiver.example.com
To: dmarc-ruf@example.com
Subject: Auth failure report for example.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
    boundary="AFRF-BOUNDARY-001"

--AFRF-BOUNDARY-001
Content-Type: text/plain

Authentication failure report for a message claiming
to be from example.com, received from IP 192.0.2.55.

--AFRF-BOUNDARY-001
Content-Type: message/feedback-report

Feedback-Type: auth-failure
User-Agent: Receiver-DMARC/2.0
Version: 1
Original-Mail-From: spoofed@example.com
Arrival-Date: Tue, 10 Mar 2026 16:42:00 -0500
Source-IP: 192.0.2.55
Auth-Failure: dmarc
Authentication-Results: receiver.example.com;
    dkim=fail header.d=example.com;
    spf=fail smtp.mailfrom=spoofed@example.com;
    dmarc=fail header.from=example.com
Reported-Domain: example.com
DKIM-Domain: example.com
Delivery-Result: reject

--AFRF-BOUNDARY-001
Content-Type: text/rfc822-headers

From: ceo@example.com
To: finance@receiver.example.com
Subject: Urgent wire transfer needed
Message-ID: <fake-msg-001@192.0.2.55>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
    s=selector1; b=INVALID...

--AFRF-BOUNDARY-001--

主要な技術詳細

RFC 6591により追加されたフィールド

これらのフィールドは、標準ARFフィールドとともにmessage/feedback-report部分に表示されます：

Auth-Failure値

DMARCレポートとの関係

DMARC(RFC 7489)はそのDNSレコードで2つのレポートアドレスを定義します：

• rua——アグリゲートレポート(XML)。すべてのメッセージにわたる認証結果の統計的なサマリー。
• ruf——フォレンジックレポート。このRFCで定義されたAFRF形式を使用したメッセージごとの詳細。

実際には、rufを介したフォレンジックレポートの採用は限定的です。多くの大手メールボックスプロバイダー(Gmail、Yahoo)はプライバシー上の懸念からフォレンジックレポートを送信しません。送信するプロバイダーでも、メッセージ本体と受信者アドレスを多くの場合マスキングしています。アグリゲートレポート(rua)がDMARCフィードバックの主要なソースのままです。

一般的な間違い

• すべてのレシーバーからのフォレンジックレポートを期待する。ほとんどの大手メールボックスプロバイダーはAFRFレポートを送信しません。rufをあなたの唯一の認証失敗データソースとしてに依存しないでください。DMARCアグリゲートレポート(rua)は、はるかに広くサポートされています。
• AFRFとARF不正報告を混同する。どちらもmultipart/reportとreport-type=feedback-reportを使用しますが、異なるFeedback-Type値があります。auth-failureレポートは認証チェックが失敗したことを意味します。abuseレポートはユーザーが「スパムを報告」をクリックしたことを意味します。異なる方法で処理してください。
• Auth-Failureフィールドを無視する。Auth-Failureフィールドは、どのチェックが失敗したかを正確に示します。dkim失敗は署名の問題を示唆します。spf失敗はあなたのSPFレコードで不足しているIPを示唆します。dmarc失敗はメカニズムも整合していないことを意味します。
• rufアドレスを公開しない。ほとんどのレシーバーはそれを使用しませんが、いくつかの小さなプロバイダーとエンタープライズゲートウェイはフォレンジックレポートを送信します。DMARCレコードにrufを含めるのはコストがかからず、有用なデータが得られる可能性があります。
• フォレンジックレポートをバウンスとして扱う。認証失敗レポートは、メッセージが配信されなかったことを意味しません。Delivery-Resultフィールドを確認してください——メッセージは失敗にもかかわらずスパムフォルダに配信された可能性があります。

配信可能性への影響

• スプーフィングキャンペーンの早期検出。誰かがあなたのドメインでフィッシングしている場合、AFRFレポート(利用可能な場合)は偽造メッセージの特定のヘッダーと送信元IPを提供し、より高速なインシデント対応を可能にします。
• 認証の誤設定のデバッグ。特定のセレクターとドメインを使用したAuth-Failure: dkimを示すフォレンジックレポートは、どのDKIMキーまたは署名設定が壊れているかを正確に示します。
• 安全なDMARCロールアウト。p=noneからp=quarantineまたはp=rejectに移行する場合、フォレンジックレポートは、認証に失敗している正規送信者を特定するのに役立ち、これらのメッセージがブロックされ始める前に。
• アグリゲートデータの補完。DMARCアグリゲートレポートは、IP 192.0.2.55から50個のメッセージが認証に失敗したことを示します。フォレンジックレポートは、これらのメッセージの1つの実際のヘッダーを表示し、フィッシュであるか、誤設定された正規システムであるかを明かします。

Related RFCs