身份驗證事件通常包含多個時鐘：報告的覆蓋間隔、報告的到達、 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查找或身份驗證測試，且時間軸沒有找到經過驗證的因果切換。