通过云Postfix服务器向Gmail发信遭SPF拦截的问题求助

问题分析 #

从你提供的退信信息来看，Google检测到你的发件域名（myhome.example.com）的SPF记录是硬拒绝（-all），但你自己配置的是软拒绝（~all），这说明要么你的SPF记录没有正确生效，要么发信时使用的MAIL FROM域名和你配置SPF的域名不一致，还有一种可能是你的SPF记录解析出现了问题。

另外，退信里提到发信IP（云VM的IP）没有通过SPF校验，但你明明已经把这个IP加到SPF里了，这进一步说明SPF记录的生效或匹配存在问题。

排查与解决步骤 #

1. 验证SPF记录是否正确生效 #

首先，你需要确认域名的SPF记录是否真的被正确解析。可以用dig命令在本地或云服务器上查询：

dig TXT myhome.example.com

检查返回的结果是否和你配置的v=spf1 ipv4:xxx.xxx.xxx.xxx include:_spf.google.com ~all完全一致。如果结果不对，说明域名记录还没有刷新（DNS缓存通常需要几分钟到几小时），或者你在域名服务商那里的配置有误。

2. 确认发信时的MAIL FROM域名 #

Postfix发信时的MAIL FROM地址（也就是信封发件人）可能和你以为的不一样。你可以在Postfix的日志里查看实际的发件域名，或者用telnet手动测试发信流程：

telnet gmail-smtp-in.l.google.com 25
EHLO myhome.example.com
MAIL FROM:<your-sender@myhome.example.com>
RCPT TO:<yyyyy@gmail.com>
DATA
Subject: Test SPF
This is a test email.
.

观察Google的响应，同时确认MAIL FROM里的域名确实是myhome.example.com——如果是其他域名（比如云服务器的主机名），那你需要在Postfix里配置正确的发件域名：
在main.cf里添加或修改：

myorigin = myhome.example.com

这样Postfix会使用你的家庭域名作为发件域名，而不是云服务器的本地主机名。

3. 检查SPF记录的语法和优先级 #

你的SPF记录里包含了include:_spf.google.com，这是允许Google的服务器代发你的域名邮件，但你的主要发信IP是云VM的IP，所以要确保ipv4:xxx.xxx.xxx.xxx的位置是正确的，没有语法错误。另外，~all是软拒绝，不会导致硬失败，但Google的退信说检测到的是-all，这很可能是DNS解析的问题，一定要确认SPF记录没有被错误设置成-all。

4. 测试SPF校验结果 #

可以用SPF校验工具输入你的发信IP和域名，看看校验结果是否通过。如果工具显示“SPF Pass”，那说明记录是对的，可能是Google的缓存还没更新，等一段时间再试；如果显示失败，再排查记录的语法问题。

5. 检查Postfix的发信配置 #

确认Postfix没有使用其他IP发信——比如如果你的云VM有IPv6地址，即使设置了smtp_address_preference=ipv4，也要确保Postfix没有优先使用IPv6。可以在main.cf里强制禁用IPv6：

inet_protocols = ipv4

这样Postfix只会用IPv4发信，避免IPv6地址没有被加入SPF记录导致的校验失败。

总结 #

最可能的问题是你的SPF记录没有正确生效（DNS缓存或配置错误），或者Postfix发信时使用了错误的发件域名。按照上面的步骤逐一排查，应该能解决Google的SPF拦截问题。

备注：内容来源于stack exchange，提问作者akc42