直接授权服务器
ip4: 和 ip6: 列出地址或网段(如 ip4:203.0.113.0/24),不消耗 DNS 查询。a 授权域名 A/AAAA 记录的 IP,mx 授权其 MX 记录中的服务器——各消耗一次查询。
勾选以您的域名发信的服务,加入您自己的服务器,即可得到一条有效的 SPF 记录,直接粘贴到 DNS。生成器会实时统计 DNS 查询次数,避免超过会让 SPF 悄然失效的 10 次上限。
100% 在您的浏览器中运行——不上传任何内容
0 本记录中 · ≈0 含嵌套 include 的预计总数
每个 include、a、mx、exists 和 redirect 消耗一次查询,嵌套在服务商记录中的每个 include 也一样。检测工具会测量真实总数。
TXT@@ 表示域名根。请编辑现有的 SPF 记录,而不是再添加一条。
v=spf1 ~all即使 SPF、DKIM 和 DMARC 完美无缺,也无法阻止退信。向无效、一次性或废弃的地址发信,对发件人信誉的伤害丝毫不小。请在下一次营销活动前验证您的名单。
邮箱服务商、邮件营销工具、事务邮件服务、CRM、客服系统、网站和账单系统——凡是在 From 或 return-path 中使用您域名发信的都算。
勾选预设服务,并添加您自己的 IP 或 include。记录和查询次数会实时更新。
在 DNS 服务商处编辑现有的 SPF 记录,或在域名根(主机 @)创建 TXT 记录。切勿发布第二条 SPF 记录——请合并为一条。
使用我们的免费 SPF、DKIM 与 DMARC 检测工具:它会跟踪每一层嵌套 include,给出真实的查询总数。
SPF 记录以 v=spf1 开头,列出允许代表该域名发信的来源,并以针对其他所有来源的 “all” 规则结尾。
ip4: 和 ip6: 列出地址或网段(如 ip4:203.0.113.0/24),不消耗 DNS 查询。a 授权域名 A/AAAA 记录的 IP,mx 授权其 MX 记录中的服务器——各消耗一次查询。
include:_spf.google.com 会引入服务商自己的 SPF 记录,您无需追踪对方的 IP 段。每个 include 消耗一次查询,其内部的每个 include、a、mx 或 exists 也都要计数。
~all(软失败)把其他来源标记为可疑,交由 DMARC 决定——这是最常见的选择。-all(硬失败)要求收件方直接拒收。切勿使用 +all(任何人都能冒充您发信)或 ?all(中立,毫无保护)。
评估 SPF 最多只能进行 10 次 DNS 查询(RFC 7208),多一次收件方就会返回 “permerror”,视为 SPF 失败。而且一个域名只能有一条 v=spf1 记录——两条记录同样是永久错误。
发布在您域名上的一条 TXT 记录,列出允许代表该域名发信的服务器。收件方会把发信 IP 与列表比对;与 DKIM 和 DMARC 配合,可防止他人冒用您的域名发信。
不可以。一个域名必须且只能有一条以 v=spf1 开头的 TXT 记录。如果有两条,收件方会返回永久错误,所有邮件的 SPF 都会失败。请把所有机制合并到一条记录中——这正是本生成器所做的。
配置好 DMARC 后两者都可以。~all(软失败)是最常见的建议,因为最终由 DMARC 决定,转发邮件也更不容易丢失;-all(硬失败)更严格,部分服务商更推荐。切勿使用 +all 或 ?all。
RFC 7208 规定,评估一条 SPF 记录所需的 DNS 查询不得超过 10 次。每个 include、a、mx、exists 和 redirect 都计数——包括嵌套在服务商记录中的那些。超过 10 次,SPF 返回 permerror 并判定失败。
删除不再使用的服务;IP 稳定时用 ip4/ip6 替换 a 和 mx;把营销工具迁到拥有独立 SPF 的子域;或对使用您域名签名的服务商依赖 DKIM。避免手动“展平”服务商的 IP 段——它们可能随时变更。
Gmail 和 Yahoo(自 2024 年 2 月起)以及 Outlook.com(自 2025 年 5 月起)要求批量发件人同时配置 SPF 和 DKIM,而只要其中之一对齐,DMARC 即可通过。两者都配置最稳妥。
放在 return-path(信封发件人)所用的域名上——通常是域名根(主机 @)。部分服务(如使用自定义 MAIL FROM 域的 Amazon SES)使用子域,此时 SPF 记录应放在该子域上。
不会。记录完全在您的浏览器中生成,您输入的任何内容都不会发送到我们的服务器。