WordPress 发送邮件失败怎么办？SMTP、SPF、DKIM、DMARC 与退信排查指南

WordPress 能正常发布文章、提交表单，用户却收不到注册验证、找回密码或订单通知，这类问题不能只看“邮件有没有发出去”。完整的投递链路至少包含 WordPress、PHP 邮件组件、SMTP 服务、域名认证、收件服务器和垃圾邮件策略，任何一层出错，最终表现都可能是“邮箱里没有信”。

排查时不要一上来反复更换 SMTP 插件。先确认故障发生在生成邮件、连接 SMTP、发件人认证、收件服务器接收，还是进入垃圾箱，处理速度会快很多。

先判断邮件卡在哪一层

可以把 WordPress 邮件投递拆成下面五步：

WordPress 生成邮件
        ↓
PHP / PHPMailer 处理
        ↓
SMTP 服务器接受投递
        ↓
SPF、DKIM、DMARC 等身份检查
        ↓
收件服务器投递到收件箱、垃圾箱或直接拒收

wp_mail() 返回 true，只代表 WordPress 的邮件处理流程没有立即报错，并不代表收件服务器已经把邮件放进收件箱。邮件可能在后续队列中退信，也可能因为域名认证、信誉或内容策略被拦截。

因此，排查时至少要收集四项信息：

• 哪一种邮件失败，是所有邮件都失败，还是只有找回密码、表单或订单邮件失败。
• 发件地址和收件地址分别是什么，是否只有 Gmail、Outlook 或企业邮箱收不到。
• SMTP 插件或邮件服务商返回的错误码、退信内容和 Message-ID。
• 问题是刚开始出现，还是从换域名、换服务器、启用 CDN、修改 DNS 后出现。

如果只有某个插件的通知失败，而 WordPress 测试邮件正常，优先检查该插件的触发条件、队列和模板；如果所有邮件都失败，再检查公共邮件链路。

第一步：确认 WordPress 真的生成了邮件

先用站点当前的 SMTP 插件发送测试邮件，并同时测试一个真实业务动作，例如申请重置密码。只测插件自带的测试按钮不够，因为它可能绕过表单插件、商城任务队列或会员系统的部分逻辑。

还可以临时记录 WordPress 的邮件失败事件：

add_action('wp_mail_failed', function ($error) {
    error_log('wp_mail failed: ' . $error->get_error_message());
});

这段代码适合放在临时调试插件或受控的代码片段工具中。完成排查后应删除，避免日志长期增长。不要把 SMTP 密码、邮件正文或用户隐私写入公开日志。

同时检查：

• 表单提交后是否确实触发通知，而不是被验证码或反垃圾规则提前拦截。
• WooCommerce、会员系统等是否使用 Action Scheduler、WP-Cron 或独立队列延迟发送。
• 网站时区和系统时间是否正常，计划任务是否积压。
• 发件地址是否被插件覆盖，多个 SMTP 或安全插件是否同时接管 wp_mail()。

如果页面提示发送成功，但邮件日志里完全没有记录，问题通常还在业务插件或任务队列，而不是 SMTP 服务器。

第二步：检查 SMTP 主机、端口与加密方式

常见 SMTP 提交端口是 587 配合 STARTTLS，部分服务也提供 465 的隐式 TLS。具体端口、主机名和加密方式必须以邮件服务商控制台为准，不能只凭经验组合。

需要逐项核对：

• SMTP 主机名是否正确，不能把 Webmail 登录地址直接当成 SMTP 地址。
• 用户名是否要求完整邮箱地址。
• 密码是邮箱登录密码、应用专用密码，还是单独生成的 SMTP 凭据。
• 端口与加密方式是否匹配。
• “From 发件地址”是否属于已验证域名，是否与认证账号被服务商允许的发件身份一致。

从服务器测试端口连通性：

nc -vz smtp.example.com 587

或者检查 STARTTLS 握手：

openssl s_client -starttls smtp -connect smtp.example.com:587 \
  -servername smtp.example.com

Windows 环境可使用：

Test-NetConnection smtp.example.com -Port 587

