迁移域名时，DNS里到底该留哪几条记录

同事把域名解析后台的迁移截图发过来，问了一句：“这条 TXT 还留着吗？域名”我看了眼那张截图，三条 A 记录、到留条一条 CNAME、底该两条 TXT、记录一条 MX，迁移看着都不像垃圾，域名可真正能对上当前业务的到留条只有一半。DNS 设置该留哪些记录，底该本质不是记录“多留保险”，而是迁移让每条记录都能回答一个问题：它对应哪个服务、谁在用它、域名删了会怎样。到留条

下面把两种常见做法并排摆开。底该一种是记录“只留最小集”，一种是“全量保留、只改必要项”。两者都不是错，错在场景用反。

做法一：只留最小集，先把每条记录对应到服务

最小集的意思是：后台里每一条记录，都能指着某个正在跑的服务说清楚用途。典型组合是——主域名一条 A 记录指向网站服务器；www 一条 CNAME 或 A 记录；MX 指向邮件服务商；SPF、DKIM、DMARC 相关的 TXT 各就各位；需要验证归属的 TXT，在验证完成后就该评估是否删除。

这套做法适合两种情况：一是新站上线、服务清单本来就很短；二是刚接手一个来源不明的域名，想把历史包袱清干净。操作顺序建议是：先导出全部记录存档，再按“域名前缀 + 记录类型 + 指向”逐条列出，能对上服务的打勾，对不上的标问号。标问号的不要立刻删，先查它是否被某个第三方验证占着，比如搜索引擎站长平台、证书签发、协作工具的域所有权校验。

选错的后果很具体：把仍在用的 TXT 验证记录删了，站长平台可能掉验证，证书续期可能失败；把 MX 误删或改错，邮件会直接退信，而且退信往往有延迟，等发现时已经丢了几天的信。所以最小集不等于“看着没用就删”，而是“先证明没用，再删”。

做法二：全量保留，只改必须改的那几条

另一种做法是迁移时不动存量，只把指向旧服务器的 A 记录改成新 IP，其余原样保留。它的好处是风险低，尤其适合老域名、多业务混用、还有历史子系统在跑的场合。很多单位的域名下面挂着不止一个网站：主站、旧版、内部测试、某个早已没人维护但仍在收信的子域。这种情况下，全量保留是更稳的选择。

代价是记录会越积越多，最终没人说得清哪条还在生效。因此这种做法必须配一个动作：留可以，但要在表格里标注“保留原因 + 负责人 + 复查时间”。没有这三项的记录，等于给未来的自己埋问题。选错这一边，典型后果是解析冲突——同一个前缀同时存在 A 和 CNAME，或者两条 A 指向不同服务器，解析结果随机，表现为“有时能打开、有时打不开”，排查起来非常费时间。

所以两种做法的边界很清楚：服务少、可控、有完整清单，用最小集；服务多、历史长、暂时理不清，用全量保留加标注。判断标准不是胆子大小，而是你手上有没有一份能对得上的记录清单。

改之前先做一张“记录—服务”对照表

不管选哪种，动手前先做表。列四栏：记录名、类型、当前指向、对应的服务与负责人。这张表比任何教程都管用，因为 DNS 设置该留哪些记录，答案只能从你自己的服务清单里长出来，不能照抄别人的模板。

填表时注意几个容易漏的点：邮件相关的记录要整体看，MX 换了服务商，SPF 里的授权列表往往也要跟着改；泛解析（*）如果存在，会掩盖很多子域问题，先确认它是否真的需要；TTL 值在迁移前适当调小，能给回滚留出时间窗口。改完之后不要只看后台显示成功，用公共 DNS 查询工具从外部验证一遍，再实际打开网站、发一封测试邮件。

验证阶段看什么，失败时先回哪一步

验证分三层：解析层看记录是否已生效、是否只有一条预期答案；应用层看网站能否访问、证书是否正常；邮件层看收信是否正常、发信是否进垃圾箱。三层里任何一层不对，先回到对照表，确认是记录写错还是服务端没配好——很多“DNS 问题”其实是服务器没监听或防火墙没放行。

如果改完出现间歇性失败，优先怀疑重复记录和 CNAME 冲突；如果是整片打不开，先查 NS 是否指向了正确的解析商。回滚时按改之前的存档逐条恢复，不要凭记忆重填。涉及邮件、证书、支付回调这类关键链路，改之前最好找负责该系统的同事确认一句，拿不准就联系域名注册商或解析服务商的官方支持，别在后台反复试。

一张截图问“这条还留着吗”，真正要回答的其实是：它背后还有没有人在用。把这个问题逐条问完，DNS 设置该留哪些记录就不再是猜，而是有据可查的取舍。