摘要

  • RFC 9991 允许 Domain Owner 请求详细的 DMARC 失败反馈；Mail Receiver 仍依据自身政策决定是否生成、生成哪一类报告，以及允许哪些数据出站。
  • 外部目的地验证只证明对方同意接收这组报告关系，不等于正文、地址、附件、留存期限和后续用途都已获得批准。
  • 可审计的控制链必须把认证失败、DNS 请求、披露决定、最小化、投递、报告验证和最终处置分开记录。

“系统发现失败”与“系统发送原文”之间，至少隔着一次授权判断。

设想一封正常的项目邮件经过转发服务。转发改变了 DKIM 覆盖的内容，SPF 看到的又是转发方路径，于是最终接收系统得到 DMARC fail。邮件可见发件域发布了 ruf，指向一家外部分析商。如果系统按模板直接生成详细报告，项目内容、收件人、Received 链和此前未知的最终目的地都可能离开接收方。

失败可以是真的，报告请求也可以是真的。两者相加，仍不足以回答“这批字节能否交给这个人”。

RFC 9991 先承认接收方会说“不”

RFC 9991 于 2026 年 5 月作为 IETF Standards Track 文档发布。它定义 DMARC failure report，可针对一封失败邮件，也可合并同一失败原因的多封邮件，并比按日聚合报告更快地给出细节。

请求来自 RFC 9989 所规定的 ruf 与 fo。Domain Owner 可以公布希望接收失败报告的 URI，以及在什么失败组合下提出请求。

这里的动词是“请求”。RFC 9991 明确把报告生成写成两个条件：域名一方提出取证需求，Mail Receiver 愿意提供。接收方还要根据自己的政策、实际失败和 fo 决定发送哪一种报告，或者根本不发送。

这不是模糊，而是准确分工。Domain Owner 最了解哪些发信系统属于自己，接收方则持有邮件、服务收件人、承担出站披露责任。协议可以让双方协作，不能让一方通过 DNS 记录接管另一方的数据判断。

逐封报告改变了证据的敏感级别

RFC 9990 的 aggregate report 按时间区间与元组汇总来源 IP、数量、对齐结果、策略和本地 override。它适合发现趋势，并不复制每封通信。

RFC 9991 使用 Abuse Reporting Format 的认证失败形式。RFC 5965 把 ARF 组织为人类可读说明、机器字段，以及原始邮件或完整头部。RFC 6591 提供认证失败字段，RFC 9991 再增加 DMARC 所需的对齐信息。

细节提高了诊断能力，也改变了出站数据的性质。头部可以暴露通信双方、投递路径和最终目的地；正文可能含未公开产品、解雇通知、法律意见或日历信息；邮件列表失败还可能暴露成员身份。

更关键的是，失败不等于滥用。转发、邮件列表、配置失误、DNS 暂时异常和未经授权的冒用都可能进入同一大类。即使攻击者确实冒用了域名，无辜收件人的地址和私人上下文也不会因此自动成为必需证据。

RFC 9991 因而强烈建议把 failure reporting 限定在有目标、有限时长的诊断活动中，仔细控制 URI，删减或编辑正文与头部，并使用安全传输。文档还指出，许多大型服务商限制或完全关闭这类报告，优先选择不会暴露邮件内容的 aggregate report。

领导层应把报告做成阶梯：先用聚合；确有需要时发送最小元数据；再到选择性头部；只有在限定案件、抽样、审批与短期窗口内，才考虑更多内容。ruf 不能把所有阶梯压成“发送完整信件”。

外部验证解决“愿不愿收”，不解决“可以看什么”

ruf 可以指向 Organizational Domain 之外的服务商。RFC 9991 要求使用 RFC 9990 的外部目的地验证流程，只是把 aggregate 的 rua 替换为 failure report 的 ruf。

这一机制防止域名一方单方面把第三方登记为收件人，也防止攻击者借大量 Mail Receiver 向某个受害地址反射报告。外部域必须公布相应授权，才算同意承担这段报告关系。

但 DNS 验证的结果非常窄。它没有说明服务商能看哪些字段，是否允许员工读取正文，是否会把地址再次转发，数据保存多久，是否进入画像、模型训练或自动封禁系统。

