从行为开始，而不是替换记录
当每个实施决策都有指定的规范和负责任的所有者时，标准迁移就变得易于管理。 DNS编辑器、 结盟 引擎和聚合报告解析器不执行相同的工作。呼叫这三个“DMARC “支持”隐藏了当一个组件发生变化而另一个组件仍保留在较旧的实现上时重要的依赖关系。实际的可交付成果是组件到需求的映射，其中包含版本、接口和保留的验收证据，而不是整个资产已升级的声明。
当前的文档集于 2026 年 5 月发布。 RFC 9989 定义核心机制并废弃 RFC 7489 和RFC 9091 。 RFC 9990 涵盖汇总报告； RFC 9991 涵盖故障报告并更新RFC 6591 。新的 RFC 编辑器记录标识 RFC 9989 和 RFC 9990 作为拟议标准。已发布的RFC 9991文本标识了其标准轨道类别。这些是已发布的规范，而不是未完成的草案，但发布并不建立特定接收器的实现。
给核心引擎一个精准的合约
将记录解析、策略发现、组织域发现和标识符对齐分配给 RFC 9989第 4.7–4.10 节。作者域来自消息的 RFC5322 .来自 场地。发现的策略域可以与作者域不同，并且 组织域 用于宽松对齐是另一个显式输出。失去接口中的这些区别可能会使正确的解析器向错误的决策引擎提供信息。
DNS记录仍以v=DMARC1. “DMARCbis” 是标准工作的名称，而不是发明 DMARC2 的许可。当前的发现使用有界DNS树遍历，而不是将历史公共后缀列表检查表视为整个算法。psd、np 和 t 标签需要单独的决策覆盖。 IANA注册机构 将 pct、rf 和 ri 标记为历史记录；它不证明已部署的产品是否忽略、解释或暴露它们。
保留正常DMARC故障、不可用的DNS信息、无效策略和接收者的最终消息处置之间的区别。 RFC 9989第 4.10.1 节包含在保留语法上有效的聚合报告 URI 时对无效策略标记的特殊处理。简单化的“每一项畸形政策都将变成零”的规则将消除其条件。在执行它的解析器案例旁边记录确切的部分。
将汇总反馈视为其自身的实施
将聚合生成器、XML 验证器、报告使用者、重复处理和交付集成映射到 RFC 9990第 3-4 节和附录 A。报告接口需要实际评估的策略、身份验证结果、消息计数和报告周期上下文。显示 XML 的仪表板并不能证明上游接收者选择了正确的策略或每个相关发送者都出现在数据中。
外部报告目标应该有自己的组件行。目的地授权是一种技术性反滥用检查，不同意传输任意组织数据。将报告生成、目的地验证和访问/保留决策置于不同的验收标准之下。 RFC 9990第 7 节涉及隐私，第 8 节则对恶意或虚假报告内容发出警告。因此，解析器强化和源信任与模式有效性一起属于映射。
不要为失败报告重复使用聚合解析器
失败反馈是不同的渠道，具有不同的披露风险。 RFC 9991 管理其生成和格式，并使用引用的身份验证失败报告规范。 ruf 请求和 fo 条件不等同于 rua 聚合。接收方可以拒绝故障报告，并且没有 故障报告 并不能证明所有消息都已通过。
故障报告集成可能会遇到 消息头 或聚合管道设计不承载的内容。确定谁可以请求它、可以将其发送到哪里、传入材料的包含方式以及适用的隐私审查。切勿仅仅为了使功能矩阵看起来完整而启用它。核心参与要求、可选故障报告和商业产品宣传的功能是需要不同证据的不同声明。
处理虚构的组件库存
考虑一个具有六个模块的虚构服务：策略解码器、发现解析器、对齐评估器、聚合构建器、XML 使用者和故障收集器。前三个映射到RFC 9989 。接下来的两个主要对应RFC 9990 。该收集器主要映射到RFC 9991 。共享存储和安全控制继承了它们处理的每个报告路径的要求。此清单是原始文献示例，而不是有关EmailAuth架构的断言。
对于每个模块，保留其实际构建标识符、相关部分、输入/输出合同、所有者和验收装置。虚构的发现装置可以将选定的策略及其源域传递到虚构的聚合装置中；报告行应该保留这种区别，而不是默默地替换可见的 From 域。然后引入故障报告请求并确认设计将其路由到单独授权的处理路径。这些是建议的检查，而不是已完成的执行。
将状态、勘误表和部署分开
确切的委托是：将每个实现组件映射到RFC 9989或 9991 并检查勘误表。实际实施范围尚未提供。当前勘误检索失败并被停止，因此本草案不能断言这些文档没有勘误。 RFC 9989对已解决的RFC 7489勘误表的讨论是历史背景，而不是对三个新文档的新勘误表检查。
在发布之前，实施所有者必须协调实际清单，标准所有者必须解决当前勘误表，接收器测试所有者必须保留版本范围内的互操作性证据。专家审查、生产路线检查、目视验收和出版批准也仍然开放。今天有用的结果是一个可审查的地图，它暴露了缺失的证据，而不会将更新的标准变成不受支持的普遍部署主张。