避免全有或全无的审查
提供商帮助页面可能仍会引用 RFC 7489 同时准确描述当前帐户屏幕或支持的发送路线。相反，新标注日期的页面可以重复历史协议建议。有用的审查单位是单独的说明或主张，而不仅仅是引用的年龄。审核员应确定哪些内容仍然有效、哪些当前标准发生了变化以及哪些内容取决于提供商的实际实施。
RFC 9989 提供当前核心 DMARC 规范并描述了RFC 7489的更改。聚合和故障报告现在分别指定在 RFC 9990 和 RFC 9991。使用这些来源来评估协议声明，但不要将它们视为提供者已更改每个 UI 字段或部署的评估器的证据。 RFC 9989 ，附录C; RFC 9990 ，第 1 节; RFC 9991 ，第 1 节
保留准确的产品上下文
在注释指南之前，记录其 URL、保留日期、产品、计划或帐户范围（如注明）、区域、路线和相关先决条件。供应商品牌可以包含具有不同配置路径的多个邮件产品。自定义SMTP路由的指南可能不适用于默认 API 路由，并且某个托管邮件产品的说明可能不涵盖同一公司的另一种产品。
保持帐户生成的值与解释性示例不同。指南样本 选择器 或DNS目标不应复制为通用生产值。同样，即使 UI 指令周围的标准解释需要更新，它仍然有用。保留这种区别，这样读者就不会仅仅因为简介中出现历史 RFC 就放弃有效的入门先决条件。
本手稿不会审核指定提供商的经常账户或断言特定服务不合规。它为未来的源头审查提供了一种方法。任何实际产品说明在适用之前都必须对照可读的主要指南和授权帐户上下文进行检查。
按权限对每条指令进行分类
至少使用四个注释类别：产品工作流程、协议要求、特定于提供商的资格或政策以及解释性建议。产品工作流程需要当前的提供商证据。协议要求需要适当的规范部分。提供者资格可能比协议最低要求更严格或范围不同，并且不得推广到每个接收者。建议应披露其理由和限制。
对于每一行，写下演员和条件。接收者的策略发现行为与域所有者的DNS发布任务不同。该服务可能需要配置特定帐户字段，而无需更改标准的记录语法。报告目标的接收权限与发送者向那里发送报告的请求不同。
当一个句子组合类别时，将其拆分。例如，输入报告地址的指令可能是有效的 UI 步骤，而任何外部地址自动接收报告的声明是不完整的。审查应保留有用的步骤并附加缺失的授权条件，而不是用通用建议替换整个指南。
比较具体变化的概念
当前核心DMARC版本值仍为DMARC1 。审核不得发明 DMARC2 记录或暗示更新 RFC 引用需要DNS版本切换。当前规范还记录了 pct 的删除，而保留的IANA注册表则标记了该标签的历史意义。这些事实支持纠正 pct 是当前核心标准抽样控制的说法，但没有证明每个部署的提供商如何处理它。
策略发现和组织域确定也需要与当前规范进行比较，而不是与旧的简化算法进行比较。应根据RFC 9990或RFC 9991酌情检查报告声明。记录准确的差异及其操作意义；不要使用“DMARCbis 改变了一切”来代替部门级评估。 RFC 9989 ，第 4.7、4.10 节和附录 A.6; IANA DMARC标签注册表
注释工作表和验收标准
创建一个工作表，其中包含指南摘录、源快照、产品范围、指令类别、当前权限、建议注释和仍需要的实施证据。分配四种结果之一：保留（如适用）、保留范围注释、因标准声明更改而更新或未解决的待定提供者证据。这些是编辑结果，并不是声称任何生产系统都通过了测试。
工作表还应标识可以确认帐户特定值的所有者以及建立行为所需的任何单独授权的测试。如果提供商指南无法访问，请标记源差距，而不是替换通用设置序列并将其称为已验证。
接受要求每个注释都有自己的证据。审阅者应该能够明白为什么在修改协议解释的同时保留了屏幕导航步骤。将原始摘录和提议的措辞放在一起，以便更改不会意外引入新的承诺、不受支持的功能或通用交付承诺。
对遗留引用的设置页面的虚构评论
想象一个虚构的提供商页面，其中包含三个指令：输入帐户生成的 DKIM 记录，通过设置屏幕添加报告地址，并使用 pct 作为当前标准的推出控件。该页面引用了RFC 7489 。此处未审核此类指定页面；这些发明的说明说明了分类方法。
如果当前产品文档和帐户值支持， DKIM步骤可能仍然有效。报告地址步骤可能作为 UI 操作仍然有效，同时需要额外的外部授权解释。 pct 语句需要当前标准注释，而提供商对该字段的实际处理仍然是一个实现问题。因此，一次引用会导致三种不同的审查结果。
建议的下一步行动是保留受支持的产品说明、更正标准语言并获取提供商特定的未解决行为的证据。这并不是删除所有现有记录、绕过设置要求或声明提供商不安全。这个虚构的示例演示了仔细审查如何在不夸大访问或测试结果的情况下发挥作用。
将运营发布和社论发布分开
编辑更新可以在生产验证完成之前改进指南，前提是其限制是可见的。请勿将带注释的文档描述为真实账户配置正确的证据。相反，成功的帐户测试不应推广到每个客户计划、区域或接收方实施。
该目录需要注释来标识哪些步骤仍然有效、哪些步骤发生了变化以及哪些步骤取决于提供程序的实现。对于该草案，真正的特定来源注释指南仍然开放。当前未声明指定提供商推出、帐户导航、 DNS编辑或消息测试。原始证据门和其他五个释放门仍然开放。
在发布操作之前，获取实际可读的提供商源并保留准确的摘录、源日期和当前标准参考。合格的审核人员应检查每条保留的指令是否与产品范围相匹配，以及未解决的实施行为是否仍未解决。这种方法产生了一个可用的指南，而不假装旧的引文单独证明正确或失败。