SPF算法：DNS里那份发件人白名单

邮件发出去，对方回一句“没收到”，退信里飘着 SPF 相关的英文报错——先别急着换服务器，也别一口咬定 IP 被拉黑了。多数时候问题不在机器上，而在 DNS 面板里那条不起眼的 TXT 记录。SPF算法 干的事很朴素：提前告诉全世界“哪几台机器有资格用我的域名发信”，收件方收到信就去查，对得上放行，对不上打折或者直接退回。它平时不显眼，可一旦写错，丢信、进垃圾箱都跟着来。

SPF算法在DNS里就一行TXT记录

做法简单到有点不像话：域名解析里加一条 TXT 记录，主机记录填 @（针对主域名），记录值大概长这样 v=spf1 ip4:203.0.113.10 include:_spf.example.com -all。开头 v=spf1 是声明版本，后面的 ip4: 就是允许发信的地址，末尾那个 all 是兜底规则。

机制就那么几种，ip4 / ip6 直接写 IP，a 指向某个域名解析出来的地址，mx 指向域名 MX 记录对应的那些机器，include 是把别人家的 SPF 记录拉进来——用第三方发信平台，基本躲不开这个。ptr 和 exists 现在不推荐用了，反解这东西太不稳定。写完保存，等 DNS 生效，这事理论上就完了，理论上的意思你懂的。

结尾那个all，三种写法差别不小

-all 是硬失败，对不上就拒；~all 是软失败，标一下但通常还是收，更多是默默进垃圾箱；+all 等于拿着喇叭喊“我这域名谁都能用”，随便哪台机器都能冒充你发信。见过有人测试时图省事写 +all，上线忘了改，后来被拿去发垃圾邮件的。正式环境别碰它，真要试就单独开个子域名去折腾。

10次查询这道坎，超了直接permerror

include 这东西会一层套一层。你的记录 include 平台的，平台的记录又 include 它自己的上游，查起来没完。规范里对 SPF 的 DNS 查询次数是有上限的，超了就是 permerror，信照样出不去，具体数字和算法以 RFC 原文和各家官方说明为准。实战里的做法：能合并的合并，没用的 include 删掉，实在太多就拆到子域名上去，别硬堆在一条记录里。

改完为什么半天不生效

TTL 缓存拦在中间。你自己电脑上查是新值，收件方那边可能还抱着几小时前的旧记录，于是你这边显示对，对方那边还是错。查的时候别只查本机：dig TXT example.com +short，再换个递归服务器查一遍 dig @8.8.8.8 TXT example.com +short，两边一致了才算真生效。有条件再让外地的朋友帮你查一次，不同线路的缓存节奏不一样。

SPF算法只管信封，不管正文

它校验的是发信域名和发信 IP 的对应关系，邮件正文有没有被改、是不是伪造的，它一概不管，那是 DKIM 签名的活。DMARC 站在上面把两者串起来，还告诉你失败了之后该怎么办。这里有个挺反直觉的点：正经的转发，比如邮件列表、自动转发到另一个邮箱，经常会让 SPF 过不了，因为信是从中间那台机器发出去的，IP 换了。所以碰到退信，先问一句“这封信是不是被转过手”，比闷头改记录管用。

几个容易漏的细节

一个域名只能有一条以 v=spf1 开头的 TXT 记录，出现两条就是 permerror。有些服务验证域名所有权时会让你加一条 TXT，后来配 SPF 又加一条，正好撞上。记录太长要拆，超过单段字符串上限就写成 “v=spf1 …”“…继续” 这种相邻字符串，DNS 里是分段，拼起来仍然是同一条，那不是两条记录，别自己吓自己。走 IPv6 发信要补 ip6:，很多人只写了 ip4，换了链路就翻车。子域名默认不带 SPF，要不要单独配，看业务和发信服务商的说明。

出问题的时候，我会按这个顺序看

第一步先看退信原文，里面那串关键词区别很大：none 是没找到记录，softfail 是软失败，permerror 是记录本身有语法问题或者查询超限，temperror 往往是 DNS 那头一时抽风，处理方向完全不同。第二步 dig 查当前生效的值。第三步看有没有两条 v=spf1 并存。第四步数 include 的层数和查询次数。第五步回想最近有没有换服务器、换发信平台、加过转发。第六步才去怀疑 IP 信誉——顺序反了容易白折腾半天。

这条记录属于“配一次、忘一年”的类型，平时不出声，出事就是一片退信。真正要记住的只有一句：只要换过发信 IP、换过发信平台、动过 DNS，回头把这条 TXT 翻出来看一眼。花几分钟的事，比事后一封封给人解释强得多。