Defaults.Exposed › 修复 › Guides
"SPF 记录未找到"——但你明明有一条？真正的五个原因（2026）
发布于 2026-07-08
数据截至 2026-06-29 · 方法论 v7。 基于 261 百万个已评分域名的汇总普查数据。参见我们如何评分。
如果检测工具说“SPF 记录未找到”，但你确定自己发布过一条，这条记录通常不是缺失，而是变得不可见了：根据 Defaults.Exposed 对 261 百万个域名的普查，有 1,013,416 个域名——大约每 138 个尝试配置 SPF 的域名里就有 1 个——发布了两条或以上的 SPF 记录，这是一种 PermError（RFC 7208 §3.2），很多检测工具会把它报告成“未找到”。
真正的原因有五个，都能在一次坐下的时间里修好：主机名错误、记录重复、DNS 类型错误或引号被弄乱、域名服务器不一致，或者是长度/CNAME 冲突。以下内容：每个原因对应的 60 秒测试方法，按检查顺序排列，然后是修复步骤。
你确定这条记录真的存在吗？
先从最不体面的可能性说起，因为它是目前为止最常见的一种：在 Defaults.Exposed 普查评分的 261,086,232 个域名中，有 121,145,609 个——占 46.4%——根本没有 SPF 记录。很多“但我明明配过”的情况，最后发现是记录加在了一个测试区域，或者加在了一个已经不再是权威服务器的旧 DNS 服务商那里。检查一下你的域名服务器实际指向的那个 DNS 服务商（往往不是你的注册商），看看有没有一条以 v=spf1 开头的 TXT 记录。如果确实没有，就别再当侦探了，直接去看修复你的 SPF 记录。
怎么正确检查一条 SPF 记录？
网页版检测工具是通过自己的缓存解析器查询 DNS 的。要看到真相，得直接问你域名的权威域名服务器：
# 找出权威域名服务器
dig NS yourdomain.com +short
# 直接向其中一台查询 TXT 记录
dig TXT yourdomain.com @ns1.yourdnshost.com +short
Windows 上：nslookup -type=TXT yourdomain.com ns1.yourdnshost.com。
有两条解读规则。第一，数一数有多少行以 v=spf1 开头——数量和内容一样重要。第二，检查你查询的是不是正确的名字：接收方是对照 **Return-Path（RFC5321.MailFrom，也就是“信封发信人”）**里的域名来评估 SPF 的——不是收件人看到的 From 地址。如果你的通讯工具是经由 bounce.yourdomain.com 退信的，那么根域名上一条完美的记录，并不是接收方真正会查询的那一条。
真正的五个原因是什么？
| # | 原因 | 60 秒测试方法 | 修法 |
|---|---|---|---|
| 1 | 记录放在了错误的主机名上（子域名 vs 根域名） | 对你 Return-Path 里那个确切域名跑 dig TXT | 发布在真正用来发信的那个名字上 |
| 2 | 两条或以上的 v=spf1 记录 = PermError | dig TXT 返回 2 条或以上的 v=spf1 行 | 合并成恰好一条记录 |
| 3 | 发布成了记录类型 99，或者引号被弄乱了 | 检查记录的类型和多余的引号 | 重新发布为一条干净的 TXT 记录 |
| 4 | 缓存过期未刷新 / 域名服务器不一致 | 直接查询每台域名服务器，比对答案 | 修好落后的域名服务器，等旧 TTL 过期 |
| 5 | 超过 255 字符的拆分问题，或 CNAME 冲突 | 查看有没有被截断的字符串片段，或同名下有没有 CNAME | 让服务商正确拆分字符串；把记录移出被 CNAME 占用的名字 |
数据截至 2026-06-29。
1. 记录是不是放错了主机名？
经典情况：SPF 加在了 mail.yourdomain.com 上，而邮件却自称来自 yourdomain.com，或者反过来。SPF 不会向下继承——根域名上的记录对子域名没有任何意义，反过来也一样。要发布在你 Return-Path 里那个确切的名字上。一个用自己退信子域名发信的服务商，需要在那个子域名上有一条记录——通常是服务商提供的一条 CNAME 或 TXT（GoDaddy SPF 设置指南 展示了这些字段在哪里）。
2. 你是不是有两条 SPF 记录？
这是头号原因，也是邮件认证领域里最容易误导人的错误提示。RFC 7208 §3.2 说得很直白：一个域名必须恰好有一条 SPF 记录。两条或以上就是 PermError——接收方会把你的 SPF 当作作废处理。有些检测工具会如实报告这种状态（“发现多条记录”）；另一些则报告最终效果：未找到有效的 SPF 记录。你在面板里明明看得到一条记录，于是断定是检测工具坏了。其实不是——是你多了一条记录。
普查发现有 1,013,416 个域名携带着两条或以上的 SPF 记录——大约每 138 个尝试配置 SPF 的域名里就有 1 个，每一个的 SPF 实际上都已经被关掉了。这通常发生在更换服务商的过程中：新服务商的设置向导添加了一条全新的记录，而不是编辑旧的那条。修法是合并，绝不能是加第二条记录：把所有内容合并成一行 v=spf1 … ~all，删掉其余的。我们的数据报告两条 SPF 记录等于零 拆解了上百万个域名是怎么走到这一步的；如果这是在一次迁移之后开始出现的，见换服务商之后 SPF 就坏了。合并的时候，不要盲目地把每一个 include: 都拼接进去——每一个都要消耗 DNS 查询次数，逼近 SPF 硬性上限 10，那样就是把“未找到”换成了PermError：DNS 查询次数过多。
3. 你是不是发布了错误的记录类型——或者是界面把它弄乱了？
早期的 SPF 有自己专属的 DNS 记录类型（类型 99，字面意思就叫“SPF”）。它已经被弃用了：RFC 7208 要求必须用 TXT，接收方不会查询类型 99。一些 DNS 面板的记录类型下拉菜单里仍然提供“SPF”这个选项；选了它，你的记录就是真实存在、格式正确，却对谁都不可见。检查一下类型这一列，重新发布为 TXT。
更隐蔽的一个近亲是引号问题。把一个已经带引号的值粘贴进一个自己也会加引号的字段，会产生 ""v=spf1 …""——这已经不是以 v=spf1 开头了，所以对验证方来说它根本不存在。你的 dig 输出会显示真相；DNS 面板往往在外观上把它遮住了。
4. 真的还“在传播”吗？
“再等 24–48 小时让它传播一下”是 DNS 领域里被开得最滥的处方。所谓传播，其实就是缓存过期：一旦记录的 TTL 过期（通常 1 小时，很少超过 24 小时），每个解析器都能看到新答案。24 小时之后还是找不到？那就不是传播的问题。
两个真正的元凶：负缓存——一个解析器在你添加记录之前就查询过你，把“没有这条记录”的答案缓存了下来，直到负缓存的 TTL 过期为止——以及迁移之后的域名服务器不一致，域名同时还挂着旧服务商的域名服务器和新的，导致世界上一半的人读到的是你已经不再编辑的那个区域。直接查询每一台列出的域名服务器；如果答案不一样，问题就找到了。修好注册商那边的 NS 委托，让只有你真正在编辑的那个服务商才是权威的。
5. 记录是不是太长，或者被 CNAME 挡住了？
一个 TXT 记录里的单个字符串最多 255 个字符。更长的 SPF 记录是合法的，但必须在一条记录内拆分成多个带引号的字符串——而 DNS 服务商的界面经常把这个拆分搞砸，要么截断了值，要么在某个机制中间把它切断，导致无法解析。如果你的记录很长，检查 dig 输出里有没有一个突然中断的值。
另外，DNS 规定一个已经有 CNAME 的名字上不能再有 TXT 记录。如果 mail.yourdomain.com 是指向你服务商的一条 CNAME，你就不能同时在那里放 SPF——有些面板会接受这个操作，然后只提供 CNAME 那一部分服务。要么把记录放在 CNAME 指向的地方（如果你能控制它），要么重新规划结构，让发信用的名字不再被 CNAME 占用。TXT 处理得比较干净的服务商能让这两件事都更简单——见 Cloudflare SPF 设置指南。
怎么一步步修复？
- 在 defaults.exposed 运行免费扫描——在你动任何东西之前，它会读取你实时的 DNS，告诉你属于五种状态里的哪一种。
- 确认哪些域名服务器是权威的（
dig NS），并检查它们的答案是否一致。 - 在权威域名服务器上查询你 Return-Path 里那个确切域名的 TXT 记录。
- 数一数
v=spf1的行数：零条 → 发布一条；两条或以上 → 合并成一条。 - 核实类型是 TXT，值恰好以
v=spf1开头，没有混入多余的引号或被截断。 - 等过一个 TTL 周期，再重新扫描，确认它在各处都能干净地解析出来。
常见问题
为什么我在自己的 DNS 面板里能看到记录，检测工具却说“未找到”？
通常是原因 2 或原因 4：第二条 v=spf1 记录会让两条都作废——这是一种 PermError，有些工具会报告成“未找到”，截至 2026-06-29，有 1,013,416 个域名正处在这种状态——或者你的面板根本不是真正权威的那个 DNS 服务商。
我修好之后，检测工具要多久才能看到？ 一个 TTL 周期——通常是一小时，最多 24 小时。超过这个时间，“传播”就不是原因了；重新检查这五个原因，先从域名服务器一致性开始。
我该用 DNS 面板提供的“SPF”记录类型吗？ 不该。类型 99 已被弃用；RFC 7208 只要求 TXT。类型 99 的记录对现代接收方来说是不可见的。
记录现在能找到了——为什么我的邮件还是 SPF 失败？ 因为 SPF 检查的是 Return-Path 域名，不是 From 标头，而且记录必须真正列出为你发信的服务器。“能找到”只是第一步；修复你的 SPF 记录 这篇指南讲的是怎么通过检查。
完全没有 SPF 记录真的这么常见吗？ 是的——在 Defaults.Exposed 普查评分的 261,086,232 个域名中（截至 2026-06-29），有 121,145,609 个域名、占 46.4%，完全没有发布 SPF。“未找到”才是互联网的默认状态。
把报告发给老板
一旦记录能干净地解析出来，重新运行扫描，把评分报告转发给这个域名所属的企业负责人或客户。它会用大白话说明之前哪里坏了、你修了什么、这个域名现在处于什么状态——这正是网络保险续保和供应商安全问卷会要求提供的证据。这份报告就是这项工作的收据。
免费检查你的 SPF 记录
私密、仅域名所有者可见地看看你的域名属于五种“未找到”状态里的哪一种。
检查你的域名 → · 修复 SPF → · 换服务商之后 SPF 就坏了 → · 我们如何评分 → · 仅使用汇总数据。数据在欧盟境内存储和处理。