身份验证事件通常包含多个时钟：报告的覆盖间隔、报告的到达、 DNS更改、应用程序部署和受控测试。只有当每个事件都保持其原始含义时，将它们放在一个时间线上才有帮助。每日一 汇总报告 通常无法告诉您每条包含的消息失败的确切时间。
建立共同的时间基础
参考： RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
将显示的时间戳标准化为声明的时区，同时保留原始值和精度。记录时钟源和已知的不确定性。将报告间隔与到达时间戳和摄取时间戳区分开来。延迟发送的报告不应被绘制为附件到达时的新的发送突发。
将调查范围扩大到作者域并尽可能验证服务。将未分类的来源分开。保留报告者和报告身份、消息计数、来源组和评估身份，以及重复和重叠决策。这些细节决定了哪些观察结果可以合法地进行比较。
添加DNS证据而不重写历史记录
参考： RFC 1034 §3.6, RFC 8767 §4, RFC 9990 §3.3.
记录批准的更改、预期发布时间、权威观察结果和任何解析器样本，包括查找时间和返回的 TTL。当前的DNS答案确定了该查找现在观察到的内容；这并不是每个接收者之前看到的完整历史。
DNS缓存问题如下 RFC 1034 §3.6;合格的发球陈旧行为 RFC 8767 §4 可以将缓存的使用扩展到超出正常新鲜度。不要声称所有接收器在发布时都已切换，或者恰好有一个接收器稍后显示。保留先前的配置、更改日志和证据限制。如果报告间隔跨越策略更改，请将其标记为混合或可能混合，而不是将每个观察值分配给最终策略。
添加申请和接收者证据
参考： RFC 5321 §4.2.5.
将应用程序部署、网关更改和签名更改放在DNS事件旁边。将受控测试作为单独观察，并包含其实际路线、接收器和结果。申请日志可能会显示提交或接受的跳跃；它不一定确定最终交付。
使用这些证据类型来测试相互竞争的解释。 DNS编辑后失败增加也可能与更改签名内容的新模板同时发生。相关性缩小了调查范围，但在没有进一步证据的情况下无法确定原因。
在有限的时间范围内工作
说明性案例：报告涵盖 00:00 至 24:00 UTC。 12:00 记录策略变更，并在 12:20 通过对照测试 DKIM。该报告包含 80 个通过的观察结果和 20 个未通过的观察结果，于第二天早上 05:00 到达。
您可以在 12:20 陈述间隔总计和成功测试。您不能仅仅因为测试较晚通过，就将所有 20 次失败都分配到中午之前。下一步是获取更窄的接收器或应用证据，或运行其他代表性测试。 05:00到达是一次收集事件，而不是20次失败的时间。
以正确强度的因果陈述结束
将结论标记为观察到的、证实的或仍然假设的。列出支持可疑原因的证据以及未排除的任何相互矛盾的解释。如果不可能精确连接，则保留不确定性，而不是在图表上绘制精确的故障边界。
保存带有源参考、查询修订、包含的时间间隔和所有权分类的时间线。记录下一个验证触发点，例如修复后的第一个完整的可比较报告期。可重复使用的时间线应该允许另一位分析师重建事实和结论的局限性。
继续调查
使用 汇总报告演练 对于基础字段和 对准诊断指南 当原始身份验证成功不满足时 DMARC.
将插图保留在证据范围内
对于虚构的 80 次通过/20 次失败间隔，将所有 20 次失败时间保持未知。 12:20 测试是稍后的观察，05:00 到达是收集事件。没有执行真正的DNS查找或身份验证测试，并且时间线没有找到经过验证的因果切换。