所以必须另有可核验合同：请求域、接收域、真正的 Report Consumer、允许字段、目的、采样、地域、人员、下游处理者、留存、删除与事故义务。DNS 记录要与这份清单吻合，却不能取代它。

Public Suffix Domain 的规则更能说明问题。带 psd=y 的 DMARC Policy Record 即使包含 ruf，没有有关各方的特定协议也不得采用。层级位置带来的覆盖面不是收集从属域详细通信的授权。

Identity-Alignment 是机制结果，不是人的身份结论

RFC 9991 增加 Identity-Alignment 字段。IANA MARF Parameters 当前登记的含义是：列出未能认证 aligned identity 的机制；若所有尝试都成功，则写 none。

它能准确告诉分析者：DKIM、SPF 或两者在哪个对齐判断上失败。它不能回答谁写了信、是否蓄意欺诈、哪个员工应负责，也不能排除合法转发破坏了签名。

中文界面若把这个字段缩成“身份失败”，会把域名比较偷换为个人定罪。系统应保留完整字段名、评估域、方法、接收方、时间和原始结果，并把人员归因留给另一条证据链。

脱敏还可能制造新的稳定标识符

RFC 6590 给出一种保持可关联性的脱敏方法。相同私密字符串经一致转换后仍得到相同替代值，Report Consumer 因而可以识别多份报告是否涉及同一未知用户。

这种实用性本身就是权力。长期不变的 token 会变成跨报告身份。转换密钥、轮换周期、适用域和允许的关联目的决定了消费者能够积累什么。

而且脱敏不等于匿名。Message-ID、时间、少见主题、Received 路径或另一方日志都可能重建原始身份。自然语言里的名字、病情、项目和人际关系也无法被通用程序全部识别。RFC 6590 正面承认这个限制。

因此不能只存 redacted=true。审计应记录字段清单、删除与转换规则、算法、key epoch、关联窗口、语言测试、残留标识符和批准人。如果无法得到与目的相称的报告，改用 aggregate 或不发，都是合规且技术上诚实的结果。

报告是声明，也可能是攻击载荷

RFC 5965 警告，ARF 字段是报告生成方的声明，并不必然可验证。格式正确不等于事实正确；来源可信也不等于解释无误。一份合法来源的报告仍可能含恶意附件、钓鱼链接或错误的派生字段。

Report Consumer 在自动处置前必须验证报告关系、来源、结构、大小和字段一致性，隔离活动内容，再与自己的发信日志、密钥历史和账户状态交叉核对。RFC 6449 对 complaint feedback loop 的处理方式也是运营关系，而非一个公开的自动判罚入口。

RFC 9991 要求报告方实施 rate limit。否则攻击者可以大量发送冒充受害域的邮件，故意让 SPF 与 DKIM 同时失败，诱导多个接收方把报告流量打向受害域或其服务商。预算要同时覆盖请求域、目标地址、租户与全局服务，同类失败可通过 Incidents 合并。

报告还会复制垃圾、钓鱼与恶意内容。RFC 9991 建议把 HTTP 链接改为不可直接点击形式并移除附件；消费者应隔离报告流、沙箱处理、分段网络并限制人员访问。报告邮件自身也应保持 DMARC alignment，避免一封失败报告再生成下一封失败报告。

运行证据要跨越七个现实层

Heng Lu 的现实层框架在这里对应七项：认证失败、DNS 请求、接收方披露决定、报告字节、投递、消费者解释、最终处置。前一层真实，不会自动授权后一层。

最小初始规范与本地未来决策解释了为什么公共标准应统一标签、字段、目的地验证和安全失败，却不应替所有 Mail Receiver 规定相同的正文披露政策。

Running-Code Primacy要求审计实际执行：哪个 evaluator 得出失败、哪条规则允许报告、哪个 transform 改写内容、当时看到哪条 DNS 授权、发出哪个 hash、真实消费者是谁、最终哪个账户或策略发生变化。

RFC 9991 让 DMARC 诊断更及时、更精确。它的治理价值正在于没有把“发现失败”写成“获准公开”。