採購審計應確定誰控制繼承的電子郵件身分、哪些業務服務依賴這些身分以及整合期間會發生什麼。不要先將收購方的DNS範本複製到每個收購的網域上。保持工作流程，同時識別不受管理的權力和證據差距。
地圖控制權和所有權
與技術存取分開記錄法律或企業所有權。確定註冊商、 DNS 、郵箱、中繼、簽名和報告帳戶，以及負責任的管理員和過渡計畫。記錄未解決的訪問，而不假設獲取完成轉移了所有技術許可。將憑證和敏感帳戶機密保留在審計登記冊之外。
將每個服務對應到其可見的 From 域、信封域、 DKIM 簽署網域名稱、來源和目標租戶、提供者關係和關鍵業務事件。申請郵件可以完全繞過員工信箱平台。包括計費、密碼恢復、支援工具、自動通知和季節性活動。
建立認證基線
擷取目前的DNS和核准的發送方配置，然後將它們與受信任的接收方觀察結果進行比較。 DMARC 取決於成功的身份驗證和 標識符對齊，不僅僅是熟悉的提供者或 SPF 經過路線中的某個地方。 RFC 9989。 DKIM金鑰發布和簽署服務是不同的依賴項，必須在任何計劃的遷移中倖存下來。 RFC 6376.
使用聚合報告來發現觀察到的來源模式，但不要將其視為完整的服務清單或業務批准證明。 RFC 9990。與應用程式擁有者、提供者帳戶記錄和授權訊息樣本協調調查結果。在確定歸屬之前，不要批准未知寄件者。
透過服務測試目標狀態
在標準化之前定義代表性交易。在適當的目的地記錄預期的識別碼、身份驗證結果和業務收據。包括正常發送、相關轉送或網關路徑以及對業務重要的計劃流。設定恢復標準並保留舊的依賴關係，直到驗證核准的轉換。
考慮三個繼承路線的假設審核。工資單有一個當前授權的樣本，並與有效的一致 DKIM簽名 並確認業務收據。 Campaign 具有已知的擁有者，但其測試樣本未能通過兩個對齊的身份驗證路徑。 Legacy 沒有目前的代表性樣本和未解決的身份。薪資單有其測試範圍的證據；活動需要技術診斷，遺留問題需要證據收集。單一投資組合範圍內的通行證將隱藏這些不同的後續行動。
這些是假設的結果，未執行身份驗證檢查、真實批准或遷移的租戶。此活動結果假設所有相關SPF和有效的DKIM對齊路徑均經過檢查，而不僅僅是一個失敗的簽章。在下面 RFC 9989 第 4.4 節和第 5.3.5 節中任一對齊的認證路徑都可以滿足訊息層級結果。另外，第 7.4 節和第 8 節要求網域發布 p=reject 應用有效的DKIM簽章而非僅依賴SPF 。傳遞訊息並不足以證明每個部署義務。
報告整合團隊可以使用的決策
單獨確認的控制、觀察到的操作、批准的例外情況和未解決的發現。列出每個發現的所有者、影響、下一步和接受證據。優先考慮關鍵服務和不受管理的權限，而不會在整體通過率中隱藏未知因素。
在租戶移動、 DNS更改、簽名密鑰更改和提供者停用後重新執行相關檢查。保留採集時代的證據，以便以後的事件可以區分繼承的配置和整合變更。僅在明確說明測試範圍和剩餘工作的情況下結束審核階段；人類風險的接受和保證聲明的發布仍然是單獨的決定。
此庫存和審核工作流程是建議的操作模型。 NIST SP 800-53 Rev. 5 CM-8 和 CM-3 為負責任的庫存和受控變更提供了一般基礎；他們不規定這些特定於電子郵件的欄位或授予批准。 NIST控制目錄.