评估更新的规范，而不是新版本字符串
“DMARCbis 仅当它标识了正在比较的实际规范和实现时，“准备就绪”才是有用的项目标签。 RFC 9989 是更新的 DMARC 核心规范于 2026 年 5 月发布。 RFC 9990 单独指定汇总报告。这些是已发布的标准跟踪 RFC，不是发明新DNS版本值的理由。策略记录仍以v=DMARC1. RFC 9989 ，第 4.7 节 和 RFC 9990 ，第 2 节.
代理商可以准备与标准相关的差距登记和验收计划。它无法推断每个接收器、报告库或EmailAuth部署都实现了更新的行为。本文描述了拟议的评估，没有产品检查、 DNS更改或执行的验收测试。
盘点做出决定的组件
列出发件人的作者域、策略记录、发送身份、报告目的地和相关软件版本。确定哪些组件发现策略、评估 结盟、生成报告、解析报告并显示结果。仪表板可以使用当前标签，而底层库仍然遵循旧的发现行为。相反，接收方可能会实施更新的评估，但不会产生分析师期望的准确报告细节。
为每个组件指定一个所有者和一个证据源。供应商声明、配置导出和受控验收结果建立不同的事物。记录实际检查的内容和仅声称的内容。不要因为一个解析器接受新的示例文件或因为一个域已经发布了v=DMARC1.
比较策略和域发现行为
RFC 9989将基于公共后缀列表的组织域确定替换为指定的 DNS树漫步，包括公共后缀域注意事项。其变更摘要明确指出旧版和更新版的实现可能会达到不同的结果。准备计划应比较代表性域层次结构、明确的作者域策略和预期实现下的相关子域案例。 RFC 9989 ，第 4.10 节和附录 C.3.
不要将其简化为“智能体向上行走，直到找到 一个记录”。该算法定义了决策和查询范围。评估应将每个预期结果与相关规则联系起来，并保留测试使用的实际DNS响应上下文。假设的域树可以帮助设计案例，但它们并不能证明生产接收器遵循相同的算法。
协调标签更改，无需猜测接收器的采用情况
更新后的核心从其策略记录标签集中删除了 pct、rf 和 ri，并添加了 np、psd 和 t。 t标签携带测试语义；它不是替代数字百分比表盘。代理应该标记有关部分执行的遗留假设，而不是自动将百分比转换为不受支持的新策略。 RFC 9989 ，附录 A.6 和 C.5.
规范中标签更改的事实并不能证明特定提供商的部署解释。如果提供商文档描述了较旧的行为，请保留其日期和范围并请求当前的适用性证据。不要仅仅为了使合规检查表显得现代而重写实时记录。任何提议的标签更改都需要对实际接收人群进行影响评估，并单独批准测试或推出。
包括运营政策考虑因素
准备就绪并不等于发布 p=reject 到处。 RFC 9989的互操作性讨论涉及合法的间接流，包括参与邮件列表的通用用户，并描述了超出已发布策略的接收者责任。将这些流包含在间隙寄存器中，而不是将它们视为隐藏失败。 RFC 9989 ，第 7.4 节和附录 C.6.
对于虚构的组织，仅收据子域和员工通信域可能需要不同的接受案例和策略决策。评估将确定可以评估其权衡的人群和所有者。它不会假设收据流上的结果证明通信域可以采用相同的策略而不会产生操作后果。
将报告作为单独的实施依赖性进行评估
RFC 9990定义了聚合报告结构、标识符、重复处理、策略更改报告和外部目的地验证。根据适当的装置测试报告使用者支持的格式和行为，包括安全测试计划下的格式错误或重复的输入。接受一个文件的 XML 解析器并不能证明计数、身份和策略字段已正确解释。 RFC 9990 ，第 3、4 和 8 节.
保留合成固定装置的标签。一个捏造的 汇总报告 可以测试解析器，但无法建立真实的接收者行为或传递结果。外部报告路由还需要目的地的组织批准，与协议的技术授权检查分开。准备工作不应默默地重定向生产报告或授予新处理者访问现有数据的权限。
让每一个差距都导致决策和可重复的测试
拟议的登记册应包含要求、标准部分、受影响的组件、观察到的行为、预期行为、不确定性、所有者和验收证据。差距可能需要软件更新、明确的提供商承诺、授权的配置更改或不采取任何行动，因为情况不适用。 “未知”优于不受支持的通行证。
对于后续变更，请将准备工作与执行工作分开，并让操作路径强制执行范围和批准。 OWASP的授权指导强调检查每个请求的权限；代理的整体项目分配不应取代对每个租户或DNS记录的权限。 OWASP 授权备忘单.
在声称准备就绪之前需要接受证据
需要与标准相关的间隙登记和可重复的验收结果。这一确切的调试要求仍然开放。下图是文件登记模板。目前的EmailAuth功能、接收器采用、实施版本、批准的更改和可重现的结果尚未确定。标准研究定义了要检查的内容；它不证明部署准备就绪。