確定哪個 Microsoft 服務接收訊息
「Microsoft 託管的郵件」並未識別一項通用轉送策略。首先確定目標是Microsoft 365組織、消費者Outlook .com 帳戶或是在到達 Microsoft 信箱之前經過另一個安全服務的路由。不應假定一種環境中可用的管理控制和證據適用於另一種環境。
此工作流程使用組織管理郵件的最新Microsoft 365文檔，並需要驗證實際路由。這是擬議的調查和變更計劃，而不是檢查或修改任何租戶設定的報告。首先進行直接與轉送的比較，然後選擇最小的變更來解決已證明的故障，同時保留組織的安全控制。
找到身份驗證發生變化的邊界
繪製從原始發送方通過每個轉發器或網關到接收服務的路徑。對於每個邊界，記錄連接主機，可用 信封寄件人, 作者域, DKIM 簽名和觀察到的轉變。將入站第三方中介與向外轉送郵件的Exchange Online分開來。即使它們都發生在同一個對話中，它們也是不同的操作案例。
SPF 使用最終連接來源作為在那裡評估的身份，因此原始來源的授權可能不會描述轉發連接。 RFC 7208第 10.3 節 解釋了這一限制。分析師不應更改原始寄件者的 SPF記錄 直到了解受影響的身份和預期授權。
使用比較原始簽名和最終簽名 RFC 6376。當網關的內容變更之後更改所覆蓋的材料時，可能會使簽名無效 規範化。這是有條件的，而不是聲稱所有新增的標頭或所有轉送規則都會破壞DKIM 。在授權的地方保留原始訊息副本，以便可以測試假設，而不是從供應商圖表推斷。
讀取 Microsoft 結果而不重命名它們
微軟的 身份驗證概述 區分SPF 、 DKIM和 DMARC 來自複合身份驗證，記錄為 compau。後者包含額外的評估。將每個欄位和最終處理操作保留在單獨的列中。複合通行證不應在事件記錄中重寫為普通DMARC通行證。
目前的 值得信賴的ARC密封劑指南 描述了使用合法中介機構的早期評估，並提供了 compauth=pass 和reason=130的診斷範例，而dmarc=fail仍然可見。它還警告其他過濾仍然可以發揮作用。這是特定於提供者的解釋，用於在受信任的接收者產生的結果中進行驗證，而不是保證相同的欄位出現在每個帳戶中。
不要輕信任意的 Authentication-Results 行只是因為它靠近粘貼標題的頂部。確定哪個接收系統產生結果以及如何識別可信任邊界。如果只有螢幕截圖或摘錄可用，請記錄缺少的出處，並透過核准的流程要求適當編輯的完整樣本。
保持 SRS 和ARC決策的區別
微軟的 SRS 文檔 專注於適用的轉送和中繼場景，並明確將重寫的 MAIL FROM 與可見的 From 分開。它還記錄了例外情況。不要假設進入Microsoft 365每個訊息都會收到相同的重寫，或將其視為向外發送 SRS 行為作為修復不相關的入站網關的行為。
重寫的信封可以支援重寫域的SPF ，而無需 結盟 給原作者。仍需要相關的域關係 RFC 9989第 4.4 節. ARC 相反，傳達早期的身份驗證評估供接收者考慮。 RFC 8617第 7.2.1 節 描述了本地策略的使用，而不是自動替換普通認證結果。
任何信任密封者的建議都是安全決定。確定確切的合法服務、其營運需求和負責任的審批者；保留先前的配置和刪除標準。不要僅僅因為訊息攜帶語法上有效的ARC集而添加廣泛信任。目前的 ARC重新分類草案 工作正在進行中，而RFC 8617在此審核日期仍處於實驗階段。
透過有界驗收測試進行虛擬閘道更改
在此虛構範例中，範例服務在Microsoft 365郵箱之前透過內容閘道接收郵件。發明的直接樣本驗證了對齊 DKIM簽名;等效的網關路由樣本具有重寫的附件，並且不再驗證該簽章。這個場景假設這些觀察結果只是為了解釋調查。沒有存取任何租戶或訊息。
業主首先要確定是否有必要進行改造，以及是否支援破壞性較小的配置。如果提出基於 ARC 的處理，則審查將需要實際的密封者身分、經過驗證的鏈證據和特定租戶的批准。驗收標準將分別記錄普通認證、綜合結果、安全過濾和處置。僅憑成功的收件匣外觀並不能證明預期的機制。
恢復標準應包括意外的廣泛信任、新的錯誤分類或未保留所需證據。回滾計劃應該確定確切的批准配置，而不是簡單地指示某人在訊息到達之前停用安全處理。
僅關閉已驗證的路由
授權更改後，將新的直接和間接樣本與代表性訊息的基線進行比較。保留設定版本、時間戳記以及任何剩餘的提供者或租戶的不確定性。通過一個網關的工作路徑不會驗證組織中的每個轉送規則。
原始證據門保持不變且可見：直接和間接傳遞樣本與路線、信封、簽名和可信結果進行比較。這裡不包括此類操作證據、租戶批准、現場測試或恢復執行。可交付成果是一個可審查的流程，具有來源支援的區別，而不是完整的Microsoft 365修復。