什麼時候 DANE 證書更改後交付開始失敗，首先確定密鑰是否已更改，是否 TLSA 關聯使用該金鑰以及每個接收者實際服務的憑證。通用憑證警告可以隱藏 DNSSEC 失敗，不正確 選擇器 或部分部署。修復錯誤的層可能會使郵件排隊，同時使證據更難以解釋。
保留失敗的觀察結果
參考： RFC 7672 §2, RFC 7672 §3.
記錄傳送者實作、時間戳記、接收者網域、選擇的MX主機、連接埠、接收 IP 和觀察到的故障。將DNSSEC驗證結果和相關 TLSA 答案與憑證或其公共指紋保留。如果寄件者重試另一台主機，請將其保留為單獨的觀察結果。總結整個領域的儀表板無法取代端點級證據。
區分握手失敗和握手後身份驗證失敗。網路超時並不能證明 TLSA 摘要不符。相反，收到憑證既不能證明DNSSEC鏈受信任，也不能證明DANE身分驗證成功。 RFC 7672分別定義了發現和驗證步驟。 RFC 7672第 2 節和第 3 節.
在比較位元組之前檢查用法和選擇器
參考： RFC 6698 §2.1.2, RFC 6698 §2.1.3, RFC 7672 §4.
對於 3 1 1 關聯，提取所提供的憑證的 DER SPKI 併計算 SHA-256。重複使用相同金鑰的憑證續約可以使該摘要保持不變。鑰匙輪換則不能。使用完整憑證選擇器，即使保留金鑰，更新的憑證也會變更關聯。請勿將瀏覽器的憑證指紋與 SPKI 指紋互換使用。
保留的 2026 年 11 月 7 日 OpenSSL 固定裝置已在此處進行檢查但未重新運行，它使用不同的密鑰創建了證書 A 和 B，並使用 A 的密鑰重新頒發了 A2。其記錄的計算顯示 A 和 A2 共享選定的 SPKI 摘要，而 B 則不同。然後它故意將 B 與 A 的關聯進行比較並記錄失敗。該測試使用真實生成的證書字節，但是本地綜合證據，而不是捕獲的生產事件。
重建DNS和端點計時
參考： RFC 7671 §8.1, RFC 7672 §2.1.
將新金鑰啟動時間與重疊關聯集的發布和先前快取資料的到期時間進行比較。如果部署了 B，而寄件者保留了僅 A 的記錄，則正確的寄件者可以拒絕 B。事件發生後查詢權威DNS並看到 B 並不能反駁先前的快取狀態。
檢查所有後端和地址系列。重新載入失敗的伺服器可能會保留 A，而其他伺服器則使用 B。僅新的 TLSA 集將僅導致部分流量失敗。 DNSSEC失敗還有另一個時間表：必須檢查簽章、委託和解析器驗證，而不能隨意將偽造資料視為未簽章。 RFC 7672第 2.1 節和第 4 節.
恢復一致性而不是禁用檢查
參考： RFC 7672 §3.1.1, RFC 7672 §4.
在金鑰未洩露的情況下，根據實際的快取和部署狀態，恢復先前覆蓋的憑證或正確重疊的關聯可能是適當的。協調郵件和DNS所有者並驗證發送方的修復。不要假設刪除 TLSA 將立即刪除快取的要求，並且不要將安全故障轉換為未經身份驗證的交付作為預設解決方法。
對於 DANE-EE，請勿將每個瀏覽器 PKIX 規則匯入診斷：其憑證使用具有特定的驗證語義，包括無憑證名稱符合要求以及忽略RFC 7672 §3.1.1 下的 DANE-EE 使用 3 的憑證過期。不要將此特定規則擴展到每個 TLSA 用途。當其他寄件者使用 PKIX 或 MTA-STS。另外，保留的 2026 年 11 月 7 日審查證據包含帶時間戳的環回 STARTTLS 會議。會議已被檢查，但未針對此修訂重新運行。受控客戶端在記錄的127.0.0.1連接埠觀察憑證 B，提取對等 SPKI 並拒絕僅 A 關聯。修正後的重疊 A 加 B 控制接受該路線。另外，Python/OpenSSL 憑證驗證根據信任材料 A 拒絕 B，而 A 成功。私人審查包保留了四個達到證書捕獲的案例的七個筆錄和同行證書位元組。握手失敗和無 STARTTLS 情況不包含捕獲的對等證書位元組。這是一個配置了 TLSA 輸入的小型實驗室用戶端，而不是 Internet DNSSEC結果或生產 MTA 事件。沒有發送訊息；生產驗收仍然需要預期的端點和發送者追蹤。