DMARC 故障报告协议更新：RFC 9991 中文解读

RFC 9991 / Standards Track / 2026 年 5 月发布

2026-07-28 · ztpop.net 邮件技术知识库

一、概述

RFC 9991（Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting）是 DMARCbis 套件中的第二份规范文档，专门定义了 DMARC 故障报告（Failure Reports）的格式、生成规则和传输机制。故障报告在业内常被称为取证报告（Forensic Reports），其作用是当某封邮件未通过 DMARC 验证时，邮件接收方向域名所有者发送详细的失败原因报告，帮助域名所有者诊断并修复认证配置问题。

RFC 9991 替代了 RFC 7489 中关于故障报告的相应章节（Section 7.2 和 Section 11.3），并进行了大幅度的格式和流程修订。该文档与 RFC 9989（DMARC 核心规范，替代 RFC 7489）和 RFC 9990（聚合报告，Aggregate Reporting）共同组成 DMARCbis 标准套件。

在 RFC 7489 时代，故障报告因隐私安全问题在实践中部署率一直不高——大多数大型邮箱提供商选择不发送故障报告，或仅发送经过高度截断的版本。RFC 9991 试图在保留故障报告诊断价值的同时，通过引入更严谨的格式规范和隐私保护机制来提升其实用性。

二、核心变更

2.1 故障报告格式更新：IODEF + ARF

RFC 9991 将故障报告格式从 RFC 7489 中松散定义的 XML 格式，升级为整合 IODEF（Incident Object Description Exchange Format，RFC 5070）和 ARF（Abuse Reporting Format，RFC 5965）两种国际标准格式的正式消息结构。

2.1.1 为何选择 IODEF + ARF？

IODEF 是 CERT/CSIRT 社区广泛使用的事件描述标准格式（XML Schema），适用于描述网络安全事件。ARF 则是 IETF 定义的反馈报告格式（基于 MIME 消息头扩展），专门用于邮件相关的事件报告。二者结合的优势在于：

• IODEF 提供结构化的事件描述能力——时间戳、分类、影响评估、联系信息等头部字段
• ARF 提供邮件特有的负载封装——原始邮件头、消息体截断、认证结果等邮件领域元数据
• 两者的 JSON 扩展——IODEF 自 RFC 9427 起支持 JSON 序列化，ARF 格式本身支持 JSON 编码，使故障报告可以以 JSON 形式生成和传输

RFC 9991 没有强制要求使用 XML 还是 JSON，而是要求实现至少支持一种序列化格式（SHOULD），并建议同时支持 XML 和 JSON 以便于互操作。

2.1.2 故障报告报文结构

RFC 9991 定义的故障报告由以下层次构成：

1. 外层 MIME 封装——使用 multipart/report 媒体类型，与 RFC 5965（ARF）一致
2. IODEF 文档（Incident 对象）——包含事件描述、系统分类、影响等级、相关时间线等
3. ARF 消息块——包含送达的邮件头截断内容（或完整邮件，由域名所有者策略决定）、认证结果（Authentication-Results 头）、DMARC 对齐信息等
4. 新增的 Identity-Alignment 块——携带 DMARC 认证失败的细节，包括对齐信息

2.2 新增 Identity-Alignment 字段

Identity-Alignment 字段是 RFC 9991 对故障报告最重要的新增内容，也是 DMARC 规范首次在故障报告中以结构化方式记录对齐结果。

该字段置于 ARF 消息块中，作为 Identity-Alignment 头字段出现，其定义如下：

Identity-Alignment: dmarc=pass; spf=pass; dkim=pass; adkim=s; aspf=r;

字段组件说明：

• dmarc：DMARC 验证结果（pass / fail）
• spf：SPF 验证结果（pass / fail / none）
• dkim：DKIM 验证结果（pass / fail / none）
• adkim：DKIM 对齐模式（s=strict / r=relaxed）
• aspf：SPF 对齐模式（s=strict / r=relaxed）
• header_from：RFC5322.From 域
• mailfrom：RFC5321.MailFrom 域
• dkim_domain：DKIM 签名域（如有多个签名则为列表）

