轉發不會自動中斷 DKIM。保留所覆蓋訊息內容的轉發器可以使原始簽名保持有效。重寫所覆蓋的標頭或正文內容的轉發器可能會使其無效。診斷轉送服務實際執行的操作，而不是將所有間接傳送視為一種故障模式。
Trace identities and transformations separately
At the final receiver, SPF評價 連線系統和相關SMTP身分。即使訊息正文未受影響，轉發也可以變更連接 IP。相反， DKIM會根據簽署網域的金鑰驗證所涵蓋的郵件內容。因此，這些機制在同一轉發訊息上可能會有所不同。
記錄可見的寄件者網域、每個DKIM簽章、 選擇器 以及結果、信封身分和轉寄躍點。 DMARC 需要與作者域一致的通過身份驗證路徑。完整對齊 DKIM簽名 當轉送中斷時可以根據適用的策略提供該路徑 SPF，如指定 RFC 9989 §4.4.1。不相關轉發域下新新增的簽章不會自動對齊。
Compare direct and forwarded samples
將受控訊息傳送到直接測試收件匣，並透過轉送路由傳送到另一個測試收件匣。保留原始訊息和可信任接收者結果。使用獨特的測試標記，以便可以在不單獨依賴受試者的情況下關聯樣本。不要從渲染的主體推斷平等。
檢查 h 中所選的正文、主題和其他欄位的變更。在解釋差異之前檢查 c 和任何 l 標籤。標準 規範化 可以容忍某些格式更改，而實質重寫可以更改簽名表示。新增的傳輸標頭不會本質上使未涵蓋這些新出現的簽名失效；重複標頭選擇和過度簽名可能很重要 RFC 6376 §5.4.2.
走兩條路
說明性路徑A在不改變覆蓋內容的情況下轉送訊息。原始簽名仍然有效。路徑B在簽名正文中加入警告橫幅，導致原來的全身簽名失敗。兩條路徑上的連接可能相同，因此僅SPF觀察結果無法解釋DKIM差異。
轉發器也可能重寫 信封寄件人 提高自身的SPF授權。這不會恢復損壞的DKIM簽名，也不一定會創建SPF 結盟 與原始可見的 From 域。將三個問題分開：哪個身分透過SPF 、哪個簽章通過DKIM 、任一路徑是否對齊。
選擇範圍補救措施
如果內容保留與服務的安全義務相容，請檢查支援的設定以避免不必要的修改。如果需要修改，請評估服務的記錄簽名和間接郵件處理。不要將您的簽名金鑰授予任意轉發者或在SPF中廣泛授權他們以消除症狀。
行政接收者可以使用額外的可信證據或本地策略來發送間接郵件，但這是一個單獨的接受決定。請勿將此類接受報告為恢復原始簽名。保留業務需求和任何異常所有者以及技術結果。
Close with route-specific proof
更改後，對純文字、HTML 和附件重複直接與轉發測試。記錄哪些原始簽章仍然存在、是否出現新簽章以及最終的DMARC和傳遞結果。在回归测试中保留转发路由，因为稍后的横幅或扫描更改可能会改变结果，而无需在发件人处进行任何DNS更改。
Read two hypothetical message-level outcomes
假設適用的DMARC策略和作者域example.com ：
- 保留路徑：轉送後SPF失敗，但原始d=example.com簽章仍然驗證。精確對齊的DKIM身分提供DMARC通行證。
- 修改路徑：原DKIM簽章失敗；唯一的新傳遞簽章和SPF身分屬於forwarder.example.net 。假設該域與example.com無關，兩者都不提供對齊，因此DMARC失敗。接收者仍然可以做出單獨的本地處理決定。
不要將新簽署的通行證與舊簽署的網域合併。這些案例說明了以下情況 RFC 9989 §5.3.5;它們不會捕獲每個轉送服務的接收器結果或保證。