WordPress询盘表单收不到邮件，先找回已保存的询盘，再用同一个业务邮箱对比工具测试信和真实表单信。测试信能到、表单信不到，就先查这张表单的通知设置；两封都不到，再查发送服务和收件端。这样能缩小范围，避免反复重装插件。
WordPress官方文档明确说明，wp_mail()返回成功并不代表用户已经收到邮件。它证明的只是这一层处理没有报告失败。真正完成询盘交付，还要收到完整字段，并能回复给填写表单的人。
先找回线索，再改配置
打开当前表单工具的Entries、提交记录或同类页面，按发生时间查找询盘。已有联系方式和需求时，先交给业务处理，并保留必要记录。不要为了验证故障先删除表单、重装插件，或者清空现有提交。
如果后台没有历史记录，先确认工具是否原本就保存。以Contact Form 7为例，官方说明指出它默认不保存提交消息，可配合Flamingo等存储功能。因此，“没有记录”既不能证明访客没提交，后来安装存储也不能自动补回以前没保存的内容。
接着从公开页面做一次受控测试。用自己控制的邮箱填写，留言加入“邮件排查-产品A-01”这种唯一标记，记下URL、时间、时区和前台反馈。只用测试资料，不需要反复传播真实客户的信息。
如果前台根本不能提交，先处理必填校验、验证码、脚本或请求错误。能够提交后，再看通知和邮件环节。界面颜色、提示文案或某一个通用错误，只能作为线索，具体含义按所用表单工具判断。
两封信发到同一个邮箱，先缩小范围
第一封从现有发信工具的测试入口发送，第二封从网站真实表单提交。尽量用相同收件地址、相近时间，各留不同标记。这能减少“工具测的是自己邮箱，表单发的是业务邮箱”带来的干扰。
已使用WP Mail SMTP时，可以进入“WP Mail SMTP → Tools → Email Test”，填写能够实际查收的地址，发送后同时看测试结果与收件箱。官方测试文档也要求实际确认收件。使用其他工具就沿用对应入口，不必再同时安装另一套接管发信的插件。
| 两封邮件的结果 | 当前优先方向 | 不能直接下的结论 |
|---|---|---|
| 测试信和表单信都没收到 | 查发信连接、服务端日志与收件端 | 不能直接断定表单坏了 |
| 测试信收到，表单信没收到 | 查通知开关、条件、收件人和表单信自身日志 | 不能说SMTP在所有情况下都正常 |
| 两封都收到，但某类真实询盘不来 | 对比附件、产品分流、字段和发生时间 | 不能认定故障已经不存在 |
| 同一消息到一个邮箱，另一邮箱没到 | 查对应地址的拒绝、抑制、转发与过滤 | 不应先反复修改全站SMTP |
工具测试信通常不经过表单的通知条件，邮件头与正文也可能不同。它的作用是缩小问题范围，不是替代表单验收。两条路径都要保留对应消息的时间与标记，后面才能在服务日志里找到同一封信。
To、From和Reply-To分别填什么
最容易导致混乱的，是为了让业务直接回复访客，把访客邮箱填进From。From代表这封通知的发件身份，Reply-To才是点击回复时希望到达的地址。
先确认故障页面使用哪张表单，然后进入它的邮件通知设置：
- Contact Form 7：WordPress后台“联系（Contact）→ 联系表单”，打开对应表单，选择Mail标签。
- Elementor Form：编辑该页面，选中Form部件，在Actions After Submit中确认包含Email，再展开Email设置。入口见Elementor官方Form说明。
两种工具的界面不同，不要在Elementor里寻找CF7的Mail标签。如果页面中有多张表单，先确认自己修改的是发生故障的那一张。
以CF7为例，下面是示意配置。example.com和地址都需要换成自己实际管理、获准发信的身份：
- To：
[email protected] - From：
网站询盘 <[email protected]> - Additional headers：
Reply-To: [your-email]
[your-email]必须对应这张表单真实存在的邮箱字段。如果把字段改名为[contact-email]，邮件映射也需要一起修改。不要把其他表单教程里的占位符原样复制，而不检查自己表单有没有这个字段。
Contact Form 7邮件设置文档解释了这些位置；其发件域名提示要求From使用网站所属域名的地址。这个地址还必须符合你实际发信服务的授权要求，同域名称本身不等于已经获得发送许可。
接着检查通知是否启用、To是否还留着开发者邮箱、是否存在按产品或地区触发的条件。首页表单与产品页表单可能是两张独立配置，修好首页不代表其他表单也生效。
正文中应包含业务需要的联系方式、产品与留言。如果收到通知却缺访客邮箱，仍然没有完成交付。全站SMTP工具若设置了强制From，还要查看最终实际发出的邮件，确认它是否覆盖了表单自己的设置。
测试邮件发不出去，按连接和授权错误处理
先读取当前工具提供的原始错误，而不是随机切换端口和加密选项。WP Mail SMTP的Other SMTP说明列出了连接、身份与认证配置；具体值应来自所用邮件服务商。
| 错误发生在哪一步 | 先查的配置或条件 | 修复后怎样验证 |
|---|---|---|
| 连接超时、无法连接 | 主机能否连接目标服务，服务器地址、端口、加密方式是否匹配官方要求 | 重新发工具测试信，确认连接阶段通过 |
| 身份认证失败 | 用户名、授权密码、OAuth或API凭据、账号是否失效 | 使用服务商要求的认证方式，不把普通登录密码当通用答案 |
| 发件身份未验证或无权使用 | From地址或域名是否已在发送服务中验证 | 保持表单与全站实际发件身份一致 |
| 额度或发送限制 | 当前账户限制、异常流量、服务状态 | 处理明确限制，再测试少量受控邮件 |
| 服务已接受但邮箱没信 | 转入该消息的后续投递与收件排查 | 使用消息ID查询，而非继续改连接参数 |
同一网站尽量让一套明确的发信配置负责邮件路由。多套插件同时接管，或者迁移后旧凭据仍存在，容易让后台看到的设置与真正生效的路径不同。修改前保存原配置，凭据不要放进公开截图或支持工单。
如果只有网站搬到新主机后开始失败，优先对照迁移前后连接、凭据和网络限制；如果密码或授权刚更换，优先查认证。变更时间能帮助缩小范围，比按随机教程安装新插件更有效。
服务显示accepted或delivered，仍要追下一层
不同服务的状态名称并不完全一致，但可以分清几个阶段：发送服务收到请求、消息等待发送、目标服务器接受、后续拒绝或退信、收件人最终在哪个文件夹看到。目标服务器接受邮件，也不代表一定放在主要收件箱。
进入邮件服务的活动记录，按时间、收件人或主题标记搜索，保存Message-ID以及后续状态。没有这条消息时，要先确认查的是正确账户、通道和时间范围；确认仍无记录，再回到网站发信阶段。不要在错误的服务控制台里刷新半天后宣布邮件丢失。
出现退信或拒绝时，按具体错误检查地址、域名政策、附件或其他限制。出现延迟时，记录是否仍在重试；不能把暂时排队当永久失败，也不要不断重复提交同一条询盘，让业务收到一批重复通知。
某个收件地址长期不来，还要看服务是否把它加入抑制列表。以Postmark为例，官方支持文档说明了硬退信及手动抑制等状态。先核实原因和地址是否有效，再按服务规则处理；投诉或退订相关限制不能为了“让它再发一次”就随意解除。
到收件端查过滤，再看实际邮件认证
在业务邮箱中搜索唯一标记，检查垃圾邮件、隔离区、归档、转发和规则。企业邮箱有时把邮件留在管理员隔离区，普通员工的收件箱里看不到。需要管理员协助时，提供收件地址、时间和消息ID，才能定位具体消息。
用实际邮件头核对发件身份
如果能在某个测试邮箱收到，打开该邮件的原始信息。Gmail网页版可以在邮件旁的更多菜单选择“显示原始邮件”，具体步骤见Google邮件头说明。核对实际From、Reply-To和认证结果，而不是只看后台打算发送什么。
SPF用于声明哪些发送来源有权代表相应域发送；DKIM提供可验证签名；DMARC还涉及可见From域与认证身份的对齐及策略。配置应来自实际邮件服务商，不要照抄其他网站的DNS字符串。一个站同时使用企业邮箱和通知服务时，也不能简单新增第二条同名SPF记录；SPF标准对同一名称的多条记录有明确限制，需要按各服务要求整合有效授权。
Google发件者要求区分了普通发件者与大量发件者的要求。对个人Gmail发送邮件，至少要满足适用的认证要求；大量发送还有更严格条件。小型询盘站不必拿群发门槛吓自己，但也不能因为发送量小，就忽略身份认证。
认证通过仍不是收件保证。Google认证说明指出，垃圾发送者也可能使用认证，因此认证只是判定中的一部分。邮件内容、收件策略、转发和地址状态仍可能影响结果。DNS面板里存在一条记录，与这一封信实际通过认证，也是两件事。
只有部分询盘丢失，要比较哪些差异
如果基础测试已经收到，但业务仍报告漏信，找出一条成功和一条失败的可追踪记录，比较页面、表单ID、时间、收件条件与附件。
带附件的表单，应分别提交不带附件和带小型测试附件的消息。关注工具的文件类型与大小要求，以及发送服务和收件端限制。不能因为纯文本测试通过，就假设客户上传大目录也一定成功；也不应为了测试反复发送真实客户文件。
按产品或地区分流时，每个分支都需测试。例如产品A到业务员甲，产品B到业务员乙，只测试A无法发现B仍留着旧邮箱。多语言页面也可能引用不同表单，而不是同一张表单换一段文字。
如果只有同域企业邮箱收不到、外部测试邮箱能收到，除收件规则外，还要让邮件管理员确认当前域的邮件路由与迁移设置。别只根据网站在新主机、邮箱在旧服务的表面关系，擅自修改所有DNS记录；应由具体投递记录定位。
三种记录，怎样推导下一步
下面都是自拟排查情境，用来展示判断过程，不是实际客户日志：
| 观察记录 | 可以缩小到哪里 | 下一步 |
|---|---|---|
| 工具测试信到达；真实表单有存储记录，但发送服务没有对应消息 | 表单留存之后、发送服务之前 | 查通知是否触发、条件是否满足、实际路由到哪个发信账户 |
| 工具测试与表单通知都在服务中被接受；业务邮箱没有，另一测试邮箱收到 | 收件人差异或后续投递 | 查业务地址的退信、隔离、转发和抑制状态 |
| 所有测试正常，只有附带目录的产品B询盘失败 | 特定表单分支或附件条件 | 分别测试B无附件与小附件，核对B收件配置及大小/类型限制 |
第一种结果不能直接说SMTP完全无关，因为表单可能被路由到另一条连接；第二种不能直接说垃圾箱，因为可能是后续拒绝；第三种也不应直接改全站From。每一步结论都只走到证据支持的位置，然后补下一条记录。
向服务商求助前，把两封信并列记下来。下面是可替换的教学填写示例，没有实际发送邮件：
| 记录项 | 工具测试信 | 真实表单信 |
|---|---|---|
| 收件人 | 同一个受控业务邮箱 | 同左 |
| 唯一标记 | mail-check-A01 | form-check-A01 |
| 时间与时区 | 填实际发送时间及UTC偏移 | 填实际提交时间及UTC偏移 |
| 入口 | 当前发信工具的测试页 | 填公开页面URL和表单ID |
| 已知结果 | 例如：实际收到 | 例如：提交已留存，未收到通知 |
| 服务记录 | 填可查到的状态与消息ID | 未找到时写“未找到”，再核对账户、路由与时间范围 |
按这个示例，下一步应由网站维护者检查表单通知与实际发信路由，而不是让收件管理员凭空找一封尚未证明进入服务的信。如果服务已有拒绝代码，再把同一条记录交给对应邮件服务商。
如果服务商另外提供事件ID，也一并保留，不把不同系统的ID混成同一个。工单只需测试记录和必要错误信息，删除无关客户正文，并隐藏密码、API密钥与完整凭据。
修好以后，要测试收件和回复
重新提交一条新的测试询盘，确认前台反馈、按配置应有的留存、业务邮箱字段完整，以及点击回复的目标。真的回复到自己控制的测试邮箱，确认业务人员能够联系到提交者；不要只盯着工具测试信。
有多个收件分支、语言或附件条件，再覆盖对应场景。测试资料清楚标记，按自己的留存规则清理，避免被业务当作真实线索。日志与提交记录含个人数据，应限制访问和保留范围，不能无限制公开或长期堆积。
平时指定人员查看未跟进提交与失败提醒。邮件通知暂时异常时，提交留存能保住一部分需求，但必须有人查看才有作用。更换DNS、邮箱、主机或表单后，重新执行这条最短路径，也可以纳入WordPress建站与维护和上线验收的固定检查。
常见问题
安装SMTP插件就能保证收到邮件吗？
不能。插件负责连接或调用发送服务，表单通知、发件授权、服务状态和收件过滤仍影响结果。安装后需要真实表单收件与回复测试，而不是只看连接成功。
Contact Form 7没有历史记录，还能恢复以前的询盘吗？
先查过去是否启用了Flamingo、其他存储、邮件日志、CRM或转发。如果当时没有任何留存，后来安装插件不会补回旧消息。只能从实际存在的记录继续寻找，不能承诺恢复未保存的数据。
为什么测试邮件收到，表单邮件仍收不到？
测试信通常绕过表单通知条件，From、正文和收件规则也可能不同。检查该表单是否启用通知、字段映射和条件是否成立，再按表单信自己的时间与消息ID追踪，不把测试信的结果当作全路径通过。
多加几个收件邮箱，能避免漏询盘吗？
多收件人可以用于业务分工，但不能替代故障处理。先让主要路径正常，再逐个测试新增地址；不同收件端的过滤与地址状态仍可能不同。更可靠的补充是适当的提交留存、失败提醒和明确的跟进负责人。