SPF — 发件人政策框架

Internet Standard Email Authentication Obsoletes RFC 4408 Published March 2026

ELI5: 想象你的公司有官方信笺。SPF就像发布一份获准在你信笺上打印的打印机清单。当有人收到一封声称来自你的信件时，他们可以检查它是否来自你批准的打印机之一。如果没有，他们就知道这可能是伪造的。

为什么存在这个RFC

SMTP在20世纪80年代初设计时没有内置发件人验证。任何服务器都可以声称从任何域发送邮件——基础协议中没有任何东西可以阻止这一点。这使电子邮件欺骗变得微不足道：垃圾邮件发送者和网络钓鱼者可以伪造信封发件人地址来冒充银行、同事或任何受信任的品牌。

SPF（发件人策略框架），在RFC 7208中标准化，通过让域所有者发布DNS TXT记录来解决这个问题，该记录明确列出哪些IP地址和服务器被授权为其域发送电子邮件。接收邮件服务器在SMTP事务期间查询该记录，可以拒绝或标记来自未授权源的邮件。

RFC 7208废止了早期的实验性RFC 4408，将SPF提升为完整的互联网标准，具有澄清的处理规则和更严格的DNS查询限制要求。

工作原理

SPF在信封级别运作，而非消息头级别。检查的域是MAIL FROM命令中的域（也称为Return-Path或信封发件人），而不是用户看到的From:头。

SPF检查流程

发送服务器连接到接收方并发出MAIL FROM:<user@example.com>。
接收方从信封发件人中提取域example.com。
接收方在example.com处查询DNS以获取以v=spf1开头的TXT记录。
接收方根据连接的IP地址评估SPF记录的机制。
结果是以下之一：pass、fail、softfail、neutral、none、temperror或permerror。

SMTP事务示例

# 发送服务器198.51.100.25连接
S: 220 mx.receiver.com ESMTP ready
C: EHLO mail.example.com
S: 250-mx.receiver.com Hello
S: 250 OK
C: MAIL FROM:<alice@example.com>
# 接收方现在检查：example.com的SPF记录是否授权198.51.100.25？
# DNS查询：example.com TXT "v=spf1 ip4:198.51.100.0/24 -all"
# 198.51.100.25与ip4:198.51.100.0/24匹配 => 结果：pass
S: 250 OK
C: RCPT TO:<bob@receiver.com>
S: 250 OK

关键技术细节

SPF记录语法

SPF记录是一个DNS TXT记录，以版本标签v=spf1开头，后跟一系列机制和每个机制的可选限定符。记录从左到右进行评估；首个匹配的机制决定结果。

example.com. IN TXT "v=spf1 ip4:198.51.100.0/24 ip6:2001:db8::/32 include:_spf.mailertogo.com include:_spf.google.com -all"

机制

机制	描述
`ip4:<range>`	如果发件人的IP在给定的IPv4 CIDR范围内则匹配。
`ip6:<range>`	如果发件人的IP在给定的IPv6 CIDR范围内则匹配。
`a`	如果发件人的IP等于该域的A/AAAA记录则匹配。
`mx`	如果发件人的IP等于该域的某个MX主机的A/AAAA记录则匹配。
`include:<domain>`	递归评估另一个域的SPF记录。来自包含域的`pass`计为匹配。
`exists:<domain>`	如果给定域的DNS A记录存在则匹配（用于高级宏）。
`redirect=<domain>`	修饰符：将当前SPF检查完全替换为另一个域的记录。
`all`	匹配所有内容。通常在记录末尾用`-all`或`~all`。

限定符

限定符	结果	含义
`+`（默认）	pass	授权发件人
`-`	fail	未授权——拒绝邮件
`~`	softfail	可能未授权——接受但标记
`?`	neutral	没有做出断言

10次查询限制

为了防止DNS滥用，RFC 7208要求SPF评估不能需要超过10次DNS查询来进行机制解析。触发查询的机制有：include、a、mx、exists、redirect和ptr（已弃用）。原始ip4和ip6机制不计在内。超过10次查询会产生permerror结果，这通常意味着根本没有SPF保护。

MX查询限制

此外，mx机制不能导致超过10个MX名称需要查询，每个名称不能解析为超过10个A/AAAA地址。明确不鼓励使用ptr机制。

宏扩展

SPF支持在评估期间扩展为上下文特定值的宏。常见宏包括%{s}（发件人）、%{l}（本地部分）、%{d}（域）和%{i}（IP地址）。这些主要用于exists:机制中的复杂的按用户或按IP策略。

DNS记录示例

基础：单个IP范围

example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 -all"

典型：第三方ESP + Google Workspace

example.com. IN TXT "v=spf1 include:_spf.mailertogo.com include:_spf.google.com -all"

不发送电子邮件的域

parked-domain.com. IN TXT "v=spf1 -all"

使用redirect

subdomain.example.com. IN TXT "v=spf1 redirect=example.com"

常见错误

多个SPF记录：一个域必须恰好有一个SPF TXT记录。发布两个会导致permerror。如果需要合并源，请将它们合并到一个记录中。
超过10次查询限制：每个include:计为一次查询，包含记录自己的机制计入总数。多个ESP的包含链很快会耗尽限制。展平您的记录或使用子域。
使用~all而不是-all：Softfail（~all）告诉接收方邮件是可疑的但不拒绝它。为了获得强大的保护（并启用DMARC执行），请使用-all。
忘记Return-Path域：SPF检查信封发件人，而非From:头。如果您的ESP使用自己的Return-Path域，您的域的SPF记录与SPF检查无关。您需要自定义Return-Path对齐或DKIM + DMARC。
使用已弃用的ptr机制：RFC 7208明确不鼓励ptr，因为它速度慢、不可靠，并对反向DNS基础设施造成负载。
使用SPF（99）类型记录：专用SPF DNS记录类型在RFC 4408中定义但在RFC 7208中弃用。始终使用TXT记录。

投递能力影响

SPF是电子邮件认证的三个支柱之一（与DKIM和DMARC并列）。其对投递能力的影响是显著的：

主要提供商要求：Gmail、Yahoo、Microsoft和Apple都评估SPF。自2024年2月起，Gmail和Yahoo要求所有发件人都通过SPF或DKIM，批量发件人的两者都需通过。
DMARC对齐：当与检查SPF认证的域是否与From:头域对齐的DMARC结合使用时，SPF变得更加强大。没有DMARC，SPF单独不能防止头部欺骗。
转发打破SPF：当邮件通过邮件列表或.forward规则转发时，发送IP会改变但信封发件人通常保持不变。这会导致合法邮件的SPF失败。这是DKIM和ARC存在的原因之一。
声誉信号：正确配置的SPF记录（使用-all）向接收方表示您重视电子邮件安全，并使坏人更难滥用您的域。