A DKIM 無金鑰診斷通常意味著驗證者無法找到簽章所需的驗證金鑰。有用的起點是訊息的實際內容 選擇器 和簽章域。猜測通用選擇器或查詢可見的 From 域可以為錯誤的DNS問題提供完全準確的答案。
保留原始收到的訊息及其可信賴的身份驗證結果。記錄觀察時間，因為密鑰自交付以來可能已更改。然後調查結果中指定的確切簽名；訊息可以攜帶多個具有不同查找名稱和結果的簽名。
匯出確切的DNS問題
讀取 s 和 d DKIM-Signature。使用s=campaign7和d=mailer.example,尋找為campaign7._domainkey.mailer.example 。選擇器不是通用提供者名稱，且簽章域不必與可見的寄件者域相同。 RFC 6376 §3.1, RFC 6376 §3.5 和 RFC 6376 §3.6.2.1 定義這些元素。
查詢支援的配置所需的名稱和記錄類型。在下面 RFC 1034 §3.6.2，如果服務使用 CNAME，跟隨它到驗證數據並捕獲中間目標。檢查 DNS 編輯器錯誤，例如附加後綴兩次， 一個記錄 發佈在錯誤的區域或從不同租戶複製的選擇器。
區分缺勤和缺勤
沒有建立對應鍵的否定答案與逾時的查詢不同。 RFC 6376 §6.1.2 對於不存在的金鑰，需要 PERMFAIL；當金鑰查詢無法回應時，允許 TEMPFAIL。這些是驗證者處理結果；診斷產品中確切顯示的標籤可能有所不同。
捕捉DNS響應代碼和答案，而不僅僅是紅色指示器。在有證據的情況下，將權威答案與與故障接收器相關的遞歸視圖進行比較。稍後從您的筆記型電腦成功找到並不能證明在原始評估時間可以存取該密鑰。
使用三分支診斷樹
首先，如果訊息不包含DKIM-Signature ，請調查簽章配置而不是選擇器查找。沒有要檢索的特定於訊息的 s 和 d 對。其次，如果簽名存在但其金鑰不存在，請檢查發布、遷移和退役歷史記錄。第三，如果密鑰可用但 正文哈希 或者簽章失敗，轉向內容、金鑰匹配或加密檢查。
說明性案例：訊息名稱選擇器 old7，而DNS僅包含 new8。正確發布new8無法驗證old7簽名。如果 old7 被故意停用，則延遲或存檔的郵件可能會發生錯誤。如果 old7 被意外刪除且其金鑰仍然值得信賴，則恢復正確的驗證資料可能是適當的核准修復。這些是診斷場景，而不是執行的租戶測試。
檢索後檢查密鑰有效性
找到TXT答案並沒有完成驗證； RFC 6376 §3.6.1 和 RFC 6376 §6.1.2 定義關鍵語法和驗證。格式錯誤的金鑰、指示吊銷的空 p 值或不相容的金鑰材料都不是可用的驗證金鑰。在下面 RFC 4592 §3.3.3, 通配符 TXT記錄 也可以產生與DKIM無關的答案。不要將每個不可用的答案重新標記為遺失的選擇器。
使用提供者的準確目前記錄值或已知的授權配置備份。切勿產生隨機公鑰來滿足查找：它不會與創建簽名的私鑰匹配。避免在未檢查其他寄件者和延遲郵件的情況下在共用尋找中取代記錄。
用新的證據驗證修復情況
授權修復後，檢查DNS並透過受影響的路由發送新的受控郵件。保留接收到的結果、簽名身分和 結盟 評估。如果原始樣本現在得到驗證，請將其記錄為稍後的重新檢查，而不是重寫其歷史接收器結果。
以缺失的姓名、原因、復原的依賴性和預防措施來結束事件。選擇器清單和報廢檢查表比在檢查器報告紅色時重複新增記錄更有效地減少重複發生。
保留有界結論
對於 old7 與 new8，保留舊簽章的查找，而不是將目前選擇器複製到事件記錄中。缺少 old7 金鑰、逾時和空 p 撤銷是不同的觀察結果。稍後成功的複檢必須保留其較晚的時間。教學場景未進行任何修復或簽名驗證。