当前的DNS查找无法证明接收者之前在报告窗口中使用的内容。策略更改可以跨越报告边界、 DNS缓存状态和接收器生成实践。在解释报告与今天的记录之间明显不匹配之前，请保留历史。
保存更改时间表
参考： RFC 8767 §4.
记录新旧 DMARC记录、受影响的域、批准的变更时间、权威观察和相关 TTL 信息。保存相关 SPF 和 DKIM 分别改变。策略编辑和发件人身份验证修复可能会同时发生，但会解释生成的报告的不同方面。
使用观察方法记录 UTC 时间。给定时间的权威答案确定了服务器当时返回的内容；它并不能确定每个接收者立即丢弃缓存的答案。避免发明的通用传播期限。合格的发球陈旧行为 RFC 8767 §4 可以保留超出正常 TTL 新鲜度的可用数据。
阅读所报告的政策的上下文
参考： RFC 9990 §3.3, RFC 9989 §5.4.
RFC 9990 第 3.3 节描述了变更期间的混合策略报告。接收方可能会生成一段时间内的多个报告，也可能生成一个其观察结果跨越策略状态的报告，同时其policy_published 元素包含一个配置。该报告的一个策略快照不是逐条消息的DNS审核。
分别检查覆盖的时间间隔、上报的配置和处理信息。报告的处置也不能替代一致的身份验证结果。接收方本地决策可能与域所有者请求的处理不同。
完成过渡工作
案例说明：业主变更 p=none 到 p=quarantine 世界标准时间 12:00。报告涵盖 00:00–24:00，并记录最终发布的隔离偏好。它仍然可以包括与先前政策相关的早期观察或处理。仅这种不匹配并不能证明接收者忽视了它已经遵守的政策。
正确的调查会比较更改日志、报告器窗口和可用的消息级示例。如果特定于策略的报告是分开的，请保留其身份并在求和之前检查重叠情况。不要重写旧的观察结果以继承当前的DNS状态。
单独验证实际变化
通过重要途径查看权威出版物和代表性后续消息。记录可信的身份验证结果和任何特定于接收者的发现。干净的后续报告间隔可以提供额外的证据，但它和当前的DNS查找都无法证明每个接收器的行为。
使用配置事件对图表进行注释，并保持更改前、过渡和后期间隔可区分。通过观察到的结果、未解决的实施差异和恢复标准来结束变更。当历史报告保留当时存在的不确定性时，它是最有用的。
保留变更证据包
将批准的记录差异、发布观察结果、测试消息引用和相关报告标识放入一份访问控制记录中。请注意附近部署的任何其他更改，包括网关转换或提供商签名更新。这些混杂因素可以解释身份验证的转变，否则这种转变似乎与策略编辑相关。将分析师的解释与原始报告分开记录，以便以后的审阅者可以重新审视它。如果关键路由显示无法解释的故障，请使用明确的停止条件来扩展到其他域。
继续调查
使用 汇总报告演练 解释底层字段和 对准诊断指南 当原始身份验证通行证不满足时 DMARC.
执行综合证据
提供的本地重新运行合成现场装置代表间隔秒 43,200 从无到隔离的政策过渡。该报告涵盖第二个 0 到 86,400，policy_published 记录了p=quarantine.域brand.example 。相对秒数使其成为模型，而不是历史DNS记录。处理两个提供的记录：
- 夹具行：计费；数量：90；处置：无；对齐DKIM ：通过；对齐SPF ：失败；所有权证据：仅作为提供的固定装置事实而为人所知
- 夹具行：来源不明；数量：10；处置：无；对齐DKIM ：失败；对齐SPF ：失败；所有权证据：未分类
执行的算术产生 100 个观察值、90 个对齐的通过和 10 个对齐的失败。字段到决策链是特定的：date_range 跨越更改，policy_published 是一个快照，并且 10 次失败的无处置无法识别何时评估这些消息。使用历史政策观察和授权样本调查这 10 个。不要自动给它们贴上更改前的标签，也不要断定接收者忽略了隔离。已知的计费装置不需要对此证据进行身份验证修复，因为其对齐的DKIM通过了，尽管业务交付仍然需要单独的证据。真实服务归属、 DNS观察和接收器样本仍有待确定。
保持决策的界限
本地练习计算了 90 次提供的对齐通过和 10 次失败，但 10 次失败的评估时间未知。该模型无法从无处置中推断出变更前时间或接收器不合规情况。未执行DNS查找、策略更改或接收器测试。