换了邮件服务商之后 SPF 就不好用了——迁移修复方案（2026）

发布于 2026-07-08

数据截至 2026-06-29 · 方法论 v7。 基于 261 百万个已评分域名的汇总普查数据。参见我们如何评分。

换邮件服务商之后 SPF 通常会坏掉，原因是新服务商的记录被加在了旧记录旁边。两条 v=spf1 记录是一个永久性错误——SPF 会整体作废。根据 Defaults.Exposed 对 261 百万个域名的普查，有 1,013,416 个域名——大约每 138 个尝试配置 SPF 的域名里就有 1 个——正处在这种状态。把它们合并成一条。

修法大约十分钟：扫描域名看清楚迁移到底留下了什么、列出你权威域名服务器上的每一条 SPF 记录、把它们合并成一条只包含新服务商的记录，再用 dig 重新验证。这篇指南会逐步讲解，外加大多数迁移都会忘记检查的 DKIM 和域名服务器问题。

为什么迁移完成后 SPF 立刻就坏了？

因为新服务商的设置指南说“添加这条 TXT 记录”——你照做了，加在了旧记录旁边。而这恰恰是 SPF 标准不允许的一件事。RFC 7208（§3.2，错误结果见 §4.5）规定每个域名只能有恰好一条 v=spf1 记录；接收方发现两条或以上时，必须返回 PermError，而不是去猜哪条才是权威记录。PermError 意味着 SPF 作废：不是旧记录生效，也不是新记录生效，而是根本没有 SPF。

而且事情不止于此。DMARC 把 PermError 当作 SPF 这条腿的失败处理，所以你的邮件现在完全依赖 DKIM。如果新服务商的 DKIM 还没配好——迁移过程中很常见——你恰恰是在更换基础设施的这个时刻发着未认证的邮件，而这正是接收方审查最严格的时候。

这是换服务商时会作废你防护的那个复制粘贴动作，而且并不罕见：根据 Defaults.Exposed 对 261 百万个域名的普查（数据截至 2026-06-29），目前有 1,013,416 个域名发布着两条或以上的 SPF 记录——约占尝试配置 SPF 的 139 百万个域名的 138 分之一。关于双记录陷阱的完整数据有自己的报告；这一页讲的是操作层面的修法。

迁移留下了哪些残留？

几乎每一次迁移后的 SPF 失败，都是这五种残留物之一造成的。按这个顺序检查：

留下了什么	你会看到什么	修法
旧的 SPF 记录还留在 DNS 里，和新记录并存（两条 `v=spf1` 记录）	检测工具报告“多条 SPF 记录”或 PermError；SPF 整体停止工作	合并成一条记录，删掉其余的——见下方步骤
你唯一那条记录里还留着旧服务商的 `include:`	SPF 能用，但白白浪费 DNS 查询次数，而且旧服务商的服务器仍然能以你的名义发信	等邮件完全从旧系统排空后再移除它
从没添加过新服务商的 `include:`	来自新服务商的邮件在接收方那里 SPF 失败	把它加进现有的那一条记录——绝不要新建一条记录
没有为新服务商创建 DKIM 选择器	`dkim=fail`，或者签名来自服务商的默认域名；DMARC 没有第二条腿	发布新的选择器——见下方第 6 步
记录只在旧的域名服务器上更新过	问不同的人得到不同答案；间歇性失败	在权威域名服务器上修好那个区域；切换期间两组都要核实

我该怎么修？迁移检查清单

