詢價表單送出後卻收不到郵件：從 SPF 到表單設定的排查清單
頁面跳出「送出成功」，你把信箱重新整理十遍，一封新的詢價都沒有。這不是玄學。依照我實際排查的順序，從 DNS 裡的 SPF、DKIM、DMARC，一路查到表單 action、SMTP 攔截和垃圾郵件匣，斷點通常就藏在這幾個地方。
重點摘要
- 前端顯示「送出成功」，只證明瀏覽器把請求送了出去，不代表伺服器真的寄了信，更不代表這封信進得了對方的收件匣。
- 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》（我如何靠一則隨機貼文拿到 17 筆專案詢問），參與者包括 /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 等）。
本頁由簡體版機器翻譯，尚待人工審核。