已撤銷 DKIM 密鑰和遺失的密鑰記錄可以告訴操作員不同的信息，但都不提供可用的驗證密鑰。 RFC 6376 §3.1 明確定義撤銷金鑰和刪除其簽章驗證記錄之間沒有語意差異。在診斷中斷或回應妥協時保留這種差異。
認識不同的觀察結果
在DKIM金鑰記錄中，空 p= 值表示撤銷。語法上適當的說明性 RSA 撤銷值是 v=DKIM1; k=rsa; p=。它不包含私鑰，也不是替代密鑰。使用準確的 選擇器 受影響簽名中的所有者名稱並遵循平台支援的流程。
當密鑰記錄不存在時， RFC 6376 §6.1.2 呼籲無關鍵原因的永久失敗。空的公鑰值會因撤銷金鑰原因而導致永久失敗。無法回應的DNS查詢是另一種情況，可能會產生臨時故障。不要呼叫每個查找問題撤銷。
操作意圖仍需證據。空密鑰可能是已批准的緊急變更或發布錯誤。遺失的記錄可能反映了故意停用、錯誤的選擇器或意外刪除。在歸因原因之前比較權威DNS狀態、遞歸答案、時間戳記和授權更改歷史記錄。
根據事件選擇回應
對於例行停用，請協調簽署的結束與合法延遲訊息可能仍需要舊公鑰的時間段。對於可疑的私鑰洩露，連續性和遏制可能會發生衝突。呼叫事件流程，確定誰可以授權更改並記錄為什麼所選回應是相稱的。
跨快取的撤銷不是即時的。 RFC 1034 §3.6 描述快取記錄的 TTL。解析器可以保留早期的正數據，直到其快取生命週期結束。事件發生後減少 TTL 並不會追溯縮短每個快取的副本。一些解析器可以在以下情況下提供過時的數據 RFC 8767 §4 當刷新不可用時，因此舊的 TTL 不是絕對的全球撤銷期限。不要聲稱DNS編輯會立即阻止使用舊答案的所有後續驗證。
阻止受損的簽署者和限制未經授權的存取是不同的任務。僅更改DNS並不能恢復洩漏的私鑰或保護洩露該私鑰的帳戶。 RFC 6376 §8.3 解釋了簽名密鑰洩漏的風險。對於提供者管理的 CNAME，確定誰控制最終關鍵資料以及哪些支援的操作會停用受影響的選擇器。不要添加衝突的 TXT記錄 與別名一起作為臨時修復；看 RFC 1034 §3.6.2.
舉一個以證據為主導的例子
在合成事件中，訊息使用 d=example.com; s=oldbilling。權威答案現在包含一個空的 p=，而一個遞歸解析器仍然傳回較早的公鑰。事件記錄顯示已核准撤銷。這支援快取轉換解釋；它並不表明所有接收者都已停止驗證舊簽章。
第二個測試使用 s=old-billing，預期選擇器中缺少連字符。該名稱不存在任何記錄。查找失敗是真實的，但並不能證明預期的選擇器已被撤銷。確切的名稱可以防止這兩起案件合併為一件事。
驗證更換而不恢復曝光
如果授權繼續傳送，請使用新的、安全性產生的金鑰和支援的選擇器轉換。確認權威出版物並檢查從每個受影響的應用程式收到的測試。將受損金鑰遠離復原腳本、還原到活動簽署者的備份以及複製的設定範本。
將舊配置保留為受限存取下的事件證據，而不是作為自動回滾目標。恢復受損簽章機密的回滾可能會重現問題。透過變更、受影響的選擇器、遏制行動、快取觀察和新簽署證據的權限來結束事件。記錄有意犧牲驗證的所有較舊的合法訊息。
在選擇操作之前對查找進行分類
使用這些作為綜合診斷分支，而不是來自真實領域的結果：
- 精確選擇器傳回空的 p 值：金鑰被明確撤銷； RFC 6376要求 PERMFAIL（金鑰已撤銷）。
- 精確選擇器沒有金鑰記錄： RFC 6376需要 PERMFAIL（沒有簽章金鑰）。檢查拼字、授權和批准的退休歷史。
- 查詢未收到回應： RFC 6376允許 TEMPFAIL（密鑰不可用）。僅此一項觀察並不能證明撤銷。
這些結果與該簽名有關。單獨保存其他簽名及其結果；訊息可以有另一個身份驗證路徑。
相關閱讀
DKIM DNS委託：評估授予提供者的控制範圍 · 跨簽章系統儲存與保護DKIM私鑰.