RFC 6652: SPF 身份验证失败报告

Current Standard Abuse Reporting & Feedback Published March 2026

ELI5: SPF 让你声明允许哪些服务器为你的域名发送电子邮件。但是当某人未能通过检查时会发生什么——无论是冒充者还是你忘记授权的合法服务器？RFC 6652 让你发布一条 DNS 记录，说"如果我的域名 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"

记录字段

标签	含义	示例
`v`	版本（必须为`spf-report1`）	`v=spf-report1`
`ra`	报告地址本地部分（报告发送到`ra@domain`）	`ra=spf-reports` → `spf-reports@example.com`
`rp`	报告百分比（0–100）	`rp=100`（报告所有失败）
`rr`	请求报告的结果类型	`rr=all`、`rr=fail`、`rr=softfail`

示例失败报告（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字段值

值	发送时机
`spf`	SPF评估返回失败、软失败或其他非通过结果时

Auth-Failure字段用于区别SPF报告与DKIM或DMARC失败报告，这些报告也使用auth-failure反馈类型（在RFC 6591中定义）。

与DMARC报告的关系

DMARC（RFC 7489）有自己的报告机制，包含两种类型：

汇总报告（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记录。

投递性影响

识别未授权的发件人。失败报告显示哪些IP在信封发件人中使用你的域但SPF失败的邮件。这可能是欺骗或遗忘的合法服务。
支持SPF记录优化。在将你的SPF策略从~all收紧到-all之前，失败报告帮助你识别任何未授权的合法发件人。
补充DMARC报告。虽然DMARC汇总报告告诉你通过/失败比例，RFC 6652法医报告为你提供单个失败的具体头和源IP——对调查新欺骗活动至关重要。
转发破坏的早期警告。当邮件列表或转发服务中继你的消息时，SPF将失败，因为转发服务器的IP不在你的SPF记录中。失败报告帮助你识别这些情况，以便调整你的身份验证策略（例如，对转发的邮件依赖DKIM）。