摘要

  • RFC 9991 规定 DMARC 失败报告如何描述一封失败邮件或一组因相似原因失败的邮件；它通常比聚合报告更及时，也可能包含更敏感的原始材料。
  • 域名所有者发布的 ruf 与 fo 是披露请求，不是取数命令。邮件接收方仍按自己的政策、失败条件、隐私判断与安全能力决定是否发送任何报告。
  • Daniel Kade 建议使用一份限于目的的失败披露凭证，记录选择、删减、分组、限流、传输、访问与删除决定，而不保存正文、地址、凭据或恶意载荷。

从一行可疑头部开始的第二次泄露

设想运维人员正在排查突然增加的 DKIM 对齐失败。聚合数据只能说明某一来源出现了问题，无法判断是签名配置错误、中间转发改写、冒名发送，还是验证时的短暂异常。一小段原始头部也许几分钟就能给出答案。

但这段头部可能同时暴露收件人、本地服务器、转发链、邮件列表成员或从未向发件域公开的关系。若报告附带完整邮件，泄露面还会扩展到合同、行程、产品计划、口令、追踪链接与恶意附件。调查所需的证据与不应跨界的数据，不是两个文件，而是同一批字节。

因此，第一次认证失败不能成为第二次信息泄露的自动理由。RFC 9991 的重要治理边界，恰恰在于它没有因为格式标准化而取消接收方的判断。标准让请求、报告与处理可以互操作；它不把私人通信的支配权一并交给域名所有者。

请求、生成与使用不是一个授权动作

RFC 9991 是 2026 年 5 月发布的标准轨规范。它与新的 DMARC 核心规范、聚合报告规范共同取代 RFC 7489 的相关安排，并更新了较早的认证失败报告规则。

域名所有者在 DMARC 策略记录中填写 ruf 目的地，并用 fo 说明关心哪些失败条件。这表示“希望收到”，不表示“必须交付”。邮件接收组织仍根据实际失败、请求选项、自身政策和适用义务，决定发送哪些报告——也可以一个都不发送。

这条链至少包含三个自主决定。域名所有者决定是否请求以及把请求指向哪里；接收方决定是否披露、删减到何种程度；报告消费者决定谁能查看、如何分析、保留多久、是否转交。前一环的成功只满足前一环的条件，不能替后一环签字。

失败报告可能针对单封邮件，也可能把相似原因的事件归为一组，并且接近实时地抵达。速度可以缩短修复时间，也会压缩隐私复核、目的地确认与隔离恶意内容的时间。好的自动化必须保留这些决定的边界，而不是把所有绿灯折叠成一次“允许”。

详情增加后，证据类别也改变了

滥用报告格式把人类可读说明、机器可读反馈字段与原始消息材料放在不同的 MIME 部分。RFC 9991 为 DMARC 增加具体语义，包括 Identity-Alignment、有关 DKIM 的细节、SPF 的 DNS 信息和认证失败类型。

Identity-Alignment 的含义很窄。它列出没有认证出对齐身份的机制；如果尝试过的机制都成功，则可以写明 none。它不解释签名为何失败，不证明表面发件人确实发送了邮件，不判断内容是否恶意，也不证明接收方之后的处置或披露具有正当性。

原始头部或正文能回答派生字段无法回答的问题，但也会带入诊断目的之外的事实。一旦复制进报告，原本只在邮件系统内存在的信息就多了一个保管者、一套访问权限与一个新的保留时钟。“取证”可以说明目的，却不能把所有材料变成无限制的数据类别。

外部目的地愿意接收，不等于有权获得全部内容

策略记录可以把报告送往组织域之外。RFC 9991 沿用聚合报告的外部目的地授权程序：目的地需要通过 DNS 表示愿意为请求域接收报告。这个检查阻止域名所有者单方面把大量报告导向不知情的第三方。

它很必要，但证明范围有限。它不证明每份报告准确，不证明每个字段都必要，不证明消费者有法律或合同依据，也不保证数据不会继续转发。规范还明确提醒，看起来在组织内部的目的地本身也可能把报告送往外部；读取公开地址并不能确定最终落点。

所以，系统需要分别回答两个问题：这个地址是否有资格作为报告目的地？这一次具体披露是否合乎比例？把两者合并，就会把“愿意收某些报告”误写成“有权得到生成方碰巧拥有的所有内容”。

最小化不是把报告处理到毫无用处

RFC 9991 建议限制请求的目的与持续时间，严格控制报告 URI，对正文和头部做删减，并采用安全传输。它也承认，许多大型服务商因真实的隐私成本而限制或关闭失败报告。

