1、前言

作为邮件安全里最最最基础的安全策略之一，SPF（Sender Policy Framework）用于验证电子邮件的发送者是否被授权代表他声称的主机发送邮件。SPF 检查结果有几种状态，这些状态表明了你的邮件服务器或者邮件安全措施（包括但不限于硬件网关、软件网关等）对 SPF 记录的验证结果。

如果你遇到了一封可疑邮件，那么可重点先看看这个字段——SPF。请注意，虽然通过SPF检查并不代表它就不是钓鱼邮件，SPF检查也不能100%拦截钓鱼邮件，但它是一个重要因素，可以推测攻击者的技战术，同样，合适的SPF检查策略，可以拦截掉一大批低级的钓鱼邮件攻击（简单域名伪造）。

2、基本概念

直接复制过来DeepSeek的答案，客官不要嫌弃，老司机可直接跳过。

1. Pass

• 含义：发件服务器的IP地址与域名SPF记录中授权的IP地址匹配，验证通过。
• 处理方式：邮件被接受，标记为合法发件人。
• 示例：
  v=spf1 include:_spf.google.com ~all（Google Workspace的SPF记录）。

2. Fail

• 含义：发件服务器的IP地址未在SPF记录中授权，明确验证失败。
• 处理方式：邮件可能被直接拒收或标记为垃圾邮件。
• 关键点：
  • 通常由SPF记录中的 -all机制触发（严格策略）。
  • 需谨慎使用，避免因配置错误导致合法邮件被拒。

3. SoftFail

• 含义：发件服务器IP地址未被明确授权，但可能属于临时或非关键来源（例如测试环境）。
• 处理方式：邮件可能被接受，但标记为可疑或降低信任评分。
• 语法关联：
  SPF记录中通过 ~all声明（软失败策略）。

4. Neutral

• 含义：SPF记录未明确声明是否授权该IP地址，验证结果“中立”。
• 处理方式：邮件正常投递，但SPF验证不提供任何信任依据。
• 典型场景：
  SPF记录仅包含 ?all（中性策略），或未完全覆盖所有发件源。

5. None

• 含义：域名未发布任何SPF记录，无法进行验证。
• 处理方式：接收方可能根据其他反垃圾邮件策略处理邮件。
• 风险：
  未配置SPF的域名易被伪造，建议尽快添加SPF记录。

6. TempError

• 含义：临时性验证错误（如DNS查询超时或服务器故障）。
• 处理方式：邮件可能被暂存并重试，不直接影响投递结果。
• 常见原因：
  DNS服务器响应缓慢或SPF记录语法复杂导致解析失败。

7. PermError

• 含义：永久性验证错误（如SPF记录语法错误或超过DNS查询限制）。
• 处理方式：邮件可能被拒绝或标记为高风险。
• 典型问题：
  • SPF记录超过10次DNS查询限制（RFC 7208规定）。
  • 包含非法字符（如未转义的空格）。

SPF状态处理建议

1. 优先使用 Pass和严格策略：

• 通过 include机制整合可信服务商（如邮件服务商、CRM系统）。
• 使用 -all拒绝未授权的IP地址，但需确保覆盖所有发件源。

避免常见错误：

• 检查SPF记录是否超过10次DNS查询。
• 使用工具验证语法合法性。

结合DKIM和DMARC：
SPF是反垃圾邮件的基础，需与DKIM（邮件签名）和DMARC（投递策略）配合使用，提升整体安全性。

总结

SPF的七种状态（Pass、Fail、SoftFail、Neutral、None、TempError、PermError）反映了邮件发件人验证的不同结果。合理配置SPF记录（如明确授权IP、避免语法错误）可显著降低钓鱼邮件和伪造风险，同时需注意与其他安全协议（DKIM/DMARC）的协同部署。若需具体配置指导或问题排查，可进一步分析您的域名SPF记录。

3、案例分析

下面我用一个案例具体实践一下：

这是一次事后溯源分析，邮件本是一封钓鱼邮件，造成的影响极其恶劣。DeepPhish EML分析工具(deepphish.cn) 在SPF记录中给出的红灯判断，后面有佐证描述，翻译过来就是“失败（protection.outlook.com: txstarsecurity.org的域不指定164.132.67.30作为允许发送者）客户端ip = 164.132.67.30; helo= (127.0.0.1)，这里的“允许发送者是指的发件服务器哦，而不是普通终端地址，而这封邮件的发件人alarmsales@txstarsecurity.org，显然是伪造的，DeepPhish不仅判断了SPF，还在发件人IP处标出了client-ip=164.132.67.30。helo这个字段默认是取主机IP，因此是127.0.0.1，但它也可以伪造，以后再表。

这个IP是哪里的呢？查询如下：

那么txstarsecurity.org声明的合法发件服务器是什么呢，我们用一个工具查一下，不推荐手工命令查，因为一旦涉及到递归，比较麻烦。如下图，非常复杂，眼睛是看不过来的，ctrl F一把，显然没有DeepPhish提取出的Client IP，当然它配置也相当乱，疑似黑产（有点后怕）。

好了，简单的SPF分析到此结束，更关键的是SPF检查失败，恶意邮件怎么还进来了呢？近年处理的很多钓鱼事件中，回溯发现很多都存在基础问题，背后有各种各样的原因，比如中小型组织人力资源和能力有限，而大型组织由于系统复杂、流程复杂，导致了基础问题被隐藏，也就是所谓的安全运营吧。

一方面要坚持夯实技术基础并定期检验，另一方面，技术并非万能，安全团队不应独自背负所有责任，把小伙伴拉进来一起培养安全文化，让公司全员参与，与安全团队共同抵御外部威胁。