当我们谈论“电子邮件认证”时，我们指的是一种技术，旨在为消息的接收者提供一定程度的确定性，确保该消息确实来源于所声明的消息来源。
Business in a box.
探索我们的解决方案。
与我们的销售团队交谈
当我们谈论“Email Authentication”时，我们指的是一种技术，该技术旨在为消息的接收者提供某种程度的确定性，即消息确实来自于声称来源的来源。这个概念是为了在某种程度上防御例如钓鱼和欺骗等欺诈性邮件，这些邮件可能会侵蚀接收者对接收邮件的信任。话虽如此，发送经过认证的电子邮件的行为本身并不声称电子邮件是好的或想要的邮件；这仅意味着邮件是这样的，可以可靠地为认证方建立声誉，并用于电子邮件接受和放置决策。
今天使用的两种主要电子邮件身份验证形式是Sender Policy Framework (SPF)和DomainKeys Identified Mail (DKIM)。在这篇博客文章中，我将解释SPF是什么以及它如何运作。
SPF 概览
发送方策略框架 (SPF)，引用RFC 7208，是一种协议，不仅允许组织授权主机和网络在发送电子邮件时使用其域名，还提供了一种接收主机可以检查该授权的方法。
当你读完这篇文章后，希望你能了解到以下内容：
SPF是一个“路径式”认证系统。
SPF策略在DNS TXT记录中声明。
验证与Return-Path域（我们在SparkPost称之为“退回域”）或HELO域相关。
验证可以在SMTP事务早期进行，因此是快速拒绝未经认证邮件的良好检查。
它容易出现相对高比例的误判。
“Path-Based” Authentication
声明一个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 Authentication 如何运作？
以下是涉及 SPF 时典型的 SMTP 事务的样子：
发送服务器（客户端）连接到接收服务器
接收服务器记录客户端的连接 IP 地址
他们交换问候，包括客户端的 HELO 主机名
客户端发出 SMTP MAIL FROM 命令
接收服务器现在可以查找 MAIL FROM 域或 HELO 主机名的 SPF 记录，以确定连接 IP 是否被授权为该域发送邮件，并决定是否接受该消息。
MAIL FROM 或 HELO – 哪一个需要检查？
SPF规范规定接收站点必须检查MAIL FROM域，并建议检查HELO主机名。在实践中，只对MAIL FROM域进行检查，除了在MAIL FROM地址是空发送者（即“<>”）的时候，此时HELO主机名是唯一可用的身份。
SPF 并非万无一失
虽然这看起来是一种相对简单的电子邮件认证方式，但SPF容易出现形式为假阴性的失败。这些失败发生的频率可能比许多人能接受的要高。
以下是两个常见场景，其中完全合法的邮件可能无法通过SPF验证，因此看起来是欺诈的：
自动转发，例如发送到jsmith@alumni.university.edu的邮件，自动转发所有邮件到jsmith@isp.com的邮箱
邮件列表，例如发送到talk-about-stuff@listserv.foo.com的邮件被“扩展”并发送到每个订阅者
在这两种情况下，如果退回路径与原始邮件保持不变，邮件可能无法通过SPF检查（取决于使用的'all'机制的修饰符）。这是因为邮件从中间服务器而不是原始服务器到达最终目的地，而那个中间服务器不太可能在域的SPF记录中。一种称为“Sender Rewriting Scheme”或“SRS”的技术可以降低这种风险，一些大型网站采用了这种技术，但它并不普遍。
Wrap Up
这就是SPF身份验证，如何运作，如何声明SPF政策，以及使用SPF时的陷阱。SPF是首个获得广泛采用的电子邮件身份验证方案，但并不是唯一的。SPF身份验证在与其他反欺诈技术结合使用时最为有效。