如果这里就超时，应检查云平台出站规则、主机防火墙、服务商是否限制 25 端口，以及当前 SMTP 服务是否只允许白名单 IP。很多云服务器对 25 端口有限制，网站通知通常更适合使用邮件服务商提供的 465 或 587 提交端口。

如果能连接但 TLS 握手失败，检查服务器时间、CA 证书、OpenSSL 版本、SNI 主机名以及中间网络是否做了不兼容的代理。不要为了“先发出去”长期关闭证书验证。

第三步：看懂常见 SMTP 错误

SMTP 错误通常比 WordPress 页面上的“发送失败”更有价值。

535：认证失败

常见原因包括用户名或密码错误、账号启用了多因素认证但仍使用普通密码、应用专用密码失效、SMTP AUTH 未开启，或者登录来源被风控拦截。

处理时应重新生成专用凭据，不要在多个站点之间共用同一密码。若邮件账号异常登录较多，应先修改密码、撤销旧凭据，再检查 WordPress 文件和管理员账号是否被入侵。

550、553：发件人或收件人被拒绝

这类错误可能表示发件地址未验证、没有中继权限、收件地址不存在，或者服务商不允许用当前账号冒充另一个 From 地址。

例如使用 notice@example.com 认证，却把 From 设置成 admin@another-domain.com，即使用户名和密码正确，也可能被拒绝。建议使用已验证域名下的固定通知地址，访客填写的邮箱放在 Reply-To，而不是直接作为 From。

421、450、451、452：临时失败

常见于发送频率过高、服务暂时繁忙、灰名单、连接数超限或账号配额不足。临时错误应由可靠的队列重试，而不是让页面请求立即连续重发。短时间反复尝试可能进一步触发限流。

554、5.7.x：策略或信誉拒收

通常与 SPF、DKIM、DMARC、IP 或域名信誉、邮件内容和投诉率有关。此时单纯更换 WordPress 插件往往无效，应查看完整退信，按收件服务商给出的增强状态码处理。

第四步：检查 SPF，避免授权范围混乱

SPF 用 DNS TXT 记录声明哪些服务器可以代表域名发信。最常见的错误不是“完全没配”，而是域名里出现多条 SPF 记录，或者不断叠加 include，最终超过查询限制。

一个域名通常应合并为一条以 v=spf1 开头的 SPF 记录。例如：

v=spf1 include:mail-provider.example -all

这只是结构示例，不能直接复制。真实内容必须使用邮件服务商提供的值。

检查重点：

• 根域名下是否存在两条或更多 v=spf1 记录。
• 邮件是否通过第三方服务发送，但 SPF 没有包含该服务。
• include、a、mx、redirect 等机制是否造成过多 DNS 查询。
• 换邮件服务后，旧服务的授权是否仍被保留。
• 使用子域发信时，认证域名是否与实际 Return-Path 对齐。

可以使用 dig TXT example.com 或 DNS 服务商的查询工具查看记录。修改后要等待 DNS 生效，并在邮件头的 Authentication-Results 中确认 SPF 最终是 pass，而不是只看控制台显示“已添加”。

第五步：启用 DKIM，确认签名没有被破坏

DKIM 会给邮件添加数字签名，收件服务器再通过 DNS 中的公钥验证邮件是否确实由授权服务发出，以及关键内容在传输中是否被修改。

配置时通常需要在 DNS 中添加服务商给出的 TXT 或 CNAME 记录，并在邮件服务控制台启用对应选择器。检查时注意：

• 选择器名称是否完整，是否误把主机名重复拼接了域名。
• DNS 记录是否已经在公网可查询。
• 邮件服务控制台是否完成验证并真正开始签名。
• 邮件经过转发、网关或插件重写后，正文和关键头是否发生变化。

不要自己随意生成一对密钥后只把公钥放进 DNS。DKIM 私钥必须由实际发送邮件的系统使用；如果 WordPress 通过第三方 SMTP 发信，应按该服务商的流程配置。

第六步：用 DMARC 检查“对齐”，不要直接上强拒绝

