当我们谈论“电子邮件认证”时，我们指的是一种技术，旨在为消息的接收者提供一定程度的确定性，确保该消息确实来源于所声明的消息来源。
Business in a box.
探索我们的解决方案。
与我们的销售团队交谈
当我们谈到“Email Authentication”时，我们指的是一种技术，旨在为消息的接收者提供某种程度的确定性，确认消息确实来自声称的消息来源。这个理念是为了实现对欺诈性电子邮件（如网络钓鱼和欺骗）的某种程度的防御，这些可能会削弱接收者对接收电子邮件的信任。话虽如此，发送经过身份验证的电子邮件的行为本身并不表明电子邮件是好的或受欢迎的；这仅仅意味着可以可靠地建立认证方的信誉，并用于电子邮件的接受和放置决策中。
目前使用的两种主要电子邮件认证形式是—Sender Policy Framework (SPF)和DomainKeys Identified Mail (DKIM)。在这篇博客文章中，我将解释SPF是什么，以及它是如何工作的。
SPF 概览
Sender Policy Framework (SPF)，用RFC 7208的话来说，是一种协议，不仅允许组织授权主机和网络在发送电子邮件时使用其域名，还提供了一种接收主机可以检查授权的方法。
当您读完这篇文章后，我希望您能学到以下几点：
SPF 是一种“基于路径”的身份验证系统。
SPF 策略在 DNS TXT 记录中声明。
验证基于 Return-Path 域（我们在 SparkPost 称为“bounce domain”）或 HELO 域。
验证可以在 SMTP 事务的早期完成，因此使用它来快速拒绝未经身份验证的邮件是一个很好的检查。
它容易出现相对较高的误报率。
“Path-Based” Authentication
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 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身份验证在与其他反欺诈技术结合使用时最为有效。
