阅读前确认：页面提示成功不等于邮件已经进入收件箱。先记录一次带唯一标记的测试，再沿发送链路排查；不要公开客户资料或发信密钥。
先确认问题发生在哪个环节
一次询盘通常经历浏览器提交、表单处理、邮件发送服务和收件系统。页面报错可能发生在提交阶段，显示成功却没有收到邮件则需要继续查看发送与投递记录。WordPress 的 wp_mail 返回成功，也不能单独证明收件人已经收到。
用唯一标记区分测试，例如在主题中写明日期与测试编号，记录提交时间和目标收件箱。尽量先用无附件的简单内容测试，避免同时引入文件大小、类型或安全扫描等变量。测试应发往你有权使用并能核查的邮箱。
检查字段与通知模板是否对应
确认邮箱字段必填且类型正确，通知模板引用的字段名称与表单一致。增加或重命名字段后，邮件正文中的标签不一定同步变化；缺失的产品型号或客户需求，可能是模板配置问题而不是邮件服务故障。
核对收件地址是否拼写正确、是否已经停用或转发到别处。邮件主题加入网站和产品识别信息，正文保留提交时间及必要上下文。不要收集业务并不需要的敏感资料，也不要让用户误以为提交后就一定完成报价或订单。
| 观察结果 | 下一步检查 |
|---|---|
| 页面直接报错 | 请求状态、字段校验、验证码与安全拦截 |
| 成功提示但服务商无记录 | 通知开关、收件地址、发信通道 |
| 服务商退信或拒收 | 认证、地址、额度和具体错误原因 |
| 已投递但用户看不到 | 垃圾邮件、隔离、收件规则与转发 |
正确区分 From 和 Reply-To
From 表示实际发件身份，应使用发信服务允许并已配置的域名地址。把客户填入的 Gmail 等地址直接当作网站发件人，容易造成认证与身份不一致。Reply-To 可以设置为经过表单验证的客户邮箱，方便工作人员直接回复。
以 Contact Form 7 为例，Mail 面板分别提供收件人、发件人、主题、附加头部和正文设置。按照插件的字段标签规则填写，不要把其他插件的示例标签直接复制进去。更换 SMTP 或邮件 API 后，也要检查它是否强制覆盖发件地址。
核对发信服务与域名认证
确认正在使用哪一条发送通道：主机邮件、SMTP 服务还是邮件 API。核对授权方式、发件域名、服务商要求的地址及配额，密钥只保存在适当的后台配置中。不要把管理密码写进页面代码或文章截图。
按发信服务提供的记录配置 SPF、DKIM 与适用的 DMARC 策略，并检查实际发出邮件的认证结果。DNS 记录应在当前权威 DNS 处修改；只在错误的控制台添加记录不会生效。认证通过有助于识别合法发件，但不能保证每封邮件都进入收件箱。
根据日志缩小范围，不要盲目更换插件
如果表单请求本身失败，查看浏览器请求状态、安全规则、验证码和缓存配置；如果请求成功但发送服务没有记录，检查插件通知开关和发信配置。若服务商已有接收记录，再查看退信、拒收、限额或延迟信息。
服务商显示已投递后，检查收件箱规则、垃圾邮件、隔离区和转发设置。必要时让邮箱管理员按时间及消息标识查找。日志只保留排查所需信息并限制访问，完成后按实际业务的保留规则处理，不能长期公开保存客户询盘。
上线验收要包含真实收件与回复
从桌面与手机各提交一条可识别测试，确认必填校验、错误提示和成功提示符合实际。由收件人确认收到完整字段，并点击回复检查目标是否是测试客户地址；涉及附件时再单独验证附件路径。
把结果记为提交成功、发送被接受、邮件收到和回复目标正确四项。保留故障时的备用联系入口，但只能填写真实可用的渠道。本文提供排查方法，不代表已经替你的网站完成邮件连通测试。
常见问题
一定要安装 SMTP 插件吗？
需要可靠且能核查的发信通道，但不限定一种实现。主机、SMTP 或 API 方案应按实际条件选择，避免多套发信插件互相覆盖。
表单插件会自动保存所有询盘吗？
不同插件和配置不同。应确认是否保存、保存在哪里、谁能访问以及保留多久，不能把邮件失败时仍有备份当成默认能力。
接下来读什么
官方资料与核对依据
资料核对日期：2026年10月23日。界面、版本和服务条件可能变化，执行前请对照正在使用的产品。
