解决邮件SPF记录故障

笔者所在单位在DMZ区域部署了自建邮件系统（如 图 1），为满足公网用户及内网用户都能正常的访问邮件系统，在出口防火墙配置了NAT双向地址转换（如图2）。

图1 邮件系统部署网络拓扑图

图2 防火墙对邮件服务器NAT双向转换设置

在此处之所以配置NAT双向转换，是考虑到内网用户需要通过公网地址访问邮件系统。如配置为NAT目的地址转换（即端口映射），则会造成邮件服务器返回内网用户的数据包目的地址被更改，数据不能正确返回到内网用户，造成通信失败。关于NAT地址转换的相关模式，在此不做介绍。

故障现象

用户通过公司邮件系统发送邮件正常。但公司邮件系统收取第三方邮件系统的邮件，则出现选择性收信故障：QQ等邮箱发送给公司邮箱的信件可正常收取 ；而 126、163等邮件系统无法正常发送给公司邮局信件，发送方收到错误退信提示：

SMTP error, DOT: 550 Requested mail action not taken: Invalid IP<218.X.X.3>

注：218.X.X.3为公司邮件系统公网地址。

故障分析

鉴于故障现象的特点，首先把故障分析的着眼点放到QQ邮箱与126邮箱的差异及故障退信的错误提示上。经联系企业邮箱客服及退信提示分析，退信是因为SPF记录检查不通过而导致的。

SPF“Sender Policy Framework，发件人策略框架”，是目前一种实用的反垃圾邮件解决方案。它是一种TXT类型的DNS记录，通过提前设定指定的、合法的发送电子邮件服务器IP记录，来验证邮件发件人的身份，即SPF记录指定了一个域名下的邮件必须通过哪些SMTP服务器来发送邮件。接收邮件方在接收邮件时，首先要检查发件方后缀域名的SPF记录，如SPF记录与发件人SMTP的IP相吻合，那就是合法邮箱。如有差异，那就会被认为是伪造的邮件从而退回。

图3 调整后针对邮件服务器NAT转换设置

从本例的故障中可以看出，126邮箱应该设置了SPF记录，当公司邮箱收到126邮箱发来的邮件时，会对126邮箱的SPF记录与来信的SMTP IP进行比对，因为SMTP IP为218.X.X.3 （故障退信中标注）与126的SPF不符，故造成退信。而QQ邮箱未设置SPF记录，故不进行核对，收信无问题。

那么126的SMTP怎么变成的218.X.X.3呢？这个就与防火墙对于邮件服务器的NAT双向地址转换有关了。如图2所示，无论公网还是内网用户访问公司邮箱的公网地址，所有的源地址转换为公司邮箱的公网地址，目的地址转换为公司邮箱的内网地址。由此一来，其他邮箱发往公司邮箱的邮件SMTP源地址都被转换成了218.X.X.3，所有设置SPF记录的邮箱发送都会出现故障。

故障解决

笔者通过讨论分析，利用NAT转换的顺序组合，将NAT转换对于公网用户和内网用户分别进行设置转换：对于公网用户只进行目的转换，不更改源地址，消除SPF记录故障；对于内网用户保留了原来的双向转换，确保可访问性。另外，对于公网用户的NAT转换一定要优先于内网用户转换，以确保SPF问题的消除（如图3）。

故障总结

对于本例防火墙设置的优化及故障排除，是基于对源地址转换、目的地址转换、双向地址转换的理解和灵活组合运用，此外更少不了对类似SPF相关应用场景、应用特点的了解和分析。

针对出现的问题，不要先急于调整。如果从错误信息、厂商反馈、经验讨论等方面进行着手分析，逐步缩小故障范围，像类似的故障是不难处置的。