WordPress 邮件发不出去排查（2026 实操）：wp_mail 说成功，postfix 挂了 71 天

站点没挂，页面秒开，但读者说收不到评论回复通知，我自己试了一次找回密码，邮件也没影。WordPress 后台不会告诉你邮件丢了，wp_mail 返回什么，完全取决于它底下那条通道通不通。

邮件这套东西拆成两层看就够了：一层是 WordPress 把信交给谁，一层是接手的那个服务能不能把信送出去。分开查，五分钟能定位。

WordPress 有两条发信通道，先搞清楚你在用哪条

第一条是主题或插件自带的 SMTP。子比主题就在 inc/functions/zib-email.php 里挂了 phpmailer_init 钩子，填好服务器、端口、账号之后，所有 wp_mail 都直接连服务商的 465 端口，绕过本机邮件服务。

第二条是 WordPress 的默认路径，PHP 的 mail() 调 /usr/sbin/sendmail，交给本机的 postfix 往外投。

两条路的故障表现完全不同。前者连不上会当场报错，后者经常静默失败，信丢在半夜的日志里，一个月都没人发现。本站恰好两条都在用，也恰好只有第二条是坏的。

第一步：让 wp_mail 把话说清楚

别在后台点按钮试，直接用 WP-CLI 在命令行跑一次：

wp eval 'var_dump(wp_mail("you@example.com","测试主题","测试正文"));' --allow-root

返回 true 只说明 PHPMailer 没当场抛错，不代表收件箱里有东西。想确认这封信走到了哪条通道，跑完立刻翻日志里有没有 sendmail 的痕迹，没有痕迹就说明被主题的 SMTP 接管了。

要直接验 PHP 那一层，就绕开 WordPress 单独测：

php -r 'var_dump(mail("root@localhost","probe","body"));'

修复之前，这条命令在本站返回 bool(false)，屏幕上还甩出一句：

sendmail: fatal: parameter inet_interfaces: no local interface found for ::1

第二步：顺着 sendmail 找到 postfix

线索在 /var/log/maillog。本站这个文件单周 24 万字节，2017 条记录全是同一句 fatal，288 条一天，正好五分钟一次。

tail -50 /var/log/maillog
systemctl status postfix --no-pager
postconf -n | grep -E '^(inet_interfaces|inet_protocols)'

服务状态显示 postfix 从 8 月 3 日 08:16 就 failed 了，两个多月没人碰过。配置里 inet_interfaces = localhost，inet_protocols = all，而系统在 /etc/sysctl.conf 里把 IPv6 整个关掉了，net.ipv6.conf.all.disable_ipv6 写的是 1。

localhost 解析到 ::1，机器上却没有 ::1 这个接口，postfix 找不到可绑定的地址，直接退出。CentOS 7 的默认 main.cf 撞上云厂商的禁用 IPv6 模板，几乎是个必然踩的坑。

改之前先备份，两行命令修掉：

cp -a /etc/postfix/main.cf /root/main.cf.bak-$(date +%Y%m%d)
postconf -e 'inet_protocols = ipv4'
postconf -e 'inet_interfaces = 127.0.0.1'
systemctl restart postfix && systemctl is-active postfix

inet_interfaces 我写的是 127.0.0.1，不是 all。本机只当投递客户端用，监听回环就够了，写成 all 等于把 25 端口敞给全网，扫段脚本一天能给你刷出几十万条垃圾信。重启之后日志里应该出现 daemon started，那句 fatal 消失。

顺手还修了个权限问题。这台机器的 /var/spool/postfix/maildrop 属主是 root，日志里冒 warning: remove maildrop/xxx: Permission denied，chown postfix:postdrop 加 chmod 730 之后才干净，卡在队列里的信 postsuper -d ALL 清掉。

第三步：本机能发，不等于收件方肯收

先把本机短投测通：

php -r 'var_dump(mail("root@localhost","probe","body"));'
tail -5 /var/log/maillog

