MTA-STS 故障涉及入站郵件的傳輸安全。它們不能透過改變來修復 SPF 或者 DKIM。依序診斷鏈： DNS中的政策發現、透過 HTTPS 的政策檢索、允許的MX名稱、接收伺服器的TLS行為。
識別受影響的發送觀察
收集寄件者的傳送錯誤、時間、目標域和可用的TLS報告。將單一寄件者的結果與普遍中斷分開。發送者可能快取了不同的策略版本，並且實現的支援也不同。記錄當前策略標識符、正文、模式和 max_age 以及您可以恢復的任何先前活動的策略。
RFC 8461定義了_mta-sts處的接收域發現和https://mta-sts.<domain>/.well-known/mta-sts.txt.檢查已發布的 TXT記錄 以及真實網域的確切 URL。確保 HTTPS 端點為其主機名稱提供可信任憑證並提供有效的策略。 RFC 8461第 3.3 節要求 HTTP 200 並禁止在取得策略時遵循 HTTP 3xx 重定向。瀏覽器成功存取首頁並不會建立該端點行為。
將策略與實際MX路由進行比較
檢查目標域的公共 MX記錄 並將它們的主機名稱與策略的 mx 模式進行比較。測試每個活動接收主機，包括通常流量很少的備份主機。超出允許模式的新新增的備份可能會造成間歇性故障，而不是完全中斷。
對於每個MX主機，請驗證SMTP STARTTLS、憑證有效性、信任鍊和MX主機名的身份匹配。在調查中將 Web 原則憑證和SMTP伺服器憑證分開：修正一個憑證不會修復另一個憑證。使用來自授權測試位置的合適TLS診斷工具並保留連接詳細信息，而無需傳輸不必要的真實訊息或憑證。
正確解釋模式和緩存
測試模式不需要因MTA-STS驗證失敗而拒絕；其他傳送控制仍可能拒絕該訊息。當寄件者有適用的策略時，強制模式會套用其驗證要求。即使DNS發現記錄稍後被刪除，具有適用快取策略的執行寄件者也可以繼續要求該策略。因此，刪除損壞的網站並不是可靠的即時回滾。
當策略變更時，更新發現標識符，以便支援寄件者可以偵測到變更。圍繞已發布的快取生命週期計劃變更。對於計劃撤銷，請使用 RFC 的無模式程序並允許快取策略，而不是將DNS刪除視為立即取消。在傳送者仍需要的轉換期間保持策略端點可用。
透過鏈條解決失敗問題
說明性案例： example.org通告primary.example.org和backup.example.net作為MX主機，但MTA-STS策略僅允許primary.example.org 。在選擇備份之前，郵件通常會成功。要調查的第一個更正是預期接收路由與策略之間的不匹配，而不是發送者 SPF記錄。在新增備份之前，請先驗證備份是否已授權且支援 TLS。這是一個綜合場景，而不是即時域測試。
建立一個診斷行，其中包含觀察時間、發送來源、策略版本（如果已知）、選定的MX 、 TLS錯誤、預期變更和驗證結果。 TLS報告可以揭示類別和模式，但其覆蓋範圍並不完整，缺少報告並不能證明每個發送者都成功。
恢復服務而不隱藏原因
更願意修復實際的憑證、端點或路由不符。如果需要放鬆政策，請獲得相關變更批准，記錄臨時暴露並說明快取。修復後，驗證每個MX路徑並檢查後續寄件者觀察結果和TLS報告。對 HTTPS 和SMTP憑證進行過期監控，並將MTA-STS策略包含在每個郵件提供者遷移清單中。
在提款決定中保留快取歷史記錄
RFC 8461第 8.3 節 描述了具有短生命週期和更改的發現記錄的發布模式 none，然後保留端點直到所有先前提供的策略過期。包括較舊的策略，其較長的 max_age 可以比前一個版本的壽命更長。刪除DNS不會刪除這些快取。 3.3 節區分了沒有可用快取的失敗的新鮮獲取和具有有效快取策略的失敗的獲取。 RFC 8460第 4.2 和 4.3 節 描述報告的會話和故障類型，而不是完整的每個訊息傳送分類帳。此教學場景未執行TLS連線、尋找或遷移。