DMARC 会结合 SPF 和 DKIM 的结果，判断通过验证的域名是否与用户看到的 From 域名对齐，并允许域名所有者发布处理策略和接收报告。

初次部署可以先从监控策略开始：

v=DMARC1; p=none; rua=mailto:dmarc-report@example.com

确认所有合法发信来源都能通过并对齐后，再逐步评估 quarantine 或 reject。如果网站通知、客服系统、工单平台和营销邮件分散在多个服务商，直接启用严格拒绝可能先拦住自己的正常邮件。

DMARC 通过并不意味着邮件一定进入收件箱，但缺少认证或对齐失败，会显著增加被拒收或进入垃圾箱的概率。对于发送量较大的域名，还应持续关注投诉率、退信率和发送信誉。

第七步：从收到的邮件头验证结果

最有效的验证方式，是把测试邮件发到可以查看原始邮件的邮箱，然后检查：

Authentication-Results:
  spf=pass
  dkim=pass
  dmarc=pass

还要查看：

• Received 链路是否与预期 SMTP 服务一致。
• From、Return-Path 和 DKIM 签名域名分别是什么。
• Message-ID 是否存在且格式正常。
• 邮件是否延迟很久才到，还是立即进入垃圾箱。

如果 Gmail 能收到而企业邮箱拒收，或者反过来，不要笼统判断为“SMTP 坏了”。对比两边的退信、认证结果和策略提示，才能定位是收件方规则、域名信誉还是账号配置。

WordPress 邮件配置的稳妥做法

对于需要稳定发送注册、订单、告警和找回密码邮件的网站，建议采用以下结构：

1. 使用专门的事务邮件服务或企业邮箱 SMTP，不依赖主机本地 mail() 随机投递。
2. 为网站通知设置固定发件地址，例如 notice@example.com。
3. 把访客邮箱放在 Reply-To，避免伪造 From 导致 DMARC 对齐失败。
4. 使用应用专用密码或独立 API/SMTP 凭据，并限制权限。
5. 配置 SPF、DKIM 和 DMARC，保留 DNS 变更记录。
6. 开启邮件日志，但限制保存期限并保护敏感信息。
7. 对重要业务使用队列、失败重试和告警，不依赖单次页面请求。

SMTP 凭据不应直接写进主题文件或公开代码仓库。更换服务商、管理员离职或发生安全事件后，应及时轮换密码和撤销旧凭据。

修复后按这份清单验收

• WordPress 测试邮件和真实业务邮件都能生成。
• SMTP 端口可连接，TLS 证书验证正常。
• 认证账号、From 地址和服务商允许的发件身份一致。
• SPF、DKIM、DMARC 在真实邮件头中均得到预期结果。
• Gmail、Outlook 和主要业务邮箱至少各测试一次。
• 正文邮件、纯文本邮件、附件邮件都符合业务需要。
• 找回密码、注册、表单和订单通知分别测试。
• 失败日志和邮件服务控制台能查到 Message-ID 或投递记录。
• 没有为了绕过问题而关闭 TLS 验证或放宽账号安全设置。

WordPress 邮件故障的关键不是“换一个插件试试”，而是确定邮件在哪一层停止。先确认业务是否触发，再查 SMTP 连接和认证，随后验证 SPF、DKIM、DMARC 与真实邮件头，最后处理信誉和收件策略。只要保留错误码、退信和投递记录，大多数“邮件凭空消失”的问题都能缩小到明确的环节。

参考资料

• WordPress Developer Resources：《wp_mail()》《wp_mail_failed》《phpmailer_init》
• Google Workspace Admin Help：《Email sender guidelines》
• PHPMailer Wiki：《Troubleshooting》
• RFC 7208：《Sender Policy Framework (SPF)》
• RFC 6376：《DomainKeys Identified Mail (DKIM) Signatures》
• RFC 7489：《Domain-based Message Authentication, Reporting, and Conformance (DMARC)》

资料核查日期：2026 年 9 月 18 日。SMTP 端口、认证方式、发信额度和收件策略可能调整，请以当前邮件服务商和收件平台的官方文档为准。