繼承的寄件者清單是決策工具，而不是 IP 位址清單。在標準化取得的網域之前，將觀察到的郵件連接到產生該郵件的特定於客戶的服務、其業務所有者及其批准的身份。熟悉的提供者可以託管合法和不需要的流量，因此基礎設施識別本身並不能獲得批准。
從多個證據來源開始
收集授權配置匯出、應用程式註冊、供應商帳戶記錄、 DNS觀察和可用的郵件證據。保留每個觀察結果的來源和收集時間。 總結報告 可以揭示來源 IP 和身分驗證模式，但無法獨立確定組織的業務意圖或完整的寄件者群體。 RFC 9990.
對於每項服務，記錄目的、責任所有者、提供者帳戶或租戶、關鍵性、可見網域、信封網域、 DKIM 簽名身分、最後代表測試和批准證據。保持未知字段明確。分別記錄可能處於休眠或防禦狀態的域的發送和接收目的。
添加權限之前先賦予身份
將觀察到的標識符與實際的供應商配置和業務工作流程進行比較。 DMARC 用途 結盟 作者域和成功驗證的標識符之間；沒有標識符的通用通過結果可能會隱藏您需要解決的問題。 RFC 9989.
不要添加未知來源 SPF 只是因為郵件似乎是從那裡發出的。 SPF為評估的身份授權主機，其評估包括DNS查找限制。 RFC 7208 ，第 4.6.4 節。新的包含可能會擴大權限、超出操作限製或無法修復對齊。首先建立預期的服務和適當的經過驗證的路由。
將批准和測試分開
已批准的服務仍可能無法通過遷移測試；經過身份驗證的訊息仍可能來自未經批准的服務。儲存這兩個狀態。批准證據應確定負責任的決策，而測試證據應描述實際交易、身分、結果和時間。請勿使用測試通過作為企業所有權的替代品。
假設繼承的計費服務具有指定的企業所有者和核准的用途，但目標帳戶的簽章身分尚未經過驗證。第二個服務具有一致的傳遞訊息，但沒有確定的業務所有者。第一個在遷移之前需要路線證據；第二個需要歸屬和批准才能被視為授權服務。這兩個差距都沒有因為其他服務的令人放心的結果而解決。
這些是假設的庫存決策，而不是產生的記錄或執行的測試。為所有權、預期身分、批准和目前測試覆蓋範圍保留單獨的欄位。當應用程式擁有者提供缺失的帳戶證據時，僅更新其建立的狀態；不要自動將未經測試的遷移結果變更為通過。
將歸因轉變為遷移計劃
依照經過驗證的擁有者、依賴性和準備情況將服務分組。在編輯記錄之前定義預期的目標身分和測試。保留未知的路線以供調查，並指定所有者和截止日期，而不是默默地批准或刪除它們。為每次後續轉換保留舊配置和批准的恢復計劃。
標準化後，根據核准的清單協調實際觀察結果並調查新的身分。讓退休人員及其決策載入史冊。有用的庫存透過供應商變更和事件回應保留為營運記錄，而不是合併項目結束時廢棄的電子表格。
此庫存和審核工作流程是建議的操作模型。 NIST SP 800-53 Rev. 5 CM-8 和 CM-3 為負責任的庫存和受控變更提供了一般基礎；他們不規定這些特定於電子郵件的欄位或授予批准。 NIST控制目錄.