安全網關可以顯示為報告接收者看到的來源，因為它中繼了訊息。它的出現並不表明它創建了訊息、擁有發送應用程式或導致身份驗證失敗。在更改DNS或網關策略之前，調查路由和訊息內容變更的點。
建立網關角色
參考： RFC 9990 §3.1.1.8, RFC 9990 §3.1.1.10.
繪製從應用程式到最終接收系統的預期路線。區分出站中繼、入站閘道和轉送中介。記錄哪個組織控制每個躍點以及報告接收者實際看到的躍點。在路由得到證實之前，熟悉的網關主機名稱只是基礎設施線索。
保留來源 IP、報告者、間隔、計數、作者域、信封身分、 DKIM 域和報告的 結盟 結果。將這些與授權網關日誌和可信任接收者證據進行比較。限制對原始訊息的訪問，因為它們可能包含個人或機密內容。
找到簽名邊界
參考： RFC 6376 §3.4, RFC 6376 §3.7.
RFC 6376定義了DKIM如何涵蓋選定的標頭和規範化的正文內容。簽名後更改所涵蓋材料的網關可能會使簽名無效。並非每個更改都必然如此：簽名字段， 規範化 和精確的變換很重要。
獲得授權後，在可疑轉變之前和之後立即獲取安全代表資訊。保留其原始位元組並比較驗證結果、選定的標頭和規範化的正文輸入。不要比較螢幕截圖或重新保存的文本，就好像它們準確地保留了簽名訊息一樣。確定簽名是發生在頁腳插入、主題重寫或其他處理之前或之後。
單獨評估SPF
參考： RFC 7208 §4.1, RFC 9989 §4.4, RFC 9989 §5.3.5.
下游接收器根據相關資訊評估連接源 SPF 身份。因此，即使DKIM存活下來，中繼也可以改變SPF情況。 Raw SPF成功並不令人滿意 DMARC 如果根據適用的對齊規則，該經過驗證的身份與作者網域無關。
DMARC可以通過經過對齊的SPF或DKIM路徑。避免在不檢查其他機制的情況下將失敗的簽章視為整體DMARC失敗的證據。同樣，不要將網關自己的不相關簽名視為自動與原始作者對齊。
透過受控比較進行工作
假設場景，並非本次評測中執行的測試：應用程式簽署example.com ，然後出站網關附加免責聲明。假設接收測試郵箱顯示該簽章的正文雜湊失敗。 SPF傳遞不相關的服務信封網域。由於沒有其他對齊傳遞機制，此範例無法通過DMARC 。
調查需要比較保留的前後樣本，並確認被覆蓋的屍體在網關處發生了變化。建議的修復是在預期的轉換之後使用受支援的設計進行授權對齊簽名。這是一個候選解決方案，而不是聲稱每個網關都提供該功能或行動簽署者總是安全的。
驗證所選的維修
讓負責的業主批准設計和安全影響。使用代表性內容測試實際路線，包括觸發重寫的範本。在外部接收方確認一致的身份驗證並驗證業務工作流程。保持安全掃描有效；不要為了讓測試通過而隨意停用控制項。
透過驗證的路線、精確的轉換、簽名位置、保留的測試證據和回溯標準來結束事件。如果前後證據不可用，則暫定可疑原因並進行受控再現。網關標籤本身並不能證明根本原因結論或廣泛的SPF授權是合理的。