这一字段的引入使故障报告不再只是一个"某某域名验证失败"的模糊消息，而是精确到是哪个认证机制失败、失败在哪一层对齐，极大地加速了域名所有者的根因分析。

2.3 Delivery-Verification 提交机制

Delivery-Verification 是 RFC 9991 定义的新的故障报告传输验证机制，解决了 RFC 7489 时代故障报告依赖 ruf（Reporting URI for Forensic）标签直接包含原始邮件导致的隐私问题。

Delivery-Verification 的工作流程如下：

1. 报告生成方（邮件接收方）将要发送的故障报告内容（包含消息头部摘要和评估结果）提交到一个中间验证服务器
2. 验证服务器根据 DNS 中配置的验证记录确认故障报告是否由授权的接收方生成
3. 已验证的报告才会实际转发给域名所有者的故障报告接收邮箱（由 ruf 标签指定）

这一机制的引入意味着故障报告不再直接从任意邮件接收方发送给域名所有者，而是经过一个可验证的中介层，防止第三方伪造或篡改故障报告。具体来说：

• 故障报告发送方在 DNS 中发布 _dmarc._report.[domain] 的 TXT 记录，声明其报告生成身份
• 验证服务器在接收故障报告前，先查找发送域的此 DNS 记录进行验证
• 只有通过验证的报告才会被接受和转发

三、故障报告生成规则

3.1 何时生成故障报告

RFC 9991 明确了故障报告生成的触发条件：

• DMARC 验证失败：当邮件未能通过 DMARC 验证（即 SPF 和 DKIM 均不满足对齐条件）时，邮件接收方可以根据域名所有者的策略决定是否生成故障报告
• 非策略触发：即使 DMARC 策略为 none，接收方也可以选择生成故障报告——但需要在报告中标明域名所有者的当前 p 值，说明这只是信息性的
• 接收方自主决定：RFC 9991 明确指出，故障报告的生成是接收方的本地策略决策，域名所有者不能强制要求接收方生成故障报告（与聚合报告不同，域名所有者必须在 DNS 中配置 rua 才能接收聚合报告）

3.2 谁生成故障报告

故障报告由以下角色生成：

• 最终邮件接收方（Final Recipient MDA）——在完成了 DMARC 验证之后、根据邮件策略判定结果之前，负责生成故障报告的实体
• 中介邮件接收方（Intermediate MTA）——在某些架构中，中间 MTA 也可能生成故障报告（如在拒绝邮件之前），但需要确保不会与最终接收方重复生成
• 第三方报告服务商——接收方可以将故障报告生成外包给第三方服务，但需要在 DNS 中配置相应的验证记录（Delivery-Verification）

3.3 生成什么内容

RFC 9991 详细规定了故障报告的内容范围限制，旨在平衡诊断需求和隐私保护：

内容类别	包含规则	说明
原始邮件头部	必须包含 RFC5322.From 头	诊断 DMARC 失败的核心字段
其他邮件头部	建议包含 Received 链（截断至外部）	帮助追踪邮件路径
邮件正文	严禁包含（除非域名所有者明确授权）	PII 保护的核心措施
认证结果	必须包含（Authentication-Results 头）	诊断报告的核心价值
DKIM 签名头部	应包含（与验证相关的签名头部）	帮助诊断 DKIM 对齐失败
消息传输日志	建议包含（针对特定接收方的基础设施）	辅助追踪

重要警示：RFC 9991 Section 6.2 明确禁止在故障报告中包含邮件正文，除非域名所有者通过 DMARC 策略中的附加参数明确授权对特定类别的邮件进行正文报告。大多数情况下，故障报告应仅包含邮件头部字段和认证结果。

四、隐私考虑

4.1 PII 暴露风险

故障报告最敏感的隐私问题在于：它本身携带了邮件头部信息，而邮件头部（尤其是 Subject、Message-ID、From、To、CC 等字段）可能包含个人身份信息（PII）。RFC 9991 专门用 Section 6 和 Appendix B 讨论隐私问题：

