询问拟议的升级实际上改变了什么
声称平台提供 DMARCbis 升级应确定当前标准、正在更改的实施行为以及更改有效的证据。不应将其作为将DNS记录切换到发明的请求而接受 DMARC 版本。保留电流 RFC 9989 仍指定区分大小写的版本值DMARC1 。新标准文档和新实施版本与已发布政策中的新版本令牌不同。
本文提出了与标准相关的准备情况审查。它没有声称EmailAuth实现 RFC 9989 完全，每个接收器都采用了它或进行了升级。没有更改DNS记录、解析器、接收器或生产配置。在任何人批准推出之前，审查应将规范变更、供应商实施声明和观察到的互操作性分开。
拒绝版本切换快捷方式
RFC 9989的策略记录定义规定，版本标记的唯一可能值是DMARC1 ，否则不同的版本值会导致记录在指定处理下被忽略。因此，发布v=DMARC2的提案并不是此 RFC 中基于标准的迁移指令。要求提议者确定支持任何建议的记录更改的确切部分，而不是依赖产品标签。
同样的注意事项也适用于重命名仪表板设置。称为DMARCbis的设置可以启用解析器功能、策略发现算法或报告解释，但其含义在记录之前是特定于产品的。记录实际支持的行为、发行版本和限制。不要推断切换设置会更新外部接收器、正确重写每条记录或验证所有合法的发送工作流程。
盘点相关标准变化
使用RFC 9989的变更讨论和规范部分来构建有重点的清单。一个重要领域是基于 DNS 的策略和组织域发现，包括 DNS树漫步。这是一种实现行为，而不仅仅是插入现有记录的新字符串。声称支持的供应商应解释哪些发现和 结盟 它处理的案例并为实际产品版本提供范围证据。
另一个明确的变化是从当前规范中删除 pct 标签。附录 A.6 解释了历史并介绍了具有值 y 和 n 的测试标签 t，在应用中被描述为与之前的 pct 值 0 和 100 类似。这并不能证明对每个历史百分比值进行全面机械替换或承诺每个接收器都实现新行为是合理的。在提出策略差异之前，请检查当前确切的语义和相关的部署群体。
将协议要求与提供商资格规则分开
提供商可以发布参考现有部署约定的产品资格要求。这些要求需要自己当前的源代码审查，并且不应因为协议文档发生更改而默默地重写。相反，历史提供商指令不会重新定义RFC 9989的规范内容。记录明显的差异、源日期和需要解决的实施问题，而不是假装两个层是相同的。
本手稿并不声称通用接收器支持测试标签、树行走行为或任何其他修订功能。准备情况评估必须确定组织控制哪些组件以及外部组件。发送者只能在支持的范围内更新自己的实现或策略；它不能强制所有接收系统升级。因此，兼容性结论需要经过论证的、有限的证据，而不是全球采用的假设。
单独的报告标准和解析器准备情况
RFC 9990 将DMARC聚合报告定义为单独的规范。平台的策略评估器和报告摄取解析器可能有不同的升级要求。询问支持哪些报告格式、字段和验证行为，以及旧的保留报告如何保持可解释性。不要假设更改策略发现实施会自动更新每个报告工作流程或历史分析。
固定产品版本并保留用于评估的标准参考。如果解析器遇到不受支持的字段或报告变体，则应记录和测试其行为，而不是默默地解释为零活动。保留原始报告出处，并将缺失的观察结果与验证结果区分开来。本文没有使用报告解析器，也没有将测试装置表示为实际的接收器报告。
构建标准到实施矩阵
每个相关要求创建一行，包括 RFC 部分、规范行为、当前产品行为、建议的更改、受影响的组件、证据参考和未解决的限制。单独的发送者策略发布、接收者评估、组织域发现、报告生成和报告摄取。平台可能只执行其中一些角色，因此不支持的角色应标记为超出范围，而不是算作通过暗示实现。
添加现有有效策略、无效版本值、发现边界、对齐关系和报告兼容性（如果适用）的代表性案例。确切的装置应由合格的评审员根据规范文本和产品支持的角色进行设计。该草案没有提供实施一致性套件，也没有声称一小部分示例可以证明完全合规。每个观察到的结果都需要保留输入、产品版本和预期行为。
将任何记录更改与发件人准备情况联系起来
如果评估建议更改DNS策略，请准备准确的差异、所有权记录、业务审批、验证计划和回滚标准。通过发件人准备矩阵保持合法的发送工作流程可见。标准升级并不能证明每个供应商都具有一致的身份验证或每个关键工作流程将继续不受影响。请勿使用新的实施标签作为跳过操作准备的理由。
记录变化可以展示什么和不能展示什么。权威的DNS证据可以显示特定时间的发布；可信的接收消息证据可以显示范围内的身份验证结果； 汇总报告 可以在其保留的覆盖范围内显示模式。没有一个能够单独建立通用的互操作性。回滚规划必须考虑缓存状态和外部实现差异，而不仅仅是恢复旧配置文件的能力。
虚构诊断：请求的 DMARC2 记录
虚构的供应商提出升级并告诉买方将策略的版本值更改为 DMARC2。买家询问标准参考，发现RFC 9989仍然指定DMARC1 。提议的版本切换因不受支持而被拒绝，而更广泛的实施审查仍在继续：供应商可能对需要单独证据的发现或报告行为进行合法更改。
该团队将请求一个范围内的准备矩阵并展示实际产品发布的结果，而不是根据其营销名称接受或拒绝整个升级。这是虚构的审查活动，不是真正的供应商指令或观察到的生产缺陷。没有发布任何记录，也没有测试任何接收器。该示例展示了精确的标准问题如何将错误的捷径与潜在有用的实施工作区分开来。
在调用升级完成之前需要演示范围
一个有用的结论确定了实施的与标准相关的变更、涵盖的角色、保留的证据以及仍然未知的外部兼容性。不应该说该组织现在使用第二版或所有接收器行为统一。此次升级是实施和准备情况评估，而不是通用开关。
该目录要求进行与标准相关的准备情况评估并展示范围内的实施结果。这些原始结果仍然开放。人类专家审查、来源适用性、生产路线、可访问性和所有者发布也保持开放。本草案提供了审查方法和虚构示例，而不是一致性证据、已部署的迁移或完整的EmailAuth支持的声明。