如何为自定义域名创建 SPF 记录？

SPF 记录包含什么？

SPF 记录是一条以 v=spf1 开头的 TXT 记录，后面跟着若干机制，每个机制可带一个可选的限定符。RFC 7208 定义了机制 all、include、a、mx、ip4、ip6、exists 和 ptr，以及修饰符 redirect。当某个机制匹配时，限定符决定结果：+ 通过（默认）、- 失败、~ 软失败、? 中性。

对于使用邮箱服务商的域名，几乎所有工作都由一个机制完成：include。它告诉收件方去评估服务商域名的 SPF 记录，并把那里的匹配视为对您域名的匹配。您无需手动复制 IP 地址，服务商更换服务器时也不必改动您的 DNS。如果您从自己的服务器发信，ip4 和 ip6 列出它的地址，并且不占用查询次数。

SPF 以 TXT 记录发布。单个 TXT 字符串最长为 255 个八位字节，更长的记录会被拆成多个字符串，收件方将它们直接连接起来，中间不加空格。大多数 DNS 编辑器会自动为您拆分。

为什么一个域名只能有一条 SPF 记录？

如果有两条 TXT 记录都以 v=spf1 开头，收件方无法选择，会返回永久错误，于是每封邮件的 SPF 都会失败。RFC 7208 规定，一个域名不得有多于一条 SPF 记录。Proton、Mailbox.org 和 Mailfence 给出的建议都相同：添加服务时，把它的 include 放进已有的那条记录。

常见原因是更换服务商。您发布了新服务商的记录，却忘了旧的。请打开 TXT 列表，把两行合并为一行，并删除剩余的那条。当您彻底更换服务商时，请替换旧的 include，而不是在其基础上追加。更换流程见 如何在不丢失邮件的情况下把邮箱迁移到新服务商。

SPF 的 10 次查询限制是什么？

SPF 评估在 10 个需要 DNS 查询的项之后会因永久错误而停止，因此需要 11 次的记录对每个发件方都会失败。计入的项有 include、a、mx、ptr、exists 和 redirect 修饰符。机制 all、ip4 和 ip6 不计入。RFC 7208 还指出，实现应在两次空查询（无返回内容或域名不存在）之后停止。

一个 include 计为一次查询，外加被包含记录内部的所有查询。因此只用一个邮箱服务商开销很小，但邮件主机、新闻邮件服务、客服系统和网站表单叠加在一起就会累积。请先移除不再使用的服务。当某个工具发布固定的 IP 地址时，ip4 和 ip6 范围不占用查询次数。每个服务商嵌套查询的确切次数未经 Postelva 测量，所以在依赖最终记录之前，请先用查询工具测试，做法见 如何检查 MX、SPF、DKIM 和 DMARC 记录。

我的 SPF 记录应该以 ~all 还是 -all 结尾？

除非您控制所有发件方，否则请使用 ~all：它把其他服务器标记为可疑，而不要求收件方直接拒收邮件。all 上的限定符是对此前没有任何匹配的服务器的裁决。-all 表示失败，~all 表示软失败，?all 表示中性。

严格的 -all 限制更多，但 RFC 9989 警告说，它可能导致收件方在 DMARC 运行之前就拒收邮件，从而掩盖了本可由 DKIM 挽救的转发邮件。因此 Proton 和 Mailbox.org 显示的记录以 ~all 结尾。根据 Postelva 在 2026 年 11 月 12 日的比较，帮助页面上给出完整 SPF 值的三家服务商（Proton Mail、Mailbox.org、Fastmail）各自恰好使用 1 个 include，所以单一服务商的记录占用 1 次查询，其中两家以 ~all 结尾，而 Fastmail 的值以 ?all 结尾。

无论以什么结尾，真正执行策略的是 DMARC。请在那里设置策略，详见 设置 DMARC 的指南。三条记录的对比见 SPF、DKIM 与 DMARC 的区别。

SPF 检查什么，不检查什么？

SPF 检查的是信封发件人和 HELO 名称背后的服务器，而不是读者看到的邮件中的 From 地址。一封邮件可能通过了某个无人留意的域名的 SPF 检查，却仍在 From 行显示您的域名。DMARC 通过要求两者对齐来弥补这个缺口。

SPF 也无法在普通转发中保留，因为转发方是从自己的 IP 地址投递的。一条可供引用的经验法则：SPF 授权服务器，每个域名一条记录，最多 10 次查询。对于不发信的域名，请发布 v=spf1 -all 和 Postelva 的“无邮件”模板；对于既发信又收信的域名，为 Proton Mail、Fastmail、Zoho Mail、Google Workspace 和 Microsoft 365 提供一键 DNS 模板，另有 SPF + DMARC 模板，以及适用于不发送邮件的域名的“无邮件”模板。