当我们谈到“电子邮件认证”时，我们指的是一种技术，旨在向消息的接收者提供某种程度的确定性，即消息确实来自所声明的消息来源。其目的是为了对抗欺诈性电子邮件，例如钓鱼邮件和伪造邮件，这些都可能削弱接收者对接收电子邮件的信任。也就是说，发送经过认证的电子邮件本身并不意味着该电子邮件是良好的或所希望的电子邮件；它只是意味着可以可靠地建立认证方的声誉，并在电子邮件接收和投递决策中使用。
目前主要有两种电子邮件认证形式——发送方策略框架 (SPF) 和 域名密钥识别邮件 (DKIM)。在这篇博客文章中，我将解释什么是 SPF，以及它是如何工作的。
SPF 概述
发送方政策框架（SPF），用RFC 7208的说法，就是一个协议，不仅允许组织授权主机和网络在发送电子邮件时使用其域名，还提供了一种接收主机检查该授权的方法。
当您读完这篇文章时，我希望您能了解到以下内容：
SPF 是一种“基于路径”的认证系统。
SPF 策略在 DNS TXT 记录中声明。
验证与返回路径域（我们在 SparkPost 稱其為“反弹域”）或 HELO 域相关联。
验证可以在 SMTP 交易的早期进行，因此这是一个良好的检查，以快速拒绝未经认证的邮件。
它可能会有相对较高的假阴性比例。
“基于路径”的认证
SPF 被视为一种基于路径的认证系统，因为它仅与消息从其源头到目的地的路径有关。当发送服务器与接收服务器启动SMTP交易时，接收服务器将根据域的SPF策略决定发送服务器是否被授权发送该消息。这完全是基于消息来源的决定，与消息的内容没有任何关系。
声明 SPF 策略
域的 SPF 策略记录只是一个特别格式化的 DNS TXT 记录，通常包含一个或多个以下“机制”：
v=spf1 – 指出该 TXT 记录是 SPF 记录的必需第一个令牌（一个域可以有多个 TXT 记录）
ipv4, ipv6 – 用于指定被允许发送邮件的域的 IP 地址和网络
a – 如果发送域有 DNS “A” 记录解析到发送 IP，则该 IP 被允许
mx – 如果发送 IP 也是发送域的 MX 记录之一，则该 IP 被允许
all – 必需的最后一个令牌，始终修改：
-all – 只有这里列出的可以通过；拒绝失败。
~all – 这里不包含的应该软失败；接受它但记录下来。
?all – 不确定这里没有的东西是否应该通过。
+all – 我们认为 SPF 是无用的；通过所有内容。
其他仍在广泛使用的较少见机制有：
include – 当一个域不仅有自己的服务器，还使用其他人的服务器时使用。必须谨慎使用。每个 include 是另一个 DNS 查询，SPF 记录不能要求超过十个 DNS 查询来解析。
redirect – 当域 A 和域 B 由同一实体拥有并使用相同的基础设施时。所有者通常希望为两者维护只有一个 SPF 记录的副本，并将 B 配置为将查询重定向到 A。
exists – 如果一个域有很多小的、不连续的网络块，它可以使用这种机制来指定其 SPF 记录，而不是列出所有的。仅在 DNS 响应的大小限制（512 字节）内保留有用。
关于“ptr”机制的说明
最后一个机制“ptr”在 SPF 的原始规范中存在，但在当前规范中已被声明为“请勿使用”。ptr 机制用于声明如果发送的 IP 地址有可解析到相关域名的 DNS PTR 记录，则该 IP 地址被授权为该域发送邮件。
该机制目前的状态是不应使用。然而，进行 SPF 验证的网站必须接受它为有效。
一些示例 SPF 记录
以下是一些示例记录及其含义。此示例显示了 RFC 1918 地址，但我知道这些地址在真实的 SPF 记录中永远不会出现。
MX 记录，一个 IP 地址，一个 IP 网络，软失败其他所有：
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
A 记录，两个 IP 网络，拒绝其他一切：
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
我们不发送邮件：
“v=spf1 -all”
我们认为 SPF 是愚蠢的：
“v=spf1 +all”
域 sparkpostmail.com 的 SPF 记录（使用重定向机制）
“v=spf1 redirect=_spf.sparkpostmail.com”
spf.sparkpostmail.com 的 SPF 记录（使用 exists 和 ptr 机制）：
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
在 SparkPost，我们在 SPF 记录中目前使用 ptr 机制。由于缺乏对 exists 机制的普遍支持，我们发现它是必要的。到目前为止，我们没有发现由于使用 ptr 机制而导致的 SPF 失败。
SPF 认证是如何工作的？
以下是当 SPF 被涉及时典型的 SMTP 交易情况：
发送服务器（客户端）连接到接收服务器
接收服务器注意到客户端的连接 IP 地址
他们交换问候，包括客户端的 HELO 主机名
客户端发出 SMTP MAIL FROM 命令
接收服务器现在可以查找 MAIL FROM 域或 HELO 主机名的 SPF 记录，以确定连接 IP 是否被授权为该域发送邮件，并决定是否接受该消息。
MAIL FROM 或 HELO – 检查哪个？
SPF 规范规定，接收站点必须检查 MAIL FROM 域的 SPF，并建议检查 HELO 主机名。在实践中，仅在 MAIL FROM 域上进行检查，除非在 MAIL FROM 地址为 NULL 发送者（即“<>”）的情况下，此时 HELO 主机名是唯一可用的身份。
SPF 不是万无一失的
虽然它似乎是一种相对简单的电子邮件认证方法，但 SPF 易受到假阴性形式的失败。这些失败可能比许多人所能接受的更频繁地发生。
以下是两个常见场景，其中完全合法的邮件可能会失败 SPF 验证，似乎是欺诈性的：
自动转发，邮件发送到 jsmith@alumni.university.edu 的情况下，一个邮箱被设置为自动将所有邮件转发到 jsmith@isp.com
邮件列表，发送到 talk-about-stuff@listserv.foo.com 的邮件被“爆炸”并发送给每个订阅者
在这两种情况下，如果返回路径与原始路径未更改，则邮件可能会失败 SPF 检查（具体取决于与“all”机制一起使用的修饰符）。这是因为它是从中间服务器到达其最终目的地，而不是原始服务器，并且该中间服务器不太可能在该域的 SPF 记录中。名为“发件人重写方案”或“SRS”的技术可以降低这种风险，某些大型网站已采用，但这并不普遍。
总结
所以这就是 SPF 认证、它是如何工作的、如何声明 SPF 策略以及使用 SPF 时的陷阱。SPF 是第一个实现广泛采用的电子邮件认证方案，但它并不是唯一的。SPF 认证在结合其他反欺诈技术部署时效果最佳。