实测返回 bool(true)，日志里是 status=sent (delivered to mailbox)，测试信落进了 /var/spool/mail/root。本机这一层通了，往外发还要过两道门。

第一道是出站 25 端口。阿里云默认封禁 ECS 出方向的 TCP 25，官方文档写得很明确，要解封得去安全管控平台提交申请。测一下就知道：

timeout 8 bash -c 'cat < /dev/null > /dev/tcp/gmail-smtp-in.l.google.com/25' && echo OPEN || echo BLOCKED

本站返回 BLOCKED，同样的测法换 465 端口是通的。所以别折腾本机直投了，让 PHP 去连服务商的 465 或 587 中继，信从他们的 IP 出去。

第二道是域名身份。收件方不只看 IP，还看 SPF、DKIM、DMARC，这个域名三条记录都是空的：

dig +short TXT littlesheep.cc
dig +short TXT _dmarc.littlesheep.cc
dig +short MX littlesheep.cc

空的意味着谁都能拿这个域名伪造发信。用阿里云邮件推送的话，SPF 写成 v=spf1 include:spf1.dm.aliyun.com -all，DKIM 公钥在控制台生成，主机记录形如 aliyun-cn-hangzhou._domainkey.你的发信域名，DMARC 先用 p=none 收两周报告再收紧。发信地址的域名和站点域名不一致时，这些记录要加在发信那个域名上，不然照样白配。

第四步：让 WordPress 老老实实走 465

主题自带 SMTP 设置的话，把主机、端口 465、SSL、SMTPAuth 填好就够了。主站现在就是这么跑的：wp_mail 返回 true，maillog 里一条新的 sendmail 记录都没有，说明信确实走了 465 出去。

没有主题兜底，就用一个 mu-plugin 接管全部 wp_mail：

<?php
// wp-content/mu-plugins/site-smtp.php
add_action('phpmailer_init', function ($phpmailer) {
    $phpmailer->isSMTP();
    $phpmailer->Host       = 'smtpdm.aliyun.com';
    $phpmailer->Port       = 465;
    $phpmailer->SMTPSecure = 'ssl';
    $phpmailer->SMTPAuth   = true;
    $phpmailer->Username   = 'no-reply@your-domain.com';
    $phpmailer->Password   = defined('SMTP_PASS') ? SMTP_PASS : '';
    $phpmailer->From       = 'no-reply@your-domain.com';
    $phpmailer->FromName   = '你的站点名';
}, 99);

密码放 wp-config.php 的常量里，别写死在代码，更别存进数据库。我在这台机器的主题设置里就看到 SMTP 密码以明文躺在 wp_options 里，任何能读库的插件、任何一份数据库备份都能顺手把它拿走。

验证一遍：命令行调一次 wp_mail，看收件箱和垃圾箱，再用 grep "status=sent" /var/log/maillog 对照。信还是掉进垃圾箱，问题就在 SPF 和 DKIM，不在代码。

常见坑与回滚

改 postfix 之前备份 main.cf，回滚就是把备份覆盖回去再重启，两分钟的事。inet_interfaces 别改成 all，mynetworks 别写 0.0.0.0/0，那等于给人做 open relay。改完顺手 systemctl enable postfix，不然机器一重启又回到 failed。

容易忽略的是触发源。/etc/crontab 里任何带 MAILTO 的任务、宝塔面板的计划任务，输出都会尝试发一封邮件。本站那 2017 条 fatal 是微步 OneAV 的 5 分钟巡检脚本触发的，脚本本身没毛病，是邮件通道在偷偷报错。想让 cron 安静下来，把输出重定向到日志文件，或者把 MAILTO 留空，但这只是盖住症状，先修通道更值。

排查这类问题的顺序其实挺固定：确认通道，让日志说话，剩下的才是端口和 DNS 那些外部条件。上次那篇讲 502 和白屏 用的是同一套思路，一层一层往下剥；系统 crontab 替掉 wp-cron 那篇提到的定时任务，也是找发信触发源的入口。