SPF 记录检查

SPF（发件人策略框架，RFC 7208）是一条 DNS TXT 记录，声明哪些服务器可使用信封 MAIL FROM（即 return-path）中的域名发信。收信方会把建立连接的 IP 与记录中的机制比对，返回 pass、fail、softfail、neutral、none、permerror 或 temperror 等结果（RFC 7208 §2.6）。

有效记录以 v=spf1 开头，以 all 机制结尾。中间的机制列出授权来源：ip4/ip6 表示字面地址，a 和 mx 引用域名自身的记录，include 委托给其他发信方。机制按从左到右求值，首个匹配即生效，因此顺序很重要。all 前的限定符为所有未匹配项设定默认行为：-all 对未列出的发信方硬性拒绝，~all 软性拒绝，?all 中立，+all 则放行所有人。

以「v=spf1 include:_spf.google.com ip4:198.51.100.0/24 -all」为例。include 会引入 Google 自己的 SPF 记录，并计入你 10 次 DNS 查询的额度；来自 Google 公布范围内、或 198.51.100.0/24 网段的邮件判为 pass。其余落到 -all 判为 fail。若把结尾改成 ~all，未列出的发信方会被标为 softfail——通常仍投递但被标记，这是 SPF 正式强制前上线初期的常见选择。

SPF 失效大多源于以下几个反复出现的错误：

• 同一域名出现两条及以上 v=spf1——导致 permerror，应合并为一条。
• 触发 DNS 查询的机制超过 10 个——超出 RFC 7208 §4.6.4 的上限，造成 permerror。
• 以 +all 结尾——授权任意发信方，使记录形同虚设。
• 使用已弃用的 ptr 机制——速度慢，RFC 7208 §5.5 不建议使用。

• 为什么我的 SPF 因 DNS 查询过多而失败？— SPF 最多允许 10 次 DNS 查询（RFC 7208 §4.6.4）；请扁平化 include 或改用宏以控制在上限内。
• 可以有两条 SPF 记录吗？— 不可以。一个域名必须只发布一条 v=spf1，否则评估返回 permerror。
• SPF 会检查 From 头吗？— 不会。SPF 验证信封 MAIL FROM，而非可见的 From；二者由 DMARC 关联。