SPF 认证：概述与最佳实践
鸟
2016年12月19日
电子邮件
1 min read
关键要点
SPF (Sender Policy Framework) 是一种基于路径的电子邮件认证协议，用于验证发送服务器是否被授权为某个域发送邮件。
SPF 策略以DNS TXT 记录形式存在，格式包含定义哪些服务器、IP 或网络被允许代表某个域发送邮件的机制。
SPF 验证与Return-Path 域（退信域）或HELO 主机名相关，而不是可见的发件人地址。
由于 SPF 仅检查发送路径，它可以在SMTP 事务中早期进行验证，从而可用于快速拒绝未授权邮件。
SPF 是有效的，但并不完美——它容易出现误报问题，尤其在邮件转发和邮件列表的情况下。
SPF 记录依赖于类似
mx、a、ipv4、ipv6、include、redirect、exists的机制，并且必须以all修饰符(-all,~all,?all,+all) 结束。DNS 查询限制适用：SPF 评估不能超过 10 个 DNS 查询，因此记录规划很重要。
ptr机制现在被认为是“不可使用”，但验证器仍然必须接受它。由于兼容性问题，一些发送者仍在使用它。仅靠 SPF 不能保证邮件是合法的——它只是保证邮件来自授权的服务器。它在与 DKIM、DMARC 和其他防欺诈技术结合使用时效果最佳。
Q&A 精华
SPF是什么的简单说法？
SPF允许一个域声明哪些服务器被允许以其名义发送电子邮件。接收服务器检查这一点以检测未经授权的发件人。
为什么SPF被称为“路径为基础”？
因为SPF验证了路径（具体来说，是发送服务器的IP），而不是消息内容中的任何内容。
SPF政策存储在哪里？
A: 作为一个DNS TXT 记录，以
v=spf1开始，后跟定义允许发件人的机制。SPF 验证哪个域？
The Return-Path（也称为退回域）。
如果 Return-Path 为空（NULL 发件人），SPF 将检查HELO域。
SMTP 交易中能否提前检查 SPF？
是的。因为它仅依赖于发送服务器的IP和域，SPF可以在接收消息正文之前进行验证——使其在过滤时更有效。
为什么SPF有时即使对于合法邮件也会失败？
常见原因包括：
Email forwarding（转发者未在原始域的SPF记录中）
Mailing lists（邮件由不同的服务器重新发送）
这会导致误报，这是路径认证固有的问题。
机制如include、redirect和exists的作用是什么？
include— 授权另一个域的SPF记录 (例如，您的ESP)redirect— 重用另一个域的SPF策略exists— 基于DNS查找动态授权 (对于复杂的基础设施很有用)
“all” 修饰符如何工作？
-all→ 拒绝未列出的任何内容（严格）~all→ 软失败（接受但标记）?all→ 中立+all→ 通过所有（有效禁用SPF）
为什么不建议使用ptr机制？
它在现代规范中已经缓慢、不可靠并且已被弃用，但SPF验证器仍然必须支持它。
仅靠SPF是否足够进行电子邮件身份验证？
不，SPF验证发送基础设施，但：
它不保护消息完整性
它与可见的发件人域不一致
它在转发时发生故障
当与DKIM和DMARC结合使用时，SPF最强。
在深入了解技术实施之前，值得了解电子邮件验证技术的演变和种类。从简单的语法检查到现代的数据驱动方法，不同的验证方法提供不同程度的准确性和可靠性。
当我们谈论“Email Authentication”时，我们指的是一种技术，旨在使消息接收者对消息确实来源于声明的消息源有一定程度的确定性。其目的是达到一定程度的防御，例如钓鱼和欺骗邮件，这可能会削弱接收者接收电子邮件的信任。对于需要超出身份验证的消息级加密的组织，S/MIME提供了端到端的安全性，自动收件人公钥收集使实现更具可扩展性。尽管如此，发送经过身份验证的邮件这一行为本身并不能断言邮件是好的或被需要的；这仅意味着可以可靠地建立和使用经过身份验证的实体的信誉，以做出电子邮件接收和放置决定。
目前使用的两种主要电子邮件身份验证形式是—Sender Policy Framework (SPF) 和DomainKeys Identifed Mail (DKIM)。 在这篇博客文章中，我将解释什么是SPF及其工作原理。
在深入了解技术实施之前，值得了解电子邮件验证技术的演变和种类。从简单的语法检查到现代的数据驱动方法，不同的验证方法提供不同程度的准确性和可靠性。
当我们谈论“Email Authentication”时，我们指的是一种技术，旨在使消息接收者对消息确实来源于声明的消息源有一定程度的确定性。其目的是达到一定程度的防御，例如钓鱼和欺骗邮件，这可能会削弱接收者接收电子邮件的信任。对于需要超出身份验证的消息级加密的组织，S/MIME提供了端到端的安全性，自动收件人公钥收集使实现更具可扩展性。尽管如此，发送经过身份验证的邮件这一行为本身并不能断言邮件是好的或被需要的；这仅意味着可以可靠地建立和使用经过身份验证的实体的信誉，以做出电子邮件接收和放置决定。
目前使用的两种主要电子邮件身份验证形式是—Sender Policy Framework (SPF) 和DomainKeys Identifed Mail (DKIM)。 在这篇博客文章中，我将解释什么是SPF及其工作原理。
在深入了解技术实施之前，值得了解电子邮件验证技术的演变和种类。从简单的语法检查到现代的数据驱动方法，不同的验证方法提供不同程度的准确性和可靠性。
当我们谈论“Email Authentication”时，我们指的是一种技术，旨在使消息接收者对消息确实来源于声明的消息源有一定程度的确定性。其目的是达到一定程度的防御，例如钓鱼和欺骗邮件，这可能会削弱接收者接收电子邮件的信任。对于需要超出身份验证的消息级加密的组织，S/MIME提供了端到端的安全性，自动收件人公钥收集使实现更具可扩展性。尽管如此，发送经过身份验证的邮件这一行为本身并不能断言邮件是好的或被需要的；这仅意味着可以可靠地建立和使用经过身份验证的实体的信誉，以做出电子邮件接收和放置决定。
目前使用的两种主要电子邮件身份验证形式是—Sender Policy Framework (SPF) 和DomainKeys Identifed Mail (DKIM)。 在这篇博客文章中，我将解释什么是SPF及其工作原理。
SPF 并非万无一失
虽然这看起来是一种相对简单的电子邮件认证方式，但SPF容易出现形式为假阴性的失败。这些失败发生的频率可能比许多人能接受的要高。
以下是两个常见场景，其中完全合法的邮件可能无法通过SPF验证，因此看起来是欺诈的：
自动转发，例如发送到jsmith@alumni.university.edu的邮件，自动转发所有邮件到jsmith@isp.com的邮箱
邮件列表，例如发送到talk-about-stuff@listserv.foo.com的邮件被“扩展”并发送到每个订阅者
在这两种情况下，如果退回路径与原始邮件保持不变，邮件可能无法通过SPF检查（取决于使用的'all'机制的修饰符）。这是因为邮件从中间服务器而不是原始服务器到达最终目的地，而那个中间服务器不太可能在域的SPF记录中。一种称为“Sender Rewriting Scheme”或“SRS”的技术可以降低这种风险，一些大型网站采用了这种技术，但它并不普遍。
虽然这看起来是一种相对简单的电子邮件认证方式，但SPF容易出现形式为假阴性的失败。这些失败发生的频率可能比许多人能接受的要高。
以下是两个常见场景，其中完全合法的邮件可能无法通过SPF验证，因此看起来是欺诈的：
自动转发，例如发送到jsmith@alumni.university.edu的邮件，自动转发所有邮件到jsmith@isp.com的邮箱
邮件列表，例如发送到talk-about-stuff@listserv.foo.com的邮件被“扩展”并发送到每个订阅者
在这两种情况下，如果退回路径与原始邮件保持不变，邮件可能无法通过SPF检查（取决于使用的'all'机制的修饰符）。这是因为邮件从中间服务器而不是原始服务器到达最终目的地，而那个中间服务器不太可能在域的SPF记录中。一种称为“Sender Rewriting Scheme”或“SRS”的技术可以降低这种风险，一些大型网站采用了这种技术，但它并不普遍。
虽然这看起来是一种相对简单的电子邮件认证方式，但SPF容易出现形式为假阴性的失败。这些失败发生的频率可能比许多人能接受的要高。
以下是两个常见场景，其中完全合法的邮件可能无法通过SPF验证，因此看起来是欺诈的：
自动转发，例如发送到jsmith@alumni.university.edu的邮件，自动转发所有邮件到jsmith@isp.com的邮箱
邮件列表，例如发送到talk-about-stuff@listserv.foo.com的邮件被“扩展”并发送到每个订阅者
在这两种情况下，如果退回路径与原始邮件保持不变，邮件可能无法通过SPF检查（取决于使用的'all'机制的修饰符）。这是因为邮件从中间服务器而不是原始服务器到达最终目的地，而那个中间服务器不太可能在域的SPF记录中。一种称为“Sender Rewriting Scheme”或“SRS”的技术可以降低这种风险，一些大型网站采用了这种技术，但它并不普遍。
SPF 概览
发送方策略框架 (SPF)，引用RFC 7208，是一种协议，不仅允许组织授权主机和网络在发送电子邮件时使用其域名，还提供了一种接收主机可以检查该授权的方法。
当你读完这篇文章后，希望你能了解到以下内容：
SPF是一个“路径式”认证系统。
SPF策略在DNS TXT记录中声明。
验证与Return-Path域（我们在SparkPost称之为“退回域”）或HELO域相关。
验证可以在SMTP事务早期进行，因此是快速拒绝未经认证邮件的良好检查。
它容易出现相对高比例的误判。
发送方策略框架 (SPF)，引用RFC 7208，是一种协议，不仅允许组织授权主机和网络在发送电子邮件时使用其域名，还提供了一种接收主机可以检查该授权的方法。
当你读完这篇文章后，希望你能了解到以下内容：
SPF是一个“路径式”认证系统。
SPF策略在DNS TXT记录中声明。
验证与Return-Path域（我们在SparkPost称之为“退回域”）或HELO域相关。
验证可以在SMTP事务早期进行，因此是快速拒绝未经认证邮件的良好检查。
它容易出现相对高比例的误判。
发送方策略框架 (SPF)，引用RFC 7208，是一种协议，不仅允许组织授权主机和网络在发送电子邮件时使用其域名，还提供了一种接收主机可以检查该授权的方法。
当你读完这篇文章后，希望你能了解到以下内容：
SPF是一个“路径式”认证系统。
SPF策略在DNS TXT记录中声明。
验证与Return-Path域（我们在SparkPost称之为“退回域”）或HELO域相关。
验证可以在SMTP事务早期进行，因此是快速拒绝未经认证邮件的良好检查。
它容易出现相对高比例的误判。
“Path-Based” Authentication
SPF 被认为是一种基于路径的身份验证系统，因为它仅与消息从起点到目的地的路径有关。当发送服务器与接收服务器启动 SMTP 事务时，接收服务器将根据域的 SPF 策略决定发送服务器是否被授权发送该消息。这完全是依据消息来源的决策，与消息内容无关。
SPF 被认为是一种基于路径的身份验证系统，因为它仅与消息从起点到目的地的路径有关。当发送服务器与接收服务器启动 SMTP 事务时，接收服务器将根据域的 SPF 策略决定发送服务器是否被授权发送该消息。这完全是依据消息来源的决策，与消息内容无关。
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验证的站点必须接受其为有效。
机制 | 功能 | 备注/使用指导 |
|---|---|---|
v=spf1 | 声明TXT记录是SPF策略 | 必须的第一个标记 |
ipv4 / ipv6 | 授权特定的IP或CIDR块 | 最明确且可靠的授权方法 |
a | 授权与域的A记录相匹配的IP | 适用于简单的基础设施 |
mx | 授权列在域的MX记录中的IP | 用于MX服务器也发送邮件时 |
include | 导入其他域的SPF策略 | 计算在10个DNS查询限制内；节省使用 |
redirect | 将SPF策略委托给另一个域 | 用于多个域共享一个SPF定义时 |
exists | 通过自定义DNS查询规则进行授权 | 适用于大而分散的IP范围；验证者必须支持它 |
ptr | 基于反向DNS映射授权 | 已弃用（“不要使用”），但验证器仍必须接受 |
all | 定义如何对待未显式允许的所有内容 | 变体：-all 拒绝，~all 软失败，?all 中立，+all 允许所有（不推荐） |
域名的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验证的站点必须接受其为有效。
机制 | 功能 | 备注/使用指导 |
|---|---|---|
v=spf1 | 声明TXT记录是SPF策略 | 必须的第一个标记 |
ipv4 / ipv6 | 授权特定的IP或CIDR块 | 最明确且可靠的授权方法 |
a | 授权与域的A记录相匹配的IP | 适用于简单的基础设施 |
mx | 授权列在域的MX记录中的IP | 用于MX服务器也发送邮件时 |
include | 导入其他域的SPF策略 | 计算在10个DNS查询限制内；节省使用 |
redirect | 将SPF策略委托给另一个域 | 用于多个域共享一个SPF定义时 |
exists | 通过自定义DNS查询规则进行授权 | 适用于大而分散的IP范围；验证者必须支持它 |
ptr | 基于反向DNS映射授权 | 已弃用（“不要使用”），但验证器仍必须接受 |
all | 定义如何对待未显式允许的所有内容 | 变体：-all 拒绝，~all 软失败，?all 中立，+all 允许所有（不推荐） |
域名的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验证的站点必须接受其为有效。
机制 | 功能 | 备注/使用指导 |
|---|---|---|
v=spf1 | 声明TXT记录是SPF策略 | 必须的第一个标记 |
ipv4 / ipv6 | 授权特定的IP或CIDR块 | 最明确且可靠的授权方法 |
a | 授权与域的A记录相匹配的IP | 适用于简单的基础设施 |
mx | 授权列在域的MX记录中的IP | 用于MX服务器也发送邮件时 |
include | 导入其他域的SPF策略 | 计算在10个DNS查询限制内；节省使用 |
redirect | 将SPF策略委托给另一个域 | 用于多个域共享一个SPF定义时 |
exists | 通过自定义DNS查询规则进行授权 | 适用于大而分散的IP范围；验证者必须支持它 |
ptr | 基于反向DNS映射授权 | 已弃用（“不要使用”），但验证器仍必须接受 |
all | 定义如何对待未显式允许的所有内容 | 变体：-all 拒绝，~all 软失败，?all 中立，+all 允许所有（不推荐） |
一些示例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 失败。
以下是一些示例记录及其含义。此示例显示了 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 失败。
以下是一些示例记录及其含义。此示例显示了 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 是否被授权为该域发送邮件，并决定是否接受该消息。
以下是涉及 SPF 时典型的 SMTP 事务的样子：
发送服务器（客户端）连接到接收服务器
接收服务器记录客户端的连接 IP 地址
他们交换问候，包括客户端的 HELO 主机名
客户端发出 SMTP MAIL FROM 命令
接收服务器现在可以查找 MAIL FROM 域或 HELO 主机名的 SPF 记录，以确定连接 IP 是否被授权为该域发送邮件，并决定是否接受该消息。
以下是涉及 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规范规定接收站点必须检查MAIL FROM域，并建议检查HELO主机名。在实践中，只对MAIL FROM域进行检查，除了在MAIL FROM地址是空发送者（即“<>”）的时候，此时HELO主机名是唯一可用的身份。
SPF规范规定接收站点必须检查MAIL FROM域，并建议检查HELO主机名。在实践中，只对MAIL FROM域进行检查，除了在MAIL FROM地址是空发送者（即“<>”）的时候，此时HELO主机名是唯一可用的身份。