先在 defaults.exposed 运行免费扫描。 它会读取你实时的 DNS，告诉你是否有多条 SPF 记录、缺少 include，或存在 DKIM 缺口——先诊断，再动手。
列出权威域名服务器上的每一条 SPF 记录。 dig +short NS yourdomain.com，然后针对其中一台跑 dig +short TXT yourdomain.com @<nameserver>。数一数有多少条以 v=spf1 开头的字符串。唯一安全的数字是 1。
合并成一条记录。 一条记录，以 v=spf1 开头，包含你新服务商的 include 和你仍在用的任何其他发信方（开票工具、CRM、通讯平台），以一个 -all 或 ~all 结尾。举例——旧的是 Google Workspace，新的是 Microsoft 365，正处在排空阶段：
```
之前：  "v=spf1 include:_spf.google.com ~all"
        "v=spf1 include:spf.protection.outlook.com -all"

之后：  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
后续：  "v=spf1 include:spf.protection.outlook.com -all"
```
服务商的具体值和 DNS 面板的各种坑，见 Google Workspace 和 Microsoft 365 的设置指南。
删除多余的记录。 只合并不删除等于没修——PermError 是因为记录条数导致的。
只在旧系统仍在发信时才保留旧服务商的 include——比如定时报表、一个旧的 CRM 连接器、一个被遗忘的邮箱。排空完成后就移除它：一个残留的 include 会让旧基础设施继续拥有以你名义发信的权限，而且每一个 include 都会消耗 DNS 查询次数，逼近 SPF 硬性上限 10——至少已有 797,263 个域名因为超出这个上限而作废了自己的 SPF（普查数据，2026-06-29）。
设置新服务商的 DKIM——但先别删旧的选择器。 新的选择器负责签新邮件；旧的选择器必须继续发布，直到所有用它们签名的邮件都已送达，转发也都处理完。完整操作见换工具之后 DKIM 失败。
如果你连域名服务器也换了，两边都要检查。 DNS 迁移常常和邮件迁移一起进行。直接查询新旧两组域名服务器（dig TXT yourdomain.com @old-ns 和 @new-ns）——在注册商的委托完全传播完成之前，一些接收方仍会问旧服务器，所以修好的记录必须在被查询到的那一组服务器上都存在。
重新运行扫描，确认 SPF 显示为一条有效记录且通过检查。

SPF 实际检查的是哪个域名？

接收方是对照 Return-Path（RFC5321.MailFrom）域名——也就是退信地址——来评估 SPF 的，而不是收件人看到的 From 标头。迁移之后这一点会有双重影响：在你配置自定义退信域名之前，新服务商可能会用它自己的退信域名；而且 SPF 在一个不属于你的域名上“通过”，对 DMARC 毫无对齐意义。这个问题的修法是新服务商的 DKIM，用你的域名签名。

同时在迁移和改名？

既换了服务商又换了域名？ 把它们当成两项独立的工作。新域名从第一天起就需要完整的一整套——SPF、DKIM、DMARC；用新域名邮件配置清单。旧域名要在转发或回复流量还经过它的这段时间里保持认证，一旦停放，就要明确地锁死它（而不只是放着不管）。一个带着残留、半坏 SPF 的旧域名，就是一个顶着你旧名字的伪造靶子。

常见问题

迁移期间我能不能同时保留两条 SPF 记录？ 不能。标准里没有宽限期这回事——从第二条 v=spf1 记录出现的那一刻起，就是 PermError，而根据普查（2026-06-29），目前有 1,013,416 个域名正处于这种状态。迁移安全的做法是：在过渡期用一条记录同时携带两个服务商的 include。

旧服务商的 include 该保留多久？ 保留到没有任何邮件再经旧服务商发出为止——通常就是你的过渡窗口长度，几天到几周不等。留意任何仍经旧系统到达的邮件的 Return-Path；那部分流量一停，就移除 include，并重新核对你的查询次数。

为什么我修好之后，检测工具还是显示我的旧记录？ DNS 缓存会遵守记录的 TTL，如果你换了域名服务器，一些解析器可能仍在查询旧的那组。直接在权威域名服务器上用 dig TXT yourdomain.com @<ns> 核实——如果那里的答案是对的，修复就已经完成，缓存会慢慢跟上。如果某一组域名服务器上的答案就是错的，见 “SPF 记录未找到”——真正的原因。

换服务商时需要改 DMARC 吗？ 记录本身通常不需要改——它写的是你的报告邮箱和策略，不是你的服务商。但你的 DMARC 结果取决于你刚迁移的 SPF 和 DKIM：切换期间报告量可能会下降，先确认两条腿都通过了再收紧策略。如果扫描显示 SPF 这条腿仍在失败，从修复 SPF 开始。

把报告发给老板

如果你是在替客户做这次迁移，用证据来收尾。合并生效后重新运行免费扫描，把评分报告转发给企业负责人：SPF、DKIM 和 DMARC 在新服务商上全部通过，用大白话写清楚，带日期。这是他们要归档用于网络保险续保和下一份供应商安全问卷的凭证——证明这次迁移让域名的认证水平比之前更好，而不是更差。

检查你的域名 → · 换工具之后 DKIM 失败 → · “SPF 记录未找到”——真正的原因 → · 我们如何评分 → · 仅使用汇总数据。数据在欧盟境内存储和处理。