询盘表单提交了但收不到邮件：从 SPF 到表单配置的排查清单
页面弹出「提交成功」，你刷新邮箱十遍，一封新询盘都没有。这不是玄学。按我实际排查的顺序，从 DNS 里的 SPF、DKIM、DMARC，一路查到表单 action、SMTP 拦截和垃圾箱，断点通常就藏在这几处。
Key Takeaways
- 前端提示「提交成功」只证明浏览器把请求发了出去，不代表服务器发了信，更不代表这封信进了对方收件箱。
- SPF、DKIM、DMARC 没配，是自建发信（PHP
mail()之类）最先翻车的一环，也是该最先查的一环。 - 表单 action 指向错误属于「页面看着一切正常、后台其实什么都没发生」，用浏览器 Network 面板几秒就能确认。
- GSC 里站内页面收录 100% 时，别急着再加内容，问题多半在链路末端——表单与邮件，不在 SEO。
表单显示提交成功，为什么邮箱一封都没有？
先把「提交成功」这四个字拆开看。它只是前端给你的一句提示，来源可能是 JavaScript 校验通过、也可能是主题里写死的一行文案，跟「邮件有没有发出去」没有任何必然联系。真正决定你收不收得到询盘的，是后面三层。
第一层是前端。访客点按钮，浏览器把表单数据打包，发往 action 指定的地址。这一层出问题，通常是校验脚本拦住了没给提示、按钮被遮罩挡住、或者提交后跳转失败，访客以为没提交，你自己也不会收到。
第二层是服务端。PHP 收到数据，决定用哪种方式把信发出去：有的是直接调 mail()，走主机自带发信；有的是接 SMTP 账号代发；有的是把询盘写进数据库加发通知。这一层的问题最多，也最隐蔽——因为大多数主题不会把发信失败暴露给访客。
第三层是投递。信从服务器出发，经过对方邮件服务商的判定，最后进收件箱还是垃圾箱，取决于 SPF、DKIM、DMARC 这套身份认证，以及发件域、内容特征、IP 声誉。很多老板到这一步才第一次听说这几个缩写，但它们恰恰是最常见的断点。
这三层里任何一层断了，访客看到的都是同一句「提交成功」，所以只能按顺序一层层证伪。这套顺序我在 技术 SEO 检查清单里也提过：先确认现象能被复现，再定位分层，最后才动手改。
排查该从哪一头开始？我的顺序是什么？
我的顺序是按「证伪速度」排的，能在两分钟内排除的排前面，需要等 DNS 生效、需要翻日志的排后面。
先测一次真实的提交。用一个你能登录的邮箱当收件人，在页面上完整走一遍流程，记下提交时间。测的时候别用同一个域名的邮箱，用 Gmail、Outlook 这类外部邮箱，才能看出跨域投递的真实表现。
接着看表单到底往哪发。打开浏览器开发者工具的 Network 面板，点一次提交，找到那条 POST 请求，看它的目标地址、状态码和响应。如果连请求都没发出去，问题在前端；如果发出去返回 500，问题在服务端；如果返回 200 但邮箱没动静，才轮到 DNS 认证和投递环节。
然后查 DNS 三件套。SPF、DKIM、DMARC 都能用一条 dig 命令看到，不需要登录任何后台。这三个记录缺一个，你的信在对方眼里就是「来路不明」。
再确认发信通道。问主机商要发信日志，或者干脆接一个正经 SMTP 服务，把 mail() 换掉。这一步能把「主机拦截」这个变量彻底摘掉。
最后才去翻垃圾箱和退信。顺序颠倒的话，你会在垃圾箱里找半天，其实信压根没发出去。
SPF、DKIM、DMARC 到底管什么？
用一句话说：这三个记录是给你发出去的信办身份证。对方邮件服务器收到信，会拿这三样核对「这封信是不是真的从你这个域名发出来的」。核不过，轻则进垃圾箱，重则直接被拒收，而且通常不会有任何提示回到你的表单页面。
它们分工不同。SPF 授权哪些服务器可以用你的域名发信；DKIM 用密钥给邮件内容签名，证明中途没被改过；DMARC 则告诉对方，SPF 和 DKIM 都没通过时你希望怎么处理，同时把报告发回给你。三个里缺哪个，判定链条就断一节。
SPF 记录怎么查、怎么写？
查 SPF 就是查这个域名根部的 TXT 记录：dig TXT yourdomain.com +short。正常的记录以 v=spf1 开头，后面跟着授权的发信来源，以 ~all 或 -all 收尾。
我见过最多的两个错误，一是同一个域名下存在两条 SPF 记录，二是记录里的授权来源漏了实际发信的那台机器。两条 SPF 会让对方无法判定，等同于没配；漏掉来源，则等于你亲手把自己列进了未授权名单。
还有一条容易忽略的限制：SPF 记录里的 DNS 查询次数是有限的，塞太多 include 会超限，记录直接失效。授权能精简就精简。
DKIM 没配会怎样？
DKIM 的公钥放在一个特殊子域里，形如 selector._domainkey.yourdomain.com，所以查询时要带上 selector 名。用 dig TXT selector._domainkey.yourdomain.com +short 就能看到公钥。
DKIM 没配，最容易出现的现象是：SPF 明明过了，邮件还是被判可疑。因为 SPF 只验证信封发件人，DKIM 才验证邮件头和正文的完整性。两个都过，才叫对齐。
配 DKIM 时最常见的手误是复制公钥时漏了字符、或者把换行弄丢了。记录本身存在，签名照样验不过。配完一定要用完整的一封测试信回读结果，别只看后台那个「已启用」的绿点。
DMARC 要不要从 p=none 开始？
要。DMARC 记录放在 _dmarc.yourdomain.com，它的策略有三个档：p=none 只观察不拦截，p=quarantine 把可疑信丢垃圾箱，p=reject 直接拒收。
我建议先挂 p=none，并在 rua 里填一个能收报告的邮箱。跑一段时间，报告会告诉你都有谁在拿你的域名发信——有时候你会看到自己根本不认识的发信源。看清楚之后再逐步收紧策略，一步跳到 p=reject，很可能把自家正常的业务邮件也一起拒掉。
反过来说，如果连 p=none 都没有，你既没有防护，也拿不到任何报告，出事时完全瞎。
表单 action 指向错误，怎么快速发现？
这是最容易被忽略、也最容易验证的一类问题。表单的 action 属性决定了数据发去哪里，而它会在很多你意想不到的时刻悄悄变掉：换主题、装表单插件、从测试环境搬到正式环境、甚至页面被缓存后旧版表单还在跑。
发现方法只有一个：真点一次，看请求。打开开发者工具的 Network 面板，提交一遍，找那条 POST。你要确认三件事——目标地址是不是你预期的处理脚本、状态码是不是 2xx、响应体里有没有报错信息。
几个典型症状可以对号入座。如果 POST 发到了一个不存在的路径，状态码会是 404，这条询盘直接丢了。如果发到了旧域名或测试域名，请求可能被跨域策略拦掉，控制台会有报错。如果表单用的是空 action，浏览器会把数据发回当前页面地址，除非页面本身有处理逻辑，否则等于什么都没发生。
还有一种更隐蔽的：表单一提交就整页刷新，看着像成功了，其实是因为没拦住默认行为。
如果你的站是 WordPress 建的，插件与缓存造成的表单行为异常尤其常见，我在 WordPress 插件、索引与内容管理这篇里写过类似的排查思路，可以对照。
SMTP 被主机拦掉，会是什么表现？
很多共享主机默认对 PHP 直接发信做了限制：要么限流，要么干脆禁止，要么把发信端口封了。表现往往不是明确的报错，而是「页面转圈几秒然后成功提示」，但信根本没出去。
判断方法有几个。第一，看主机控制面板里的发信或退信日志，正规主机都会留记录。第二，临时把收件人换成你自己的外部邮箱，多测几次，看有没有稳定的到达率。第三，直接接一个独立 SMTP 服务，用 465 或 587 端口发信，把主机自带发信这个变量摘掉。
为什么推荐直接换 SMTP，而不是在主机上折腾？因为主机发信一旦出问题，你很难拿到完整的投递反馈。独立 SMTP 服务通常提供发送日志和退信原因，出了问题能直接定位。对询盘这种「丢一封就是丢一个客户」的场景，这点可观测性值回票价。
换完之后别忘了回头验证 SPF：新的 SMTP 服务商也需要被加进你的 SPF 授权列表，否则你把发信通道换好了，认证那一环反而又断了。
这套「先保证通道可观测、再优化内容」的思路，和做 B2B 长成交周期的内容与询盘是一回事：链路没打通之前，加内容只是增加分母。
邮件确实发出去了，为什么进垃圾箱？
确认信发出去了、SMTP 日志里有记录，但对方收件箱里没有，那就进入垃圾判定的范畴。这时候要查的不再是「发没发」，而是「像不像正经邮件」。
先查发件域对齐。很多站的 From 地址写的是 info@你的域名，但实际发信服务器走的是第三方，SPF 授权的是第三方的域。这种「显示发件人」和「实际发信人」不一致，是垃圾判定的高频触发项。最省事的做法是让发件域、SPF 授权域、DKIM 签名域三者保持一致。
再查内容特征。整封信只有一张大图、正文里塞满短链、标题用全大写加感叹号、附件是 .zip，这些都会拉高可疑分。询盘通知邮件本来就该是纯文本加一两个链接，没必要做成一封营销邮件。
还要查 IP 声誉。如果用的是共享主机或共享 SMTP，同 IP 上别人的发信行为会牵连到你。这种情况下换独立发信通道，往往比调内容更有效。
最后一步别偷懒：把发件地址加进收件方白名单，先确认「正常投递」这条路是通的，再去解决「被判垃圾」的问题。两件事混在一起查，会绕很久。
想系统看哪些邮件到了、哪些没到，光靠人工刷新邮箱不够。把询盘事件接进分析工具，和流量数据对起来看，能更快发现「有人来了但没留下询盘」，具体方法见 GA4 自然流量分析。
GSC 收录 100% 还没询盘，说明什么？
这是我实测里反复确认的一条判断：当 Google Search Console 显示站内页面收录 100% 时，问题通常不在 SEO，而在链路末端——也就是表单和邮件。
为什么这么说？因为收录 100% 意味着爬取、索引这条上游链路是通的，页面能被搜到、能被人点进来。流量有了、页面也正常，询盘却没有，那漏斗只可能断在最后一步：访客想联系你，但表单没把消息送到你手上。
这个结论的价值在于止损：没询盘时先把表单和邮件这条链路做一次端到端验证，再谈拉流量，否则等于往一个末端漏水的桶里加水。
怎么验证？用外部邮箱做一次真实提交，确认收到；再检查 GSC 的收录与点击数据，确认上游没塌；然后用 GSC 的 SEO 诊断方法排除搜索侧问题。两边都干净，问题就锁定在表单这一环了。
流量涨了、询盘却没涨，是同一类问题的另一种表现，我在 流量涨了询盘没涨的排查里把这种情况拆得更细，可以接着看。
顺便说一句，询盘这件事值得被认真数。Reddit 上有一篇公开讨论，原帖题名《How I got 17 project inquiries from a random tweet》，参与者包括 /u/rufusdenne、/u/dcedrych、/u/HawkofDarkness 等。来自 Reddit 公开讨论的这个题名本身就提醒人：询盘是可以被明确数出来的数字，不是模糊的「感觉最近咨询还行」。数不出来，就没法判断表单到底漏了多少。
一份可照抄的排查清单
把上面的步骤压成一张表，建议按顺序走，不要跳步。每一步都设有通过标准，达不到就停在这一步修，不要往下猜。
| 顺序 | 检查项 | 怎么验 | 通过标准 |
|---|---|---|---|
| 1 | 真实提交 | 用外部邮箱（Gmail/Outlook）完整走一遍表单 | 提交后能收到通知信 |
| 2 | 表单 action | 开发者工具 Network 面板看 POST 目标与状态码 | 目标是预期处理脚本，状态码 2xx |
| 3 | SPF | dig TXT 你的域名 +short |
恰好一条 v=spf1，含实际发信来源 |
| 4 | DKIM | dig TXT selector._domainkey.你的域名 +short |
能查到公钥，且签名验证通过 |
| 5 | DMARC | dig TXT _dmarc.你的域名 +short |
有记录，rua 指向能收报告的邮箱 |
| 6 | 发信通道 | 查主机发信日志，或换独立 SMTP（465/587） | 有完整发送与退信记录 |
| 7 | 垃圾箱 | 把发件地址加入白名单后再测一次 | 能进收件箱，而非垃圾箱 |
| 8 | 数据闭环 | 把表单事件接进分析工具，和流量对看 | 能看到「到访—提交—收到」的对应关系 |
这张表里的每一项都只需要十几分钟，但顺序不能乱。先查 DNS 再去翻垃圾箱，是最常见的无效路径。
修好之后，该盯哪几个指标？
修好不等于结束，得让它一直能被监控。我盯三件事：表单提交次数、实际收到邮件数、两者之间的差。正常情况下这两个数字应该基本相等，一旦开始分叉，说明认证或通道又出了问题。
如果表单是自建的，可以把提交事件推给 GA4，和自然流量放在一张图里看。链接怎么布、事件怎么设计，可以参考站内这篇 GA4 自然流量与转化分析。如果你还想让表单本身的语义更清楚，给页面加上结构化数据会有帮助，思路见 结构化数据与 AI 搜索。
另外，把「询盘链路是否通畅」写进定期检查项。改主题、换插件、迁服务器、换 SMTP 之后，都重新跑一遍上面那张表。表单的坏法总是悄无声息的，它不会主动告诉你它坏了。
最后，如果你自己是做服务的，别只在自己的站上跑这套检查。客户站的询盘表单同样值得在交付前验一遍，一个收不到信的表单，会把前面所有 SEO 工作都变成白做。想先看看别人怎么写这类排查记录，可以从 研究文章列表进；想直接说你的情况，联系页里的表单就是上面这套流程的实践样本——它要是也收不到信，我大概会先怀疑 SPF。
常见问题
表单提示成功，但垃圾箱里也没有，信去哪了？
大概率根本没发出去。前端提示只代表请求提交了，服务端发信失败时通常不会回传错误给访客。先去主机或 SMTP 服务的发送日志里查有没有这封信的记录，没有记录就是卡在服务端。
SPF、DKIM、DMARC 三个都要配吗？
要。三者分工不同：SPF 管授权，DKIM 管签名，DMARC 管策略和报告。只配其中一两个，判定链条不完整，邮件仍可能被判可疑。成本很低，没有理由省。
换了 SMTP 服务，为什么邮件还是进垃圾箱？
先检查新服务的发信服务器有没有被加进 SPF 授权列表，以及 From 域和签名域是否一致。通道换了、认证没跟着改，是最常见的原因。
用 WordPress 表单插件能避免这些问题吗？
插件只解决「怎么发」，不解决「发的身份对不对」。它能把表单接上 SMTP，但 SPF、DKIM、DMARC 还是得你去 DNS 里配。插件装好只算完成了一半。
怎么确认表单没在悄悄丢询盘？
把表单提交事件接进分析工具，定期用外部邮箱做真实提交测试。盯住「提交次数」和「实际收到数」两个数字，一旦分叉就按上面的清单从头查一遍。
信息来源＝实测：tianwenseo 内容库中的表单邮件丢失排查记录（常见根因：SPF/DKIM/DMARC 未配、表单 action 指向错误、SMTP 被拦、邮件进垃圾箱；GSC 侧：站内收录 100% 时问题常在链路末端即表单与邮件，而非 SEO）；公开资料：Reddit 公开讨论帖《How I got 17 project inquiries from a random tweet》（参与者 /u/rufusdenne、/u/dcedrych、/u/HawkofDarkness 等）。
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “表单提示成功，但垃圾箱里也没有，信去哪了？”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “大概率根本没发出去。前端提示只代表请求提交了，服务端发信失败时通常不会把错误回传给访客。先去主机或 SMTP 服务的发送日志里查有没有这封信的记录，没有记录就是卡在服务端。”
}
},
{
“@type”: “Question”,
“name”: “SPF、DKIM、DMARC 三个都要配吗？”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “要。三者分工不同：SPF 管授权，DKIM 管签名，DMARC 管策略和报告。只配其中一两个，判定链条不完整，邮件仍可能被判可疑。成本很低，没有理由省。”
}
},
{
“@type”: “Question”,
“name”: “换了 SMTP 服务，为什么邮件还是进垃圾箱？”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “先检查新服务的发信服务器有没有被加进 SPF 授权列表，以及 From 域和签名域是否一致。通道换了、认证没跟着改，是最常见的原因。”
}
},
{
“@type”: “Question”,
“name”: “用 WordPress 表单插件能避免这些问题吗？”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “插件只解决怎么发，不解决发的身份对不对。它能把表单接上 SMTP，但 SPF、DKIM、DMARC 还是得自己去 DNS 里配。插件装好只算完成了一半。”
}
},
{
“@type”: “Question”,
“name”: “怎么确认表单没在悄悄丢询盘？”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “把表单提交事件接进分析工具，并定期用外部邮箱做真实提交测试。盯住提交次数与实际收到数两个数字，一旦分叉就按排查清单从头查一遍。”
}
}
]
}
