进来之前先计划好出去的路
早在任何人签署退出通知之前，身份验证供应商就可能成为依赖者。当管理仪表板不可用时，委派的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 关系结束后的活动。通过协商责任应用这些结果；该框架不承诺供应商的援助、出口权利或取消条款。商业和合法所有者必须核实适用的协议。
制定授予和释放决定
在授予授权之前，需要提供证据证明客户保留适当的父区控制权、其他合格的运营商可以使用退出包以及建议的恢复路径并不完全依赖于离开的供应商。仅批准所需的确切权限。保持访问撤销和数据删除的顺序，以便在破坏性步骤之前保留证据并检查连续性。
目录要求仍然开放：要求和证据矩阵以及透明的工作量或成本假设。下图是建议的结构，而不是完整的客户矩阵。作为已证明的供应商退出案例的发布需要实际授权库存、合同确认、经过审查的假设和验收证据。一份记录性的计划现在就可以揭露正确的问题，而无需声称真正的迁移已经成功。