检查一条 SPF 记录，或者生成一条
SPF 出问题时是悄无声息的。它正常用了一年，某人又加了一个服务，记录就超过了十次 DNS 查询的上限，从那一刻起，每个收件方都会把它当成坏掉的记录处理 —— 而且哪里都不会报错。这个工具把这个查询次数显示给你看。
- 在你的浏览器里运行，不在我们的服务器上
- 不用注册
- 没有水印
正在加载工具……
工作原理
- 输入你的域名。如果想知道某台具体的服务器是否被允许发信，再加上它的 IP。
- 看结果、查询次数和发现的问题；展开树状结构，看看每条被包含的记录里到底写了什么。
- 用下面的生成器，根据你实际在用的服务，拼出一条正确的记录。
为什么什么都不用上传
这个页面上的每一步操作，都由运行在你浏览器标签页里的代码完成，用的就是渲染网页的那套引擎。文件从磁盘读进标签页的内存，在那里被处理，再作为下载写回去。它不会被送到任何地方 —— 不会送给我们，也不会送给第三方。
自己动手验证
- 打开浏览器的开发者工具（F12），选择“网络”（Network）面板。
- 载入你的文件，运行这个工具。
- 你能看到的请求只有这些：工具自己的代码 —— 少数几个重型工具还会从公共 CDN 取它们的开源引擎 —— 外加一条发往 loreatec.jp 的小小访问记录（页面地址和标题，仅此而已）。没有一条带着你的文件。
常见问题
“十次查询上限”具体是怎么算的？
每一个 include、a、mx、ptr、exists 和 redirect 都算一次 DNS 查询，你所包含的记录里面再嵌套的那些查询也要算进去。标准（RFC 7208）把总数上限定在十次。收件方一旦达到这个上限就会停止计算并返回一个错误，大多数收件方会把这种情况当成你根本没有 SPF 记录来处理。常见的原因是某个服务商的一条 include 背后，其实藏着三四次额外的查询。解决办法：去掉不再使用的服务，或者把 include 换成直接的 IP 地址 —— 要小心操作，因为这类地址名单会过期。
为什么 +all 这么糟糕？
因为它等于授权互联网上的每一台服务器都能以你的域名发信。这比干脆不发布记录还糟：没有记录时，收件方还会参考其他信号；用了 +all，你就是在明确替垃圾邮件发送者担保。这种情况通常出现在有人照抄示例、却改错了字符的时候。
记录该以 -all 结尾，还是 ~all？
-all 的意思是“其余一律拒绝”，~all 的意思是“其余一律当作可疑处理”。在你还在摸清楚到底哪些渠道在替你发信的阶段，先用 ~all，之后再改成 -all。这个区别只有在配好 DMARC 之后才真正要紧 —— DMARC 是告诉收件方该怎么处理未通过检查邮件的那条规则，一个 reject 的 DMARC 策略配上 ~all 的 SPF，照样会拒绝邮件。不要出于谨慎就一直停留在 ~all：它是个中转站，不是终点。
能同时有两条 SPF 记录吗？
不能。同一个名字下有两条 v=spf1 记录，是永久性的错误，收件方会直接停止评估。这种情况常常发生在某个服务要求你“添加这条记录”，而你添加了第二条 TXT 记录，却没有把它的内容合并进已有的那一条里。
这会把什么发给谁？
需要查询的域名，会从你的浏览器发给你选定的公共 DNS 服务。这个网站自己的服务器不参与其中，也不会留下任何记录。