删减也不等于删除。RFC 6590 描述了一种一致且抗碰撞的转换方法，使消费者能够判断两个被遮蔽的字符串原本是否相同，而无需看到原值。这保留了跨报告归组能力，也保留了可关联性。如果同一密钥与转换长期跨目的使用，匿名标记会逐渐成为稳定的关系索引。

负责的实现需要记录转换版本和适用范围，按目的隔离或轮换密钥，并阻止原值与删减值进入同一片宽泛日志。若调查根本不需要跨事件关联，就不应默认生成长期稳定的标记。有时最小充分披露是一种失败类别，有时是一次性的案件编号，有时则是不发送报告。

最小化必须围绕具体诊断问题验收。删得不够，私人通信不必要地跨越组织边界；删得过多，报告虽然无助于排错，却仍产生接收、解析和存储风险。不存在永远正确的字段清单，只有可复核的目的与选择。

限流让“没有报告”变得多义

失败报告本身可以被武器化。攻击者大量发送冒用受害域名的邮件，就可能诱使参与接收方把报告流量送向受害者或其受托方。RFC 9991 因而要求生成方限流，并允许合并相似事件或丢弃超限报告。目标是揭示不同失败条件，不是逐封精确计数。

这也意味着，消费者不能把失败报告流当成完整事件账本。沉默可能代表没有符合条件的失败，也可能代表接收方不参与、隐私政策阻止披露、报告已被分组、触发限流、传输失败，或诊断窗口已经到期。突然增量可能是新故障，也可能是政策变更或人为制造的洪水。

消费者在解释数量前，需要知道生成方声明的分组与限流背景。生成方则需要保留被抑制原因的本地摘要，而不是为了解释丢弃行为又建一套敏感的逐封档案。按有限时间窗和原因记录计数，往往已经足够。

报告也是不可信输入

失败报告可能重现垃圾邮件、钓鱼内容、恶意软件、欺骗链接和附件。规范建议把处理环境隔离、沙箱化和分段，只允许受过训练且获授权的人员访问。若消费者把报告直接放进普通邮箱、工单预览或全局搜索，就可能扩大原本要调查的事件。

让报告流自身通过并对齐 DMARC，可以把传输身份绑定到预期发信域，却不能使嵌入内容自动安全，不能证明机器字段中的每个判断，也不能赋予所有分析者查看原始邮件的权利。身份认证、内容安全、数据资格与操作访问是四种控制。

最有价值的自动化常常表现为拒绝：移除活动内容，拒收不支持的 MIME 结构，隔离附件，限制解压与解析资源，不让报告进入通用检索。解析成功只是受控保管的起点，不是披露决定的终点。

一份限于目的的失败披露凭证

我建议为披露政策以及每次例外释放生成一份紧凑凭证。这是治理建议，不是给 IETF 规范添加新要求。

凭证首先记录 DMARC 策略域、DNS 查询时间与结果、请求的 ruf 目的地和 fo 条件、外部授权结果、接收方政策版本，以及用途和到期日。随后标明失败类别、单案或分组属性，并只列出被选择的数据类别——例如派生认证字段、有限的跟踪头部、删减后的地址标记或受限消息片段，而不复制数据本身。

凭证还应保存删减算法版本、关联范围、归组规则、限流结果、安全传输结果与生成错误。在消费端，它要把角色、访问边界、隔离结果、保留期限、删除或被替代事件绑定到可问责的决定。

它绝不能变成影子邮箱。正文、地址本地部分、收件人地址、凭据、可点击的恶意链接与附件都应留在凭证之外。内容指纹也只能在风险与用途确实需要时使用，并且必须有明确范围与失效时间。

这样，当未来有人问“为什么这些字节越过了这条边界”，答案就不会只是“因为 DNS 提出了请求”。它会是一条能够复核的本地决定链。

来源

  1. Lu Heng：数据主权的技术现实与实际现实
  2. Lu Heng：BTW Media 为何存在
  3. Lu Heng：政策之镜
  4. IANA：邮件滥用报告格式参数
  5. RFC 9991 信息页
  6. RFC 5322：互联网消息格式
  7. RFC 5965：可扩展邮件反馈报告格式
  8. RFC 6590：邮件滥用报告敏感数据删减
  9. RFC 6591：使用 ARF 报告认证失败
  10. RFC 6650：邮件反馈报告的创建与使用
  11. RFC 7489：DMARC
  12. RFC 9989：DMARC
  13. RFC 9990：DMARC 聚合报告
  14. RFC 9991：DMARC 失败报告