• Subject 字段风险：邮件的主题行经常包含姓名、联系方式、事件描述等 PII
• 地址暴露：RFC5322.From 和 To 字段可以直接暴露通信双方的邮件地址
• 时间戳推断：Received 链中的时间戳可以推断通信双方的行为模式
• 跨域关联：故障报告中的多个域名信息可能导致跨域用户行为关联

RFC 9991 的推荐处理方式：

• 在生成故障报告时，对 Subject 和 Message-ID 等敏感字段进行截断（truncate）或哈希（hash）处理
• 仅包含确认为 DMARC 诊断所必需的最少头部字段
• 接收方应限制故障报告的分发范围，仅发送给授权的域名所有者

4.2 邮件列表泄漏风险

邮件列表是 DMARC 故障报告的典型难题——当一封来自邮件列表的投稿邮件未通过 DMARC 验证时，生成的故障报告会将原始投稿人的邮件头部发送给投稿域名所有者，从而暴露了双方均未预期的通信关系。

RFC 9991 明确警告这一风险，并建议邮件列表运营商和域名所有者：

• 域名所有者不应要求邮件列表发送故障报告
• 邮件列表应避免向不符合 ruf 配置的地址转发故障报告
• 如果域名所有者有邮件列表参与方，发布 p=reject 会导致严重问题，故障报告机制会更加恶化这一情况

4.3 Minimize 原则（最小化原则）

RFC 9991 在隐私方面最核心的指导原则是最小化原则——故障报告应仅包含为诊断 DMARC 失败所绝对必需的信息，任何超出此范围的数据都应当被剔除或截断。

具体的最小化实践：

• 头部最小化：只包含 From、To（可选）、Date（可选）、Subject（截断）、Message-ID（截断）等有限的头部字段
• 身份标识最小化：不应在故障报告中包含用户级的 IP 地址（除非是邮件来源的公开 MX 地址）
• 内容全禁止：正文内容绝不包含（除非特别授权）
• 聚合优先：域名所有者应优先使用聚合报告（RFC 9990）获取宏观趋势，仅在需要微观调试时再选择性启用故障报告

五、DNS 配置：ruf 标签变更

5.1 ruf 标签定义更新

在 DMARC DNS 策略记录中，ruf（Reporting URI for Forensic）标签仍然存在，但其语义在 RFC 9991 中有所更新：

• 格式不变：仍为 mailto: URI，可指定多个地址，以逗号分隔
• 要求宽松：RFC 9991 明确说明了所有接收方可能选择不发送故障报告到 ruf 中指定的地址
• 推荐比 RFC 7489 更明确：如果域名所有者不希望接收故障报告，可以不发布 ruf 标签（或发布后另做标记）

示例配置：
v=DMARC1; p=reject; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com;
注意：RFC 9991 不再支持 rf（报告格式）标签，因此 ruf 标签对应的报告格式始终为 IODEF + ARF，无需额外声明。

5.2 DNS 查询规则更新

与 RFC 9989 一致，RFC 9991 的故障报告涉及以下 DNS 查询规则变更：

• DNS Tree Walk 不适用于 ruf：故障报告目标地址的解析基于 Author Domain 的 DMARC 策略记录中的 ruf 标签，不执行 DNS Tree Walk 查找父域策略中的 ruf
• Delivery-Verification 查询：故障报告发送方需要查询 _dmarc._report.[sender-domain] TXT 记录以验证发送身份
• 响应处理：如果查询返回多条 TXT 记录且无法解析为有效的验证记录，发送方不应发送该故障报告

六、与中国邮件生态的关联

6.1 ARF 格式 vs 国内日志格式差异

RFC 9991 采用 IODEF + ARF 作为故障报告的标准格式，但国内邮件系统在工单环境下常用的故障追踪格式与之存在较大差异：

对比维度	RFC 9991（IODEF + ARF）	国内常见日志格式
消息结构	MIME multipart/report	Syslog JSON / 自定义 XML
身份标识	邮件域（Domain）	邮件地址 + 企业 ID
认证信息	Authentication-Results + Identity-Alignment	SPF/DKIM/DMARC 结果分离存储
隐私处理	严格禁止正文，头部截断	视系统配置，部分系统记录完整头部
传输协议	邮件（SMTP）	HTTP REST / Kafka / Syslog
序列化格式	XML 或 JSON	以 JSON 为主导

