什么是SPF记录，我的域名为什么需要它？

这是一条DNS TXT记录，列出了可以代表你的域名发送邮件的服务器。接收方会用它核对连接过来的服务器；没有SPF，任何人都可以随意伪造你的地址。

记录末尾应该用~all还是-all？

先从~all开始：失败会被标记但仍会送达，这样一个被遗漏的发件方不会丢失邮件。等报告显示所有合法来源都通过后，再切换到-all。

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

RFC 7208规定每次评估中需要DNS查询的机制——include、a、mx、ptr、exists、redirect——最多10次，嵌套的include也会递归计入。超出后返回permerror，很多接收方会把它当作失败处理。每个服务商的include通常占用1到3次。

光靠SPF能阻止邮件伪造吗？

不能。SPF检查的是信封发件人，而不是用户看到的From标头，而且在纯转发场景下会失效。请配合DKIM签名和DMARC策略一起使用——三者结合才是真正的身份验证。

SPF记录生成器

生成授权你的发件服务器的SPF TXT记录，或粘贴现有记录来验证语法并对照10次的DNS查询上限进行核对。

SPF记录生成器完全在你的浏览器中运行。记录在你的设备上生成和验证——不会发起任何DNS查询，也不会上传任何内容。

打开DMARC记录生成器

关于 SPF记录生成器

SPF记录生成器会构建那唯一一条TXT记录，告诉接收方邮件服务器谁可以代表你的域名发送邮件。勾选你所使用的发件服务商——Google Workspace、Microsoft 365、SendGrid——它们会被转换成各自有文档记录的include机制；再按IP添加你自己的服务器，并为其余所有情况选择策略：在你还在梳理发件方时用~all软失败，名单确定后用-all拒绝。检查功能会像接收方一样解析任何现有记录：验证v=spf1前缀，标记出已弃用的ptr和灾难性的+all，警告all之后被忽略的多余项，并统计需要DNS查询的机制数量，对照那个悄悄破坏无数记录的10次硬性上限。

功能特性

一键添加主流邮件服务商的include
ip4和ip6机制，支持地址和CIDR校验
面向使用自有主机发件的域名提供a和mx开关
如实解释全部四种all策略
对照RFC 7208规定的10次上限统计DNS查询数
全部在浏览器中验证——不发起任何远程查询

如何使用 SPF记录生成器

勾选为你的域名发送邮件的服务商
如有自有服务器IP请添加，并设置all策略
将记录复制到根域名的TXT记录中
或切换到检查模式，粘贴现有记录

示例

输入

Google Workspace + SendGrid · ~all

输出

v=spf1 include:_spf.google.com include:sendgrid.net ~all

10次允许的DNS查询里只用了2次——余量充足。

常见错误与故障排除

记录看起来没问题，邮件却在SPF校验上失败。 — 数一数查询次数：include、a、mx、ptr、exists和redirect各占一次，嵌套的include也算在内。超过10次，接收方会返回permerror。把不常用的include展开成ip4机制。
域名上有两条SPF记录。 — 这会自动导致永久性错误。请把所有机制合并到一条v=spf1字符串里：每个域名只能有一条SPF记录。
所有邮件都通过了——包括伪造的邮件。 — 检查是否有+all，它会授权整个互联网，比根本没有记录还糟糕。请使用-all，或在推行阶段使用~all，并配合DMARC使用。

常见问题

什么是SPF记录，我的域名为什么需要它？: 这是一条DNS TXT记录，列出了可以代表你的域名发送邮件的服务器。接收方会用它核对连接过来的服务器；没有SPF，任何人都可以随意伪造你的地址。
记录末尾应该用~all还是-all？: 先从~all开始：失败会被标记但仍会送达，这样一个被遗漏的发件方不会丢失邮件。等报告显示所有合法来源都通过后，再切换到-all。
什么是SPF的10次DNS查询限制？: RFC 7208规定每次评估中需要DNS查询的机制——include、a、mx、ptr、exists、redirect——最多10次，嵌套的include也会递归计入。超出后返回permerror，很多接收方会把它当作失败处理。每个服务商的include通常占用1到3次。
光靠SPF能阻止邮件伪造吗？: 不能。SPF检查的是信封发件人，而不是用户看到的From标头，而且在纯转发场景下会失效。请配合DKIM签名和DMARC策略一起使用——三者结合才是真正的身份验证。