验证您的发件人策略框架记录
DNS 与记录
DNS 查询 查询任意域名的全部 DNS 记录 A 记录查询 域名的 IPv4 地址 AAAA 记录查询 域名的 IPv6 地址 MX 查询 域名的邮件服务器 NS 查询 权威名称服务器 TXT 查询 TXT 记录、SPF、验证 CNAME 查询 规范名称（别名）记录 SOA 查询 起始授权机构记录 SRV 查询 服务位置记录 CAA 查询 哪些 CA 可以签发证书 反向 DNS（PTR） IP 地址到主机名 DNSSEC 检测 该域名是否已签名并通过验证？ DNS 健康检测 完整的委派与 DNS 诊断报告电子邮件送达率
SPF 检测 验证您的发件人策略框架记录 DMARC 检测 检查并评估您的 DMARC 策略 DKIM 检测 查找并验证您的 DKIM 公钥 黑名单检测 对照电子邮件黑名单（DNSBL）检测 IP SMTP 测试 连接邮件服务器并检测 STARTTLS MTA-STS 检测 入站邮件的强制 TLS 策略 BIMI 检测 电子邮件的品牌徽标记录 TLS-RPT 检测 SMTP TLS 报告策略网络与网站
SSL 证书检测 检查网站的 TLS 证书和到期情况 HTTP 标头检测 检查响应标头、重定向和安全性 Ping（TCP） 通过 TCP 检测可达性和延迟 端口检测 哪些常用端口处于开放状态域名
WHOIS 查询 域名、IP 和 ASN 的注册数据SPF（发件人策略框架，Sender Policy Framework）告诉接收方邮件服务器哪些主机可以代表你的域名发送邮件。SPF 记录一旦出错——重复、DNS 查询次数过多，或缺少 all 机制——就会导致正常邮件被投进垃圾箱。IPeek 会查找你的 SPF 记录，逐项解析每个机制，并标记出那些损害送达率的问题。
SPF 以 TXT 记录的形式存放在你的根域名上，以 v=spf1 开头。当某台服务器收到声称来自你的邮件时，它会查询这条记录，检查发送方 IP 是否被授权。像 v=spf1 include:_spf.google.com ip4:198.51.100.10 -all 这样的记录表示"允许 Google 的主机和这个 IP，拒绝其他一切"。各机制从左到右依次求值，第一个匹配的生效。末尾的 all 机制是兜底项，决定了所有未明确列出的主机的默认处理结果。
all 机制设定你的策略：-all 是硬失败（拒绝未列出的发件人），~all 是软失败（接收但标记为可疑），而 +all 允许任何人——绝不要使用它。SPF 还把发起 DNS 查询的机制（include、a、mx、ptr、exists、redirect）总数限制在 10 次以内；超出后结果为 permerror，会被视为失败。嵌套的 include 也会计入，因此添加多个供应商会悄悄耗尽配额。IPeek 会统计每一次查询，并在你接近上限前发出警告。
仅靠 SPF 是不够的。它验证的是信封发件人（return-path），而不是用户看到的可见 From 地址，因此伪造者可以在通过 SPF 的同时冒用你的品牌。DMARC 弥补了这一缺口：它要求 SPF 域名与 From 域名保持对齐（alignment），并将 SPF 与 DKIM 配对，使两者任一都能完成验证。把 SPF 看作三层防护之一：SPF 授权主机，DKIM 签名内容，DMARC 将它们与你的 From 域名绑定并强制执行策略。
SPF 每次求值最多允许 10 个发起 DNS 查询的机制。include、a、mx、ptr、exists 和 redirect 机制都会消耗查询次数，嵌套的 include 也计入同一上限。超过 10 次会产生 permerror，接收方会将其视为验证失败。请扁平化或合并 include，以保持在上限之内。
区别在于强制力度。-all 是硬失败，告诉接收方拒绝任何未在记录中列出的主机发来的邮件；~all 是软失败，告诉接收方接收但视为可疑。测试期间使用 ~all，确认所有合法发件人都已授权后再切换到 -all。避免使用 +all，它会授权任何人。
仅有 SPF 记录并不能保证进入收件箱。常见原因包括超出 10 次查询上限（permerror）、缺少或过于宽松的 all 机制、实际未被授权的发送主机，或同一域名上存在重复的 SPF 记录。SPF 也不保护你的可见 From 地址——要获得强送达率，还需要配合 DKIM 和 DMARC。
不可以。一个域名必须且只能发布一条 SPF（v=spf1）TXT 记录。两条或更多 SPF 记录会导致 permerror，接收方可能拒收或判定验证失败。如果需要授权多个发件方，请用额外的 include 或 ip4/ip6 机制把它们合并进一条记录，而不要再加一条记录。
不会。SPF 验证的是信封发件人（return-path 或 MAIL FROM），而不是收件人实际看到的 From 头。这正是仅靠 SPF 无法阻止品牌被冒用的原因。DMARC 增加了 SPF 对齐，要求 SPF 域名与可见的 From 域名匹配，从而弥合协议层检查与用户所见之间的缺口。