延遲的訊息可能會導致與時間相關的失敗 DKIM 即使沒有人更改其內容也進行檢查。在輪換金鑰或指責網關之前診斷簽章的時間欄位和驗證者的決定。訊息日期標頭、簽名建立時間和接收者到達時間描述了不同的事件。
正確讀出 t 和 x
在一個 DKIM-Signature header 中，t 是簽章建立時間戳，x 是絕對過期時間戳，兩者皆表示為自 UTC Unix 紀元以來的秒數。 RFC 6376第 3.5 節正式將這兩個標籤標記為「建議」。他們可能缺席，但該津貼不應與可選要求水平混淆。 x 值不是加到目前時間的持續時間。當兩者都存在時，x 必須大於 t。缺少t表示創建時間未知；缺少 x 表示該標籤未指定簽名到期時間。 DNS TTL是一個不同的概念，並且不設定x。 DNS DKIM金鑰記錄中的 t 標記是一組標誌，而不是此簽章時間戳記。
RFC 6376第 3.5 節 允許實現忽略具有未來時間戳記的簽名。當驗證過期時，它還允許簽名被視為無效。為了進行比較，如果可靠可用，則驗證時間應為驗證者的管理域首次收到訊息的時間，否則為當前時間。這就留下了事件記錄必須與通用拒絕規則區分開來的實施選擇。
建立一個三時鐘時間線
捕獲準確的簽名和原始接收者證據。將 t 和 x 轉換為可讀的 UTC，同時保留原始整數。記錄簽署者的時脈、驗證管理域的首次可靠接收時間、診斷複檢時間。新增相關的隊列延遲。不要使用不受信任的日期標頭作為系統何時收到訊息的證據。
說明性場景：簽名於 10:00 UTC 創建，並於 12:00 UTC 到期。訊息於 11:50 到達接收方，但在 12:15 再次檢查。具有可靠首收資訊的驗證者可以使用 11:50；稍後的獨立工具可能只有當前時間。不同的結果本身並不會顯示損壞的內容。此範例描述了協議的時間區別，而不是關於特定提供者的承諾。
區分時鐘偏差和緊密窗口
如果新發出的簽名看起來來自未來，請檢查簽署者的時鐘同步和時間戳記產生。如果這些值合理，但郵件定期在 x 之後到達，請檢查排隊、重試路由和所選的有效間隔。 RFC 6376沒有規定通用的理想壽命。使用您的實際交付要求和支援的簽署者設定來設定一項。
短暫的過期並不是完整的重播防禦。 RFC 6376第 3.5 節 明確表示 x 不適用於此目的。它也不能取代金鑰保護或濫用監控。刪除舊的公鑰可能會導致獨立於 x 的延遲驗證變得不可能，因此請將過期策略與金鑰保留相協調。
測試修復並保留區別
修正時鐘或策略配置後，透過慢速和正常路徑發送新的受控訊息。驗證它們的時間戳記和接收器結果。保留證據顯示先前的故障是否與時間、金鑰可用性、 正文哈希 或簽名驗證。不要在現有簽名訊息上編輯 t 或 x：這些值已被簽名覆蓋，更改它們不是修復。
工作紀元範例
合成值t=1794132000和x=1794139200對應於 2026 年 11 月 8 日 10:00 UTC 和 12:00 UTC。它們的差異是 7,200 秒或兩個小時，但 x 本身仍然是絕對時間戳。 11:50 的可靠第一筆收據是在到期之前；之後將在 12:15 進行獨立複檢。驗證者選擇的參考時間和允許的過期處理解釋了可能的差異。相較之下，當兩個標籤都存在時， x=t違反了所需的順序。這些值說明了算術和協定規則，而不是執行的郵件測試。
保留緊湊的調查記錄
使用此建議的工作表來查看正在審查的路線。它是一種規劃輔助工具，而不是已執行測試的證據。
- 簽章：原始 t 和 x 值、它們的 UTC 轉換、d 和 選擇器.
- 時間表：簽名者時鐘，首先可靠的收據，然後重新檢查，帶有時區。
- 發現：未來時間戳記、過期簽章、不可用金鑰或其他驗證失敗。
- 修復：支援時鐘或生命週期變更以及新發送的正常和延遲路徑測試的結果。