SPF 记录（Sender Policy Framework）

SPF 记录（Sender Policy Framework，发件人策略框架）是一种以 DNS TXT 记录形式发布的电子邮件验证机制，用于声明哪些 IP 地址或服务器被授权以某个域名的名义发送邮件。

概述

电子邮件底层协议 SMTP 在设计之初并不验证发件人身份，任何服务器都可以随意伪造「发件域名」，这也是垃圾邮件和钓鱼邮件泛滥的根源之一。SPF 的思路是：域名所有者在自己域名的 DNS 里发布一条 TXT 记录，列出合法的发信来源；收件方邮件服务器收到邮件后，查询发件域名的 SPF 记录，核对实际发信 IP 是否在授权名单内，从而判断邮件是否可能伪造。该机制由 IETF 标准化，标准文档为 RFC 7208。

一条典型的 SPF 记录形如 v=spf1 include:_spf.example.com ip4:1.2.3.4 -all：以 v=spf1 开头，中间列出授权来源（ip4/ip6 指定 IP 段，include 引入第三方邮件服务的名单，a/mx 引用本域解析记录），结尾用 all 定义默认策略——-all 表示名单之外一律拒绝（硬失败），~all 表示软失败（通常标记为可疑而非直接拒收）。

主要作用

• 防伪造：阻止他人冒用你的域名群发垃圾邮件、实施钓鱼诈骗，保护域名信誉。
• 提升送达率：Gmail、QQ 邮箱等主流收件方会检查 SPF，未配置的域名发信更容易进垃圾箱甚至被拒收。
• 授权第三方发信：使用企业邮箱、邮件营销平台（EDM）或云服务代发邮件时，通过 include 语法把对方服务器纳入授权名单。
• 配合 DKIM 与 DMARC：SPF 验证发信来源，DKIM 用签名验证内容完整性，DMARC 在两者之上定义验证失败后的处置策略，三者共同构成现代邮件认证体系。

配置注意事项

一个域名只应保留一条 SPF 记录，多条会导致验证失败；记录整体的 DNS 查询次数（include、a、mx 等机制的嵌套查询）有上限限制（标准规定为 10 次），引入过多第三方服务时容易超限失效。SPF 只校验信封发件人（Return-Path）对应的域名，并不能防住邮件正文「显示名称」的伪装，因此建议与 DKIM、DMARC 一起部署。修改后可用 dig/nslookup 或在线 SPF 检测工具验证生效情况。

常见问题

问：不发邮件的域名需要配置 SPF 吗？答：建议配置。对完全不发信的域名发布 v=spf1 -all，可以声明该域名从不发邮件，防止被冒用发送垃圾邮件。

问：SPF 记录要单独的记录类型吗？答：不需要。早期曾有专门的 SPF 记录类型，现已废弃，现行标准统一使用 TXT 记录发布，主机记录一般填 @（主域名本身）。

问：配置了 SPF 邮件还是进垃圾箱怎么办？答：SPF 只是基础项之一，还需检查 DKIM 签名、DMARC 策略、发信 IP 信誉、反向解析（rDNS）以及邮件内容质量等因素。