对于部署了完整邮件安全审计系统的国内企业，需要关注以下适配工作：

• 将 DMARC 故障报告格式标准化为 IODEF + ARF，以兼容国际标准的邮件诊断生态
• 在国内邮件安全审计中心中增加对 IODEF JSON 格式（RFC 9427）的解析支持
• 为跨域邮件追溯场景建立 ARF ↔ 国内日志格式的转换网关

6.2 等保 2.0 对故障追溯的要求

中国《信息安全技术 网络安全等级保护基本要求》（GB/T 22239-2019，即等保 2.0）对邮件系统的安全审计和故障追溯提出了明确要求：

• 三级及以上系统：要求对邮件通信过程进行安全审计，审计记录保存不少于 6 个月
• 四级系统：要求针对通信内容的完整性校验、抗抵赖性进行记录
• 关键信息基础设施：依据《关键信息基础设施安全保护条例》，要求对来自境外域名的邮件进行详细记录和追溯

RFC 9991 的故障报告机制与等保 2.0 审计要求的契合点：

• 故障报告中的 Identity-Alignment 字段精确记录了 DMARC 认证失败的技术原因，可作为等保审计日志的一部分
• Delivery-Verification 机制增强了故障报告的可信性，满足等保对事件来源不可否认性的要求
• 故障报告中的时间戳和 Received 链为邮件传递路径提供了完整的链路审计能力
• 但 RFC 9991 要求截断邮件正文，这与部分等保场景下"完整记录通信内容"的要求存在潜在冲突，需在合规框架内具体平衡

6.3 国产邮件系统（Coremail 等）的适配现状

Coremail 作为国内市场份额最大的邮件系统，在 DMARC 支持方面已具备基础能力，但针对 RFC 9991 的适配仍需关注以下方向：

• 故障报告生成：当前 Coremail 等国产邮件系统在 DMARC 验证失败时，多数采用内部日志记录方式而非 IODEF + ARF 标准格式输出。后续建设需要对接国际标准交换格式
• IODEF 消息体构建：需要引入 IODEF XML/JSON Schema 支持，将内部认证失败信息映射为标准 Incident 对象
• ARF 封装层：需实现 multipart/report MIME 格式的故障报告封装，包括 Authentication-Results 头部和 Identity-Alignment 字段
• Delivery-Verification 验证：需实现对 _dmarc._report 子域 TXT 记录的 DNS 查询支持
• 隐私合规：国内《个人信息保护法》（PIPL）对邮件内容隐私有限制性要求，RFC 9991 的最小化原则与 PIPL 精神一致，但国内系统在实现时需要确认具体的数据减量策略是否满足监管要求

七、总结

RFC 9991 的发布标志着 DMARC 故障报告从 RFC 7489 时期"理论上存在但实践中甚少部署"的状态，走向了标准化、结构化、隐私友好的新阶段。

对于邮件运维人员，最需要关注的变化可以概括为三点：

1. 格式彻底升级：从松散定义的 XML 到正式的 IODEF + ARF 结构，故障报告拥有了与安全事件管理（SIEM）系统和 CSIRT 团队对话的标准化"语言"
2. 新增 Identity-Alignment 字段：这一字段将 DMARC 诊断从"验证失败"的黑盒提升到"是 SPF 失败还是 DKIM 失败？对齐模式是什么？"的精确诊断层面
3. 隐私保护从可选变为强制性：RFC 9991 以相当篇幅规范了故障报告的隐私处理原则，明确要求正文禁止包含、头部截断等操作。中国的《个人信息保护法》对这一方向的要求比 RFC 更加严格，国产邮件系统在适配时需以更审慎的态度处理隐私问题

RFC 9991 并非试图让所有邮件接收方都开始生成故障报告——聚合报告（RFC 9990）仍然是 DMARC 诊断的手段。对于大多数域名所有者来说，如果聚合报告已能清晰揭示认证问题，不启用故障报告是完全合理的选择。但如果需要微调查证失败的根因，RFC 9991 提供了一套远比 RFC 7489 成熟和可操作的工具。

参考文献