A DMARC 变更请求应该允许另一个人准确地确定将要更改的内容、哪些服务可能会受到影响以及如何证明成功。仅显示所需策略的屏幕截图是不够的。保留基线和建议的 RRset，然后将它们连接到已批准的业务流程和恢复决策。
精确捕获基线
记录DNS提供商帐户或租户、区域、所有者名称、记录类型、完整值和 TTL。包括观察的时间和来源。捕获受影响的作者域的当前DMARC策略发现，以及批准的发件人和任何未解决的异常。保留身份验证标识符，而不是减少对仪表板颜色的测试。
DMARC可以通过对齐成功 SPF 或者 DKIM 结果。因此，邮件的可见发件人域及其经过身份验证的标识符比SPF传递的通用声明更重要。 RFC 9989。对于域名发布 p=reject, RFC 9989 第 7.4 节和第 8 节分别要求有效的DKIM签名并禁止仅依赖SPF ；消息级成功并不免除部署职责。身份验证通行证不能证明业务请求或确保收件箱放置。
描述预期的差异
说明确切的前后 RRset 和受影响的名称。解释为什么现在需要改变、测试了哪些服务以及哪些证据仍然不完整。将不相关的DNS编辑保留在请求之外，以便审批者不会意外批准更广泛的操作。确定技术实施者、业务审批者和升级联系人。
如果报告目的地或委托服务发生变化，请分别评估信息流和依赖性。保留预期监控所需的报告摄入配置。 汇总报告 是具有覆盖范围限制的接收器观测结果，因此它们不能成为时间关键的合法流的唯一接受信号。 RFC 9990.
编写可观察的验收标准
使用可能失败的标准：权威RRset等于批准值；代表性关键消息使用预期身份并按预期进行身份验证；业务接收者确认预期结果；并继续报告摄入量。记录观察时间并区分立即可用的测试和以后的报告审查。尚未到达的报告并不是通过测试。
在实施之前定义恢复触发器。如果关键流程失败并且诊断将其链接到批准的变更，则调用批准的恢复计划。保留旧状态并解释其局限性。恢复策略不会立即反转缓存的DNS或撤回已拒绝的消息。计划在名义维护窗口之外进行观察。
测试请求是否能够真正关闭
假设一个假设的请求仅更改工资单 From 域的策略 p=none 到 p=quarantine 同时保留其报告目的地和 TTL。审查仍必须约束完整的基线和建议的 RRset、目标帐户和域、批准的工资范围和恢复计划。这里不提供真正的有效负载、批准或DNS更改。
假设授权的变更后观察与批准的DNS状态匹配，并且代表性工资单消息按预期进行身份验证，但业务接收者尚未确认接收，并且下一个汇总报告尚不可用。记录配置和身份验证检查与那些待处理的结果分开。将收据后续工作分配给工资所有者，并将延迟的接收审核分配给报告所有者；不要根据匹配记录来关闭所有验收标准。这些是假设的发现，而不是执行的检查。
上面的变更工作流程是操作建议，而不是协议要求。 NIST SP 800-53 Rev. 5 控制 CM-3 和 CM-5 为审查、批准和限制变更提供了一般基础；这里的确切有效负载绑定、角色和切换字段是建议的实现。 NIST控制目录.