進來之前先規劃好出去的路
早在任何人簽署退出通知之前，身分驗證供應商就可能成為依賴者。當管理儀表板無法使用時，委派的DNS子樹、供應商託管的政策目標、報告郵箱或簽署安排可能會繼續影響郵件。在授予控制權之前，確定如果關係意外結束，哪些措施必須繼續發揮作用。本指南提出了退出評估；它不批准委派或描述經過驗證的EmailAuth遷移功能。
從業務服務而不是供應商帳戶開始。記錄用於員工郵件、交易訊息、行銷和非發送資產的網域，然後識別發布或使用其身份驗證資料的系統。有用的退出計劃說明誰可以恢復每個依賴項、替換配置來自何處以及團隊將如何確定合法郵件仍然可以進行身份驗證。
準確劃定權限邊界
保持註冊、權威DNS託管和應用程式管理的不同。在下面 RFC 1034，區域切割委託子樹的權限。因此，NS 委派的範圍與 NS 委派不同 CNAME 這使得一個特定的名稱依賴另一個名稱。兩者都不僅僅是查看儀表板的權限。在評估任一安排之前，記錄確切的所有者名稱、記錄類型、目標、父控制項和受影響的後代。
包括跨越明顯邊界的依賴關係。一個 選擇器 別名可以取決於供應商的DNS和簽章服務。一個 SPF include 可以使身份驗證依賴其他地方維護的記錄。報告目的地可以在根本不控制策略的情況下保持運作。對於每個連接，區分供應商更改答案的能力和客戶更換或撤銷連接的能力。如果 DNSSEC 部署後，委託一個單獨的經過驗證的鏈轉換計劃，而不是在終止期間臨時進行 DS 更改。
使退出包無需供應商即可使用
指定獨立操作所需的匯出：網域和寄件者清單、已發佈的配置、批准歷史記錄、未解決的異常、報告來源和保留元資料。詢問格式、欄位定義、時間戳記、完整性檢查以及在取消之前驗證匯出的方法。如果新操作員需要原始報告識別碼和觀察期以避免對相同活動進行兩次計數，則儀表板總計的電子表格可能不夠。
目前匯總報告指南 解決重複和重疊的報告。保留足夠的出處，以協調新舊收藏家的需求。確認誰可以接收匯出的資訊、可以保留該資訊多長時間以及誰授權刪除。不要將私人簽署金鑰或可重複使用的帳戶憑證放在一般移交文件中。如果仍在另一個平台進行簽名，請記錄託管人和批准的過渡流程。
設計一個可以觀察到的轉變
在刪除舊依賴項之前準備替換，具體以實際服務和變更批准為準。替換DNS答案必須表達預期的策略或金鑰，而不是簡單地重新建立方便的螢幕標籤。 RFC 9989 使經過驗證 標識符對齊 中心到 DMARC;複製 一個記錄 不能證明應用程式的訊息使用一致的身份。
記錄相關的權威和解析器觀察、早期快取生命週期、計劃的變更和計劃的檢查點。新降低的 TTL 不會縮短已在舊值下快取的資料。負緩存也會影響最近引入的名稱； RFC 2308 定義自己的處理方式。避免通用傳播期限。說明有哪些證據可以證明前進、暫停或恢復的合理性，包括舊供應商不再可用的可能性。
一個虛構的範例使用billing.example和供應商管理的DKIM選擇器。建議的退出要求發送平台的擁有者確定替代簽名安排， DNS擁有者檢查確切的記錄更改，以及郵件團隊隨後驗證代表訊息。本例中沒有查詢任何記錄、帳戶或訊息。保留舊的公共選擇器以進行商定的過渡可能是合適的，但受損的密鑰需要不同的復原決策。
價格責任而不是模糊的遷移
建構一個需求和證據矩陣，每個依賴項一行。對於每一行，記錄客戶所有者、供應商義務、要求的證據、驗收條件和未解決的問題。包括正常終止、供應商破產、失去管理員存取權限和緊急暫停。沒有責任方的要求是一種假設，而不是退出控制。
使用透明的工作負載估算，而不是捏造的遷移費用。作為一個虛構的規劃計算，在測試、協調、糾正和簽核之前，以二十分鐘的時間審查 12 個領域需要四個小時。該算術沒有說明實際的EmailAuth工作量或價格。分別顯示假定的網域數量、複雜性、人工費（如果獲得批准）、重疊訂閱以及任何經合約驗證的出口費用。包括一系列未解決的案例，並確定哪些不確定性可能主導時間表。
NIST CSF 2.0 將供應商要求納入協議中，並包括 GV.SC-05 和 GV.SC-10 關係結束後的活動。透過協商責任應用這些結果；該框架不承諾供應商的援助、出口權利或取消條款。商業和合法所有者必須核實適用的協議。
制定授予和釋放決定
在授予授權之前，需要提供證據證明客戶保留適當的父區控制權、其他合格的運營商可以使用退出包以及建議的恢復路徑並不完全依賴於離開的供應商。僅批准所需的確切權限。保持存取撤銷和資料刪除的順序，以便在破壞性步驟之前保留證據並檢查連續性。
目錄要求仍然開放：要求和證據矩陣以及透明的工作量或成本假設。下圖是建議的結構，而不是完整的客戶矩陣。作為已證明的供應商退出案例的發布需要實際授權庫存、合約確認、經過審查的假設和驗收證據。一份記錄性的計劃現在就可以揭露正確的問題，而無需聲稱真正的遷移已經成功。