离开托管供应商 SPF 逻辑或 DKIM DNS记录更改实时信任依赖关系。这不仅仅是取消订阅。首先清点确切的DNS名称和签名路由，然后在您仍然具有恢复的访问权限和权限时替换依赖项。除非计划真正需要，否则将仅报告的更改保留在同一更改窗口之外。
确定供应商控制的内容
对于SPF ，记录实际发布的策略以及每个包含或重定向关系。包含被评估为SPF机制；重定向在适用时提供另一项策略。两者都不仅仅是一个装饰性的别名。根据DNS查找限制评估生成的策略 RFC 7208，包括嵌套依赖项。复制当前扩展的 IP 地址可能会变得过时，并且无法保留供应商未来的更新。
对于DKIM ，记录每个活动 选择器，其确切的DNS所有者名称，任意 CNAME 或使用相应私钥的区域委托和签名服务。 RFC 6376 将签名与公钥检索分开。移动公共记录不会为替换服务提供旧的私钥，并且更改别名不会导致使用新选择器对现有消息进行签名。
在删除旧路径之前构建替换路径
使用为目标帐户生成的值建立新的发件人授权或签名路由。验证权威DNS并测试通过每个关键应用程序接收到的消息。如果DNS或提供商限制阻止共存，请记录该限制并使用经过测试的恢复路由进行受控切换。不要假设同一SPF所有者名称的两个不同TXT策略会产生冗余。
在旧签名停止后，为批准的延迟邮件窗口保留旧DKIM公钥的可用性。适当的间隔取决于队列行为、签名有效性约束、操作风险和提供商保留。没有通用的 TTL 长度等待规则： DNS缓存和延迟传送是不同的时钟。尽管延迟邮件失败，但受损的密钥可能需要撤销，这是一个事件决定，而不是例行的迁移内务处理。
区分新签名和延迟验证
假设旧的排队消息携带选择器old，而新生成的消息携带选择器new。每个签名在生成时都是有效的，并且消息保持不变。如果旧的公共记录在接收者检索之前被删除，则即使新签名使用自己的密钥进行验证，该接收者也可能无法验证旧签名。缓存的可用密钥或另一个有效签名可以更改观察到的结果，因此这不是通用的交付预测。
此假设的依赖项示例不执行签名、 DNS查询或验证。恢复正确的公共记录可以恢复该查找路径，但无法修复过期的签名、更改的消息或受损的签名密钥。取消前，分别验证新的发送路径、批准的旧密钥保留或撤销决定以及实际的恢复访问。公共记录导出无法恢复私人签名功能。
在适当的情况下使出口可逆
更改记录应标识旧的依赖关系、替换、批准、预期的DNS答案、身份验证测试、延迟邮件决策和回滚触发器。保持服务处于活动状态，直到通过所需的更换测试。如果恢复需要过期的帐户或您不再控制的域关系，则它不是可执行的回滚。
在商定的观察窗口之后，通过批准的流程删除过时的SPF授权、选择者委托和访问。重新检查实际的权威答案和代表性接收者结果。保留准确的前后记录以及未解决的异常情况。成功的仪表板取消是服务的商业端，而不是技术退出安全的证据。