安全的電子郵件網關和 DMARC 解重疊的操作問題，但不可互換。網關可以檢查、路由、隔離或修改訊息。 DMARC評估一致的身份驗證並向接收者提供網域策略資訊。重要的問題是您的完整路線的行為方式，包括建立簽名後的轉換。
繪製實際的訊息路徑
按順序記錄提交、簽名、網關處理和最終接收。確定您控制哪些元件以及每個元件有權簽署哪些身分。表示僅啟用網關的圖表無法確定下游接收器是否獲得完整的對齊簽章。從授權的測試路徑取得原始和最終的原始訊息，保留訊息標識符和時間。
DKIM 涵蓋選定的標頭和規範化的正文。即使更改的連結是合法安全功能的一部分，主體重寫也會使現有簽名無效。 RFC 6376定義了簽章和驗證行為。 DKIM規範。保留簽名的標頭列表， 規範化 解釋特定故障時的選擇和任何身體長度參數。
刻意核對並簽字
入站網關可以在修改之前驗證訊息，但內部結果不會自動信任每個下游收件者。定義下一個系統如何識別可信任結果以及它如何處理不可信的標頭斷言。 RFC 8601。稍後的驗證者檢查修改的位元組可能會出於合法原因得出不同的結果。
對於您管理的呼出路由，在批准轉換後簽章可以避免破壞最終簽章。簽署者必須獲得其網域的授權，並且 結盟 仍需評估。增加來自不相關網關域的有效簽章不一定會產生一致的DMARC結果。不要僅僅為了保留簽名而刪除安全檢查，而不審查更廣泛的控制設計。
追蹤假設的重寫
假設授權的brand.test簽署者簽署了包含URL的訊息正文。然後，網關會變更所覆蓋的 URL，而無需隨後新增授權的對齊簽章。如果規範化的簽名字節發生更改，則較早的簽名將無法針對更改後的正文進行驗證。保持相關規範化簽名字節不變的轉換不需要破壞簽名。檢查規範化、選定的標頭和任何 l= 限制，而不是假設每次重寫都具有相同的效果。
如果單獨的授權簽名者簽署最終轉換的訊息，則即使舊簽名失敗，新簽名也可以驗證。它不會修復舊簽名或證明新簽名者俱有業務權限。評估新的 d= 域的對齊和可信的最終接收者結果。這些是基於協定的假設結果，而不是原始訊息樣本、產生的金鑰、dkimpy 輸出或執行的網關實驗。
將結果轉換為路由測試
在生產中，使用受控接收者和供應商支援的配置重現相關的授權轉換。捕捉最終接收者的可信結果，而不是從網關控制台推斷成功。比較整個路線中的相同內容修訂，並記下其他更改，例如主題前綴或免責聲明。通過的新簽名並不能證明早期的身份驗證仍然存在。
也測試故障處理。如果簽名步驟不可用，請確定郵件是否排隊、失敗或在沒有預期簽名的情況下離開。將恢復說明與實際服務連結。避免緊急旁路將包含的身份驗證問題轉變為不受限制的中繼或未經檢查的傳遞。
驗收記錄應註明測試的路線、轉換、簽署者的位置、最終身分和接收者結果。維護單獨的惡意軟體過濾檢查， 網路釣魚 檢測和域認證。通過一項測試是該功能的有用證據，而不是整個訊息或網關安全的證書。
源和執行邊界
RFC 9989第 4.4、5.3.5 和 5.4 節 區分認證、對齊和處理；通行證並不認可訊息內容。這裡的營運決策是範圍內的建議和明確的假設範例，而不是對客戶、提供者或歷史固定裝置的新測試。任何真正的改變都需要有自己的授權範圍、保留的證據和負責任的決定。