WordPress 询盘邮件收不到怎么办：把表单、发信、认证与线索留存逐层查清

WordPress 表单显示“提交成功”却收不到询盘邮件时，先保住线索，再排查投递。一次提交至少经过表单、WordPress、发信服务和收件系统四层，前端成功只证明其中一部分完成。

先画出询盘经过的四个节点

很多团队遇到丢信后立即更换 SMTP 插件，但连表单是否在服务器生成过消息都没有确认。先选一条受控测试，在不会发送客户隐私的前提下记录提交时间、页面 URL、测试邮箱、表单结果和收件地址。

• 节点：浏览器到网站；要确认的证据：Network 请求、状态码、页面成功提示；失败时优先看哪里：JavaScript、缓存、WAF、接口校验
• 节点：WordPress 处理；要确认的证据：表单条目、应用日志、错误日志；失败时优先看哪里：表单配置、必填字段、插件冲突、PHP 错误
• 节点：WordPress 到发信服务；要确认的证据：message ID、SMTP / API 接受或拒绝记录；失败时优先看哪里：发件身份、凭证、端口、限额、服务状态
• 节点：发信服务到收件箱；要确认的证据：Delivered、Deferred、Bounced、Spam 等投递结果；失败时优先看哪里：SPF / DKIM / DMARC、收件规则、退信原因

如果表单插件支持保存提交记录，先确认这条测试是否已经落库。没有落库时，问题还在网站层；有记录但发信日志为空，继续查 WordPress 事件和通知配置；发信服务已经接受但收件箱没有，再进入投递与域名认证层。

`wp_mail()` 成功不等于对方已经收到

WordPress 的 `wp_mail()` 官方说明明确指出：函数返回 `true` 只表示当前发送方法处理请求时没有报错，并不自动证明邮件已送达收件人。表单插件显示成功，也可能只是保存或排队成功。

因此不要只看绿色提示。需要拿到发信服务的 message ID 或投递日志，判断消息是被接受、延迟、退回还是进入垃圾邮件。若日志显示连接或认证失败，核对主机能否访问发信服务、端口与加密方式、账号权限和凭证是否仍有效；不要把密码、API key 或完整邮件内容贴进公开工单。

如果同一时段 WordPress 的密码重置、管理员通知和表单邮件都失败，问题更可能在全站发信链。只有一个表单失败时，优先检查该表单的收件人、触发条件和模板变量，而不是先改服务器 DNS。

发件人和回复人要分开

常见错误是把访客填写的 Gmail、Outlook 或企业邮箱直接放进 `From`。网站并不被授权代表访客域名发信，这会让 SPF、DKIM 与 DMARC 对齐失败，邮件更容易被拒绝或归入垃圾箱。

更稳妥的结构是：`From` 使用网站自己控制并由发信服务授权的域名地址，`Reply-To` 再使用访客邮箱。这样销售点击回复仍能联系访客，投递系统也能验证真正的发件身份。

核对发送域名的 SPF、DKIM 与 DMARC 时，要看实际发信服务给出的当前记录，不复制另一家服务商的值，也不要创建多条互相冲突的 SPF。发送测试后检查完整邮件头，确认认证结果和对齐域名，而不是只看 DNS 管理页显示“已保存”。

邮件不能是询盘的唯一存档

邮件投递再稳定，也不应是唯一线索记录。表单至少要有受控的服务器端条目、CRM 或其他可审计存档，并按业务需要设置失败告警。存档字段只收集跟进所需信息，限制后台角色，设定合理保留期，不在日志中记录密码、Cookie 或无关个人数据。

可以每天对照“表单成功数、已保存条目、发信服务接受数和销售收到数”。四个数字一旦不同，团队能在当天发现断点，而不是等客户从 WhatsApp 追问才知道邮件丢了。

同时准备一个不依赖同一邮件链的备用联系入口，例如站内明确展示的 WhatsApp、微信或电话。备用入口是为了不丢线索，不应掩盖邮件故障；修复后仍要回放受影响时间段的表单记录，避免漏跟进。

用一次回归证明整条链路恢复

修复后从真实公开页面提交一条标明测试的记录，验证前端错误与成功状态、表单条目、邮件内容、Reply-To、发信日志、目标收件箱和手机端回复。再测试一个错误邮箱，确认退信能被看到；检查垃圾邮件规则、转发和共享邮箱权限，避免邮件已送达却无人负责。

WordPress 询盘投递同时涉及表单交互、主题或插件、服务器发信、DNS 和销售流程。李李出海可以协助检查 WordPress 页面体验、表单实现与长期维护边界，并把关键线索留存和备用联系入口一起验收。联系时提供测试时间、页面、脱敏日志、发信服务状态和域名认证结果即可，不要发送邮箱密码或客户真实询盘内容。