DNS 迁移检查清单：网站搬迁与邮件收发

先明确究竟迁移什么

更换域名注册商、更换权威 DNS 服务器、迁移网站，以及更换邮件服务商，是不同的工作。开始前应写清楚哪些事项属于本次范围。更换网站托管服务并不自动要求迁移邮件。

我们建议把交接表分为四项：域名管理、DNS、网站和邮件。每项注明原服务商、新服务商、负责人和所需权限。这样，“迁移域名”就成为边界清楚的修改任务，接手人员也能知道哪些服务应保持不变。

明确保留邮件及其他依赖

自动导入的 DNS 记录应与现有清单核对。Cloudflare 建议检查实际使用的服务记录，并向相关邮件服务商确认邮件配置值。

修改前保存原 DNS 区域，并为含义不明的记录指定核实负责人。新代理商不应猜测某个看似复杂的 TXT 值是否仍有用途。请相关负责人给出有依据的决定。“不知道是什么”不足以成为删除理由。 [1]

左右滑动可查看完整表格。

较短 TTL 不能代替迁移计划

TTL 表示 DNS 应答可以被缓存的时间。之后缩短 TTL，并不会追溯清除已经保存的应答。

以下只是规划示例，不是统一等待期限：某条记录原先为 3,600 秒，计划改为 300 秒。如果到切换时才降低 TTL，之前可能存在的一小时缓存并未消失。应提前安排修改，并按约定保留一段新旧服务重叠运行时间。其他缓存层、名称服务器委派和 DNSSEC 可能有各自的时间参数。 [2]

不要让旧子域名继续指向已释放资源

如果 DNS 仍指向已弃用且他人可以重新认领的资源，可能发生子域名接管。但仅凭目标无法解析，并不能证明它可被接管。

为每个停用服务记录名称、目标、原账户、负责人和关闭决定。先受控地修改或删除引用，考虑剩余缓存时间，再释放旧资源。之后还应检查应用和文档中的链接。特别注意，不要误停仍合法使用同一名称的新服务。 [3]

将 DNSSEC 纳入切换计划

更换名称服务器时，上级区域的 DS 记录必须与 DNSSEC 密钥匹配。过期的信任链可能使执行验证的解析器返回 SERVFAIL。

由 DNS 负责人制定具体迁移流程。部分服务商支持在持续签名状态下协调迁移；其他情况下，临时停用与重新启用应属于同一变更计划。永久关闭 DNSSEC 不能算是妥善收尾。如果只是更换网站主机，并未更换 DNS 运营方或签名密钥，应先确认信任链是否需要改动。 [4] [5]

完成验收后再关闭迁移任务

新首页的截图只是验收的一部分。应约定检查时间、负责人和回退方案。记录需要区分已经验证的事项与仍未完成的事项。没有执行的邮件测试必须保留为待办。

• 比较迁移前后的 DNS 清单。
• 打开网站、www、重定向和约定的子域名。
• 记录获授权的邮件测试及发件域名认证结果。
• 如涉及 DNSSEC 和委派，进行相应检查。
• 先清理旧引用，再按计划释放闲置资源。
• 撤销不再需要的代理商权限和 API 密钥。
• 记录新的负责人及下一次检查时间。

可填写的 DNS 迁移交接表

使用共享记录整理迁移工作。CSV 模板涵盖网站、电子邮件、验证记录和 DNSSEC。请为每条实际使用的 DNS 记录单独添加一行。模板不含测试结果，不会发起查询，也不会更改任何设置。

从相关服务商账户中获取当前值和计划值，并记录批准情况、预期结果及实际取得的证据。未执行的测试应保持待处理状态；较短的 TTL 或可以打开的主页并不代表整个迁移已通过验收。

请将填写后的文件保存在您自己的受保护存储空间中。不要填写密码、API 密钥或其他凭据，也不要通过公开联系表单提交基础设施详情。 [1] [2] [3] [5]

左右滑动可查看完整表格。

下载 DNS 交接表（CSV）

更换域名服务器后收不到邮件？

先区分是收件、发件还是某一个发送服务受到影响，记录时间与完整错误信息。随后将新的权威 DNS 区域与保存的原始记录、邮件服务商要求进行比对。

不要凭猜测同时修改多项保护。投递故障不意味着应全面关闭 DMARC 或删除用途不明的记录。分别记录原因、针对性修复和实际结果。 [1] [2] [4] [5]

左右滑动可查看完整表格。