客户说发了询盘你没收到？

客户在邮件里说「上周就填了你们网站的表单」，你翻遍收件箱和垃圾箱都没有，后台也没有记录。这类问题在外贸独立站上并不少见，漏掉一条，就是一条客户在那个时间段里彻底消失。

这篇把询盘从点击提交到进入你收件箱的链路拆成 5 段，每段给出检查动作和常见原因，最后给一张可以照着走的排查顺序表。链路排查的意义在于归因：先确定断在哪一段，再决定改什么，不要在没定位之前换服务器或者重做网站。

直接答案

直接答案：询盘丢失通常断在 5 段中的一段：表单提交环节、站点记录环节、通知邮件发送环节、邮件送达环节、人工处理环节。先用一次真实测试建立基线，记录提交时间、后台出现时间、收件箱到达时间与垃圾箱情况；如果后台有记录而邮件没到，问题在第 3、4 段；如果后台也没有记录，问题在第 1、2 段。多数情况不需要重做网站，只需要把这几段逐一验证一遍。

先看核心结论

1. 先把 5 段分开，再动手改。跳过分段直接换服务器或者重做表单，等于继续猜。
2. 后台必须留记录。只靠邮件通知的站点，邮件一丢询盘就没了，无法追溯。
3. 通知邮件的发件域最好与公司主域一致，认证配置缺失时，邮件更容易被判定为垃圾邮件。
4. 收件箱里没看到不等于没收到，需要在垃圾箱、推广标签和邮箱规则里再确认一次。
5. 修好之后要固定测试节奏，改表单、换服务商、换域名都属于必须复测的变化。

一、先做一次真实测试，建立基线

排查的起点不是看代码，而是自己走一遍完整流程，并且把过程记录下来。四个时间点建议写在同一张纸上。

1. 提交时间。用公司外部邮箱（不要用站内域名的邮箱）提交，填写真实可联系的邮箱与公司名，内容写清楚是测试。
2. 后台出现时间。提交后立刻刷新网站后台的询盘列表，看有没有新增记录，以及记录里是否带来源页面与时间。
3. 收件箱到达时间。看通知邮件几分钟内到达，发件人显示成什么，回复时会回到哪个地址。
4. 垃圾箱与推广标签。同一个邮箱里检查垃圾邮件文件夹、推广标签页，以及邮箱的过滤规则。

有条件的话，请目标市场的一位客户或同事从当地网络再测一次。跨境访问本身会带来延迟与超时，某些提交失败只在特定网络环境下出现，本地测试很难复现。

二、第 1 段：表单有没有真的提交成功

客户以为提交成功，实际请求没有到达服务器，这种情况最常见的表现是「提示一闪而过」。

要确认的四件事：

1. 字段校验是否误伤。邮箱格式校验过严、电话号码强制要求国家码、必填项没有明显标记，都会让客户在反复报错后放弃。
2. 成功反馈是否明确。提交后应当有清晰的提示或跳转到一个结果页面，而不是一个几秒后消失的浮层。反馈不明确，客户会重复提交，也会记错自己到底提交没有。
3. 人机验证是否拦住真人。滑块、图形验证在部分海外网络环境下容易连续失败，拦掉的往往是真实客户，机器人反而少见。
4. 是否有防重复或限流。防重复提交、接口限流设置过紧时，正常的连续提交会被拒绝，而页面提示可能仍然显示成功。

判断方法：打开浏览器开发者工具的网络面板，提交一次，看这条请求的响应状态码与返回内容。状态码是 200 而返回内容里写着校验失败，这种「界面提示成功、接口实际拒绝」的错位是最容易漏掉的一类问题。

三、第 2 段：站点有没有留下记录

这一段的检查动作最简单：提交之后看后台有没有这条记录。

后台有记录，说明数据已经落到你的系统里，问题在后半段链路，可以继续往下查。后台没有记录，就要看记录方式本身：

1. 只发邮件不存记录。部分早期做的站点，表单提交后只给指定邮箱发一封信，不做任何存储。邮件一旦丢失或被误删，这条询盘就彻底找不回来，也无法确认到底收过多少条。
2. 写入失败但仍然提示成功。接口调用的环节出错，页面却按成功处理，用户和业务员都不会发现异常。
3. 记录字段缺失。有记录但没有来源页面、没有提交时间、没有客户填写的原始内容，后续跟进时无法判断客户看的是哪一页、关心哪类产品。

这一段的处理建议是明确的：无论走哪种通知方式，询盘都应落在可以随时回溯的地方，这是后面所有排查的基础。

