SPF 记录检测
验证 SPF 记录，防止邮件伪造
本页提供关于 SPF 记录验证的原创、经人工审校的内容，涵盖 include 链、10 次 DNS 查询限制、ip4/ip6 机制，以及为什么仅有 SPF 而不配 DKIM 与 DMARC 并不足够。
SPF（发件人策略框架）是一种邮件认证方式，允许域名所有者指定哪些邮件服务器有权代表其域名发送邮件，从而帮助防止邮件伪造。
SPF 的工作原理：
- 您在域名的 DNS 中发布一条 TXT 形式的 SPF 记录
- 当有人收到声称来自您域名的邮件时，其邮件服务器会检查您的 SPF 记录
- 收件服务器将发件服务器的 IP 与您的授权列表进行比对
- 根据比对结果，邮件被接受、拒绝或标记为可疑
SPF 记录组成：
- 版本：始终以 v=spf1 开头
- 机制：定义哪些来源被授权（ip4、ip6、include、a、mx 等）
- 限定符：指定采取的动作（+通过、-失败、~软失败、?中立）
- all 机制：定义未列出来源的默认策略
SPF 的好处：
- 减少邮件伪造与钓鱼攻击
- 提升邮件投递率与发件人信誉
- 防止您的域名被用于垃圾邮件活动
- 实施 DMARC 的必要前提
最佳实践：
- 通过合并 include 保持 SPF 记录在 10 次查询限制以内。
- 以 -all 结尾实施严格策略（或先用 ~all 过渡）。
- 更换邮件服务商时及时检查并更新 SPF 记录。
基本 SPF 记录结构：
常见 SPF 示例：
基本 SPF（自有邮件服务器）
仅 MX 记录中列出的服务器可以发送邮件
Google Workspace
包含 Google 的 SPF 记录以用于 Gmail/Workspace
Microsoft 365
包含 Microsoft 的 SPF 记录以用于 Office 365
多个服务
组合多个邮件服务与特定 IP 地址
DNS 查询次数过多
需要超过 10 次 DNS 查询的 SPF 记录将无法通过验证。
解决方案：减少 include，尽可能使用 IP 地址代替主机名。
存在多条 SPF 记录
DNS 中存在多条 SPF 记录会导致 SPF 验证失败。
解决方案：将所有 SPF 机制合并到一条 TXT 记录中。
缺少 all 机制
没有 all 机制的 SPF 记录可能无法按预期工作。
解决方案：根据您的策略，始终以 ~all、-all 或 ?all 结尾。
语法错误
SPF 记录中的无效语法可能导致认证失败。
解决方案：部署前验证 SPF 语法并充分测试。
SPF 限定符说明：
明确允许该来源
拒绝该邮件
标记为可疑但仍接受
未指定策略
~all 和 -all 有什么区别？
~all（软失败）将未授权邮件标记为可疑但仍投递，而 -all（硬失败）指示收件服务器完全拒绝未授权邮件。大多数域名推荐使用 ~all。
可以有多个 SPF 记录吗？
不能，每个域名只能有一条 SPF 记录。多条 SPF 记录会导致认证失败。请将所有邮件来源合并到一条 SPF 记录中。
SPF 传播需要多久？
SPF 记录与其他 DNS 变更一样传播，全球通常需要 24-48 小时。不过许多服务器会在几分钟到几小时内看到变更。
超过 10 次 DNS 查询会怎样？
如果记录需要超过 10 次 DNS 查询（包括 include 引入的查询），SPF 认证将失败。请监控查询次数并适时优化。
应该使用 ip4 还是 include 机制？
对于您控制的静态 IP 使用 ip4/ip6，对于 Google Workspace、Mailgun 等第三方服务使用 include。include 更灵活，但会计入 10 次查询限制。
子域会继承 SPF 记录吗？
不会。子域不会继承父域的 SPF 记录。每个发送邮件的子域都需要自己的 SPF 记录，或使用通配符 SPF 记录。
SPF 代表什么？
发件人策略框架（Sender Policy Framework），通过声明哪些服务器可以代发域名邮件来防止伪造。
只配置 SPF 就足够保护我的域名吗？
不够。SPF 需要与 DKIM、DMARC 配合使用才能完成完整认证，DMARC 规定检查失败时的处理策略。
如何检查我的 SPF 记录？
在本工具中输入域名即可自动查询并验证 SPF 记录。