反向DNS（PTR）不匹配是导致邮件“静默失败”的主因：需确保服务器出口IP的PTR记录、Postfix的myhostname配置及正向A记录三者严格一致，否则Gmail等服务商会在HELO阶段拒连且日志仅显“unknown”或模糊超时。
邮件发不出去，但日志里没报错、telnet 能连上目标 SMTP、postqueue -p 显示邮件在队列里卡住不动——这种“静默失败”大概率是反向 DNS（PTR）不匹配被拒，而不是配置或网络问题。
怎么确认是不是反向解析导致的拦截
别猜，直接查目标服务器是否在拒绝你。Gmail、Outlook 等主流服务商不会明说“因 PTR 不对拒收”，但会在连接建立初期就断开，且日志中常出现模糊提示：
-
NOQUEUE: reject: RCPT from unknown[1.2.3.4]—— 注意unknown这个 hostname，说明对方反查你的 IP 没拿到有效域名 -
connect to gmail-smtp-in.l.google.com[]: Connection timed out—— 实际不是超时，而是对方收到 HELO 后校验失败，直接关闭连接（不发 RST，所以抓包看不到响应） -
status=deferred (connect to ...: Connection refused)—— 尤其出现在 relayhost 配置后，基本可锁定为对方主动拒连
验证方式：用 host 或 dig -x 查你服务器出口 IP 的反向记录，再对比 Postfix 的 myhostname 设置：
host 1.2.3.4<br>dig -x 1.2.3.4 +short
输出必须是一个**可解析的、与 myhostname 完全一致的 FQDN**（比如 mail.example.com.），且该域名的 A 记录必须能正向解析回同一 IP。
Postfix 的 myhostname 必须和 PTR 记录严格一致
很多人改了 DNS 的 PTR，却忘了同步改 Postfix 配置，结果对方反查得到 mail.example.com，而你的 myhostname 是 server1.local 或空值，直接触发拒绝。
- 检查当前值：
postconf myhostname - 修改
/etc/postfix/main.cf，确保这行存在且正确：myhostname = mail.example.com（末尾不加点，但 DNS 中 PTR 记录必须带结尾点） - 重启生效：
systemctl reload postfix，不要只postfix reload，避免参数未重载 - 验证 HELO 发出内容：
swaks --to test@gmail.com --server smtp.gmail.com:587 --ehlo，看输出里EHLO后跟的是不是你设的myhostname
云服务器厂商的 PTR 通常要手动申请，不能自助修改
阿里云、腾讯云、AWS 等默认不开放 PTR 修改权限，即使你在控制台填了，也不会自动生效；VPS（如 Linode、Hetzner）一般允许用户在后台设置，但需等待 DNS 缓存更新（通常 1–24 小时）。
- 先确认你用的是哪个 IP：
ip -4 route get 1.1.1.1 | awk '{print $7}'（取源地址） - 登录对应云平台，在“弹性公网 IP”或“反向 DNS”栏目提交申请，填写的域名必须能通过 A 记录正向解析到该 IP
- 别用
localhost、localhost.localdomain或内网域名（如ip-10-0-1-100.ec2.internal），这些一律被拒 - 设置后用
host YOUR_SERVER_IP多次测试，直到返回你填的域名，且无not found或connection timed out
容易被忽略的中间环节：MTA 自动 fallback 到 unknown
即使你配了 myhostname，Postfix 在某些场景下仍会退化使用 unknown：
-
inet_interfaces = loopback-only且未显式设myhostname，Postfix 会尝试从/etc/hosts解析，若失败就 fallback - 系统主机名（
hostname -f）不可解析，且myhostname为空时，Postfix 默认用unknown - 容器部署（如 Dify、Mailu）中，worker 容器的
/etc/hosts里没写宿主机的 FQDN，导致内部解析失败
所以务必运行：hostname -f 和 postconf myhostname 对比，两者输出必须一致，且都能被 host 正向解析。