四、第 3 段：通知邮件有没有发出去

后台有记录，收件箱没有邮件，先确认这封信是被发出去了，还是根本没发。

要核对的五项：

1. 发信方式。是站点服务器直接发信，还是通过第三方发信服务。前者更容易受服务器出口信誉影响。
2. 收件地址写对没有。接手别人搭的站点时，通知邮箱停留在离职同事的地址上，这类情况很常见。
3. 回复地址指向哪里。如果通知邮件的回复地址是系统地址或者无人值守地址，业务员直接点回复，客户就收不到回信，这一条比漏信更隐蔽。
4. 发信记录里有没有失败。看发信服务或服务器日志中的失败条目，记录里通常能看出是超时、被拒收，还是认证不通过。
5. 出口信誉。共享主机或共享 IP 上的其他站点有大量垃圾邮件行为时，你的正常通知也可能被目标邮箱整体拒收。

五、第 4 段：邮件有没有送到收件箱

邮件发出去了，接到的人没看到，问题出在送达判定上。这一段是四个技术项：SPF、DKIM、DMARC 与发件域。

1. SPF。授权发信来源的域名记录，需要包含你实际使用的所有发信渠道。换过发信服务但没更新 SPF，是收不到通知的常见原因。
2. DKIM。给邮件加上签名，用来验证内容在传输中没有被改动。签名域与 From 域不一致时，部分邮箱会降低信任。
3. DMARC。告诉收件方认证失败时怎么处理，最低可以先用只监控不拦截的策略（v=DMARC1; p=none），从报告中观察失败记录。
4. 发件域与公司主域是否一致。用第三方服务的共享域发信，虽然配置简单，但发件人对客户来说是陌生地址，更容易进垃圾箱或者被标记为推广内容。

看一封实际邮件的原始邮件头，能看到这三个认证项各自的结果与判定所用的域。这是最直接的证据，比任何推测都可靠。

外部规则方面有一条值得放在这里：Google 与 Yahoo 自 2024 年 2 月起对批量发信方实施发信人要求，Microsoft 随后在 2025 年 5 月对 Outlook 邮箱跟进同类要求。这些规则针对的是向这些邮箱的用户每天发送量达到 5,000 封及以上的发信方，要求包括同时通过 SPF 与 DKIM 认证、发布 DMARC 记录、认证域与发件域对齐、把用户举报的垃圾投诉率保持在 0.3% 以下（Google 另有低于 0.1% 的建议目标），以及商业邮件支持一键退订。工厂站的询盘通知远达不到这个量级，因此不适用批量发信方的完整要求；但认证配置缺失同样会让邮件更容易被判定成垃圾邮件，这一段检查仍然值得做。具体条款与最新版本以官方文档为准。

六、第 5 段：人的环节

前四段都正常，邮件也确实到了某个收件箱，问题可能出在人和流程上。

1. 通知发给了一个没人看的邮箱。info@ 或 contact@ 由谁负责，如果没有明确到人，就等于没人负责。
2. 只发给一个人。这位同事休假或出差，邮件就堆在那里，等到发现时已经过了客户的决策期。
3. 被当成垃圾邮件手动删除。业务员看到陌生发件人加英文内容，顺手清掉，没有标记为「非垃圾邮件」，下一次同样会被拦。
4. 邮箱规则把询盘分错了文件夹。自动分类规则、转发规则设置不当，邮件其实在，但谁都没看到。
5. 回复环节断裂。客户在等回音，业务员以为客户会再联系，双方都在等，最后谁都没动。

七、5 段排查顺序表

八、修好之后怎么防止再漏

排查一次只解决当下这条链路，真正降低风险的是固定下来的三件事。

1. 双通道留痕。询盘同时落在后台记录和通知邮件里，两边都能查。只有一条通道时，任何一环出问题都会无声无息。
2. 固定测试节奏。改完表单、更换发信服务、换域名、调整邮箱规则之后，各测一次；另外每季度走一遍完整流程，包括垃圾箱检查。
3. 记录测试结果。测试时间、提交所用地区、各环节时长、最终是否到达，简单几行就够。下次出现同类问题时，对比有过记录的状态能快很多。

另外两项成本很低但有效的动作：在提交成功的页面上留一个备用联系方式，避免链路出问题时客户无处可去；给通知邮件设置不止一个收件人，减少单点依赖。这两项都属于独立站获客的基础动作，投入很小，但补上的是整条链路里最脆的一环。

常见问题

问：客户说提交了表单，但我这边什么都没有，怎么回？

