← RFC Reference

RFC 6652: SPF認証失敗レポート

このページが存在する理由

SPF（RFC 7208）は、送信IPが エンベロープ送信者ドメインの認可を受けていることを検証します。SPFが失敗する場合、以下の可能性があります：

• スプーファーがあなたのドメインを詐称している
• 正当なサードパーティ送信者（マーケティングプラットフォーム、CRM）がSPFレコードから漏れている
• 転送サーバーがあなたのメールをリレーしている（SPF整合性が崩れている）
• SPFレコードに構文エラーがあるか、10ルックアップ制限を超えている

失敗レポートがなければ、これらのイベントについて何も知ることはできません。DMARC集約レポート（RFC 7489）は毎日の要約を提供しますが、RFC 6652はSPF失敗専用のメッセージごとのフォレンジックレポートを提供します。これらのレポートはARF形式（RFC 5965）を使用し、auth-failureフィードバックタイプがRFC 6591によって拡張されています。

仕組み

ドメイン所有者は_spf._report.<domain>に特殊なDNS TXTレコードを公開して、受信者にSPF失敗レポートの送信先を指定します。

DNSレコード

; SPF失敗レポートをこのアドレスに送信するよう要求
_spf._report.example.com.  IN TXT  "v=spf-report1; ra=spf-reports; rp=100; rr=all"

レコードフィールド

失敗レポートの例（ARF形式）

From: arf-generator@receiver.example
To: spf-reports@example.com
Subject: SPF failure report for example.com
Content-Type: multipart/report; report-type=feedback-report;
    boundary="SPF-REPORT-001"

--SPF-REPORT-001
Content-Type: text/plain

SPF authentication failure report for a message
claiming to be from example.com.

--SPF-REPORT-001
Content-Type: message/feedback-report

Feedback-Type: auth-failure
User-Agent: Receiver-MTA/2.0
Version: 1
Auth-Failure: spf
Authentication-Results: receiver.example;
    spf=fail smtp.mailfrom=example.com
Original-Mail-From: user@example.com
Source-IP: 198.51.100.50
Reported-Domain: example.com
Delivery-Result: reject

--SPF-REPORT-001
Content-Type: text/rfc822-headers

From: user@example.com
To: recipient@receiver.example
Subject: Important update
Message-ID: <msg-001@example.com>

--SPF-REPORT-001--

主要な技術的詳細

SPFのAuth-Failureフィールド値

Auth-Failureフィールドは、SPFレポートをDKIMまたはDMARC失敗レポート（RFC 6591で定義されるauth-failureフィードバックタイプも使用）と区別します。

DMARCレポートとの関係

DMARC（RFC 7489）には2つのタイプを持つ独自のレポート機構があります：

• 集約レポート（rua）—認証結果の毎日のXML要約。DMARCレコード内のアドレスに送信されます。
• フォレンジックレポート（ruf）—メッセージごとの失敗レポート。DMARCのフォレンジックレポートはSPFとDKIM整合性失敗の両方をカバーしています。

RFC 6652レポートはSPF固有で、DMARCに依存しません。実際には、ほとんどの受信者がDMARC集約レポート（広くサポートされている）を生成しますが、プライバシー上の懸念からRFC 6652またはDMARCフォレンジックレポートを生成することはほとんどありません。ただし、サポートされている場合、RFC 6652レポートはSPF特有の最も詳細なメッセージごとの失敗データを提供します。

プライバシーに関する考慮事項

失敗レポートには受信者アドレスとメッセージヘッダーが含まれる可能性があり、プライバシーに関する懸念があります。多くの受信者は含める内容を制限するか、これらのレポートを生成しないままです。rpタグを使用すると、ドメイン所有者はレポート量を削減するために100未満の割合を要求できます。

一般的な間違い

• 広範な採用を期待すること。実際には、ほとんどの受信者がRFC 6652レポートを生成していません。ほとんどのSPF失敗可視性はDMARC集約レポートから得られます。レポート記録を公開しますが、SPF失敗への唯一の可視性源として依存しないでください。
• レポートメールボックスを監視しないこと。レポートアドレスを公開する場合は、それを監視してください。未読レポートは価値を提供しません。レポートを自動解析するか、DMARC/SPFレポートサービスを使用してください。
• DMARCのrufレポートと混同すること。DMARCフォレンジック（ruf）レポートとRFC 6652レポートは別のメカニズムです。どちらもARF形式を使用していますが、異なるレコードによってトリガーされ、異なる受信者によって生成される可能性があります。
• 大量送信ドメインでrp=100を設定すること。数百万のメッセージを送信するドメインの場合、100%の失敗レポート要求は圧倒的な量を生成します。低い割合から始めて、必要に応じて増加させてください。
• _spf._reportプレフィックスを忘れること。DNSレコードは_spf._report.yourdomain.comにある必要があり、SPFレコード内にはありません。これはSPFポリシーとは別のTXTレコードです。

配信性への影響

• 無認可の送信者を識別すること。失敗レポートは、あなたのドメインをエンベロープ送信者に持つメールを送信しているがSPFに失敗しているIPを明らかにします。これはスプーフィングまたは忘れられた正当なサービスの可能性があります。
• SPFレコード改良をサポートすること。SPFポリシーを~allから-allに厳しくする前に、失敗レポートはまだ認可していない正当な送信者を識別するのに役立ちます。
• DMARCレポート補完するること。DMARC集約レポートは合格/不合格の比率を示しますが、RFC 6652フォレンジックレポートは個別の失敗の特定のヘッダーとソースIPを提供します—新しいスプーフィング キャンペーンの調査に重要です。
• 転送の破損に対する早期警告を提供すること。メーリングリストまたは転送サービスがあなたのメッセージをリレーする場合、転送サーバーのIPがSPFレコード内にないためSPFは失敗します。失敗レポートはこれらのケースを識別するのに役立つため、認証戦略を調整できます（例：転送されたメール用にDKIMに依存）。

Related RFCs