答：先请客户提供提交的大致时间与截图，同时自己按本文顺序走一遍测试。两边信息对不上时，往往是客户停留在确认页没有真正提交，或者提交时校验未通过。无论哪种情况，先给对方一个可用的联系方式，不要让沟通断在这里。

问：询盘存在后台了，通知邮件是不是可以不做？

答：不建议取消。后台记录需要有人主动登录查看，通知邮件是把信息推到人面前的那一步。两者互为备份，成本都不高。

问：用个人邮箱接收询盘通知有问题吗？

答：能收到就没问题，但长期看有两个隐患：一是邮箱归属与人员绑定，人员变动时容易断；二是用服务商共享域发信时，发件人对客户来说比较陌生，更容易被判定为推广内容。使用公司域名邮箱更稳。

问：DMARC 是不是必须配置？

答：属于强烈建议的配置。可以先用只监控不拦截的策略观察一段时间，从报告中看有没有异常的认证失败记录，再决定是否收紧。具体配置方式以你的邮箱服务商官方文档为准。

问：为什么本地测试一切正常，客户就是收不到？

答：跨境网络、目标邮箱的判定规则、客户本地的邮箱过滤都在本地测试的覆盖范围之外。请目标市场的联系人代测一次，或者至少从不同网络环境各测一次，能覆盖掉其中一部分。

结论：先分段，再修，最后固定节奏

询盘丢失让人焦虑的地方在于它不可见：客户不会因为你漏了信而再发一次，你也不知道丢了多少条。外贸独立站怎么做的讨论里，注意力大多放在页面和流量上，从表单到收件箱这一段很少有人主动检查。把它拆成 5 段之后，这件事就变成了一组可以逐一验证的检查项。

今天就能做的三步：用外部邮箱提交一次真实询盘并记录四个时间点；检查后台是否留下了记录；看一封实际通知邮件的邮件头，确认三个认证项的结果。剩下的问题，都会在这三步里显露出位置。

适用限制与边界说明：本文说明的是表单与邮件链路的排查顺序，不涉及具体邮箱服务商的配置细节，各家的判定规则与界面会变化，实际操作以对应服务商的官方文档为准。文中不承诺任何送达率或到达时间，送达结果取决于发信配置、发件域信誉与收件方策略。涉及产品功能与可用范围时，以 NEOGRESS 官网公开说明为准。

链路排查解决的是「信有没有到」，内容与页面的部分在另外两篇里接着讲：询盘跟进的流程与分工、上线后没有询盘该先查什么。搭建阶段就把表单与通知链路一起规划，可以少走一遍回头路：外贸网站建设方案里有页面结构与转化路径的对应说明，具体功能与可用范围以官网公开说明为准。

数字来源说明

1. 2024 年 2 月、2025 年 5 月（第五节，发信人要求生效时间）：类别为外部官方政策时间；来源为 Google 与 Yahoo 于 2023 年 10 月联合公布的批量发信方要求（2024 年 2 月起实施），以及 Microsoft 于 2025 年 5 月起对 Outlook 邮箱实施的同类要求。相关说明见 Google 官方公告、Gmail 发信人指南、Yahoo Sender Hub 最佳实践。
2. 每天 5,000 封及以上（第五节，批量发信方的适用阈值）：类别为外部官方政策阈值；口径为向 Gmail 与 Yahoo 用户发送量达到该量级的发信方，按发信域统计。该量级用于界定规则适用范围，工厂站点的询盘通知邮件通常远低于此，因此不适用批量发信方的完整要求。
3. 0.3% 与 0.1%（第五节，垃圾投诉率相关数值）：类别为外部官方政策数值；其中低于 0.3% 属于硬性阈值，低于 0.1% 为 Google 给出的建议目标值，两个数值均针对批量发信方。
4. SPF、DKIM、DMARC、RFC 8058 一键退订（第四、五节，技术项与规范）：类别为技术规范；分别对应 SMTP 与邮件认证相关的公开技术标准，其中一键退订对应 RFC 8058。
5. 5 段、4 个时间点、3 件事（全文，结构性数字）：类别为本文的方法划分，用于组织排查步骤，不代表外部标准规定的数量。
6. 每季度一次、改完即测（第一、八节，测试节奏建议）：类别为运营建议；属于作者基于排查经验的建议做法，不是外部标准，读者可按自身站点更新频率调整。
7. 本文未引用任何外部流量、询盘、成交或转化统计数字，未使用任何客户数据。

数据口径总声明

本文未引用任何外部流量、询盘或成交统计数字，正文不出现此类精确数字；涉及的经验建议已逐条标注，读者应以自身数据为准。