Defaults.Exposed › 修復 › Guides
聯繫表單郵件進垃圾箱——Web 伺服器發件的修復方法（2026）
發布於 2026-07-08
資料截至 2026-06-29 · 方法論 v7。 基於 261 百萬個已評分網域的彙總普查資料。參見我們如何評分。
聯繫表單和網站郵件之所以落進垃圾箱，是因為你的 Web 伺服器以未驗證的方式發送它們——沒有 SPF 授權，沒有 DKIM 簽名。可靠的修法是讓這些郵件經由驗證 SMTP 發送，而不是把伺服器加進白名單。在 Defaults.Exposed 普查（資料截至 2026-06-29）的 261,086,232 個已評分網域中，46.4% 根本沒有發布 SPF 記錄。
修復順序很重要，而大多數教程把順序搞反了。先執行免費掃描，看你的網域實際發布了什麼；讓網站郵件經由驗證 SMTP（你的郵箱服務商或事務性郵件服務）發送，從而獲得真正的 DKIM 簽名；修正表單的 From 位址；把伺服器 IP 加進 SPF 只能是最後的手段。
為什麼我網站發出的郵件會進垃圾箱？
因為真正發送它們的是誰。當訪客提交你的聯繫表單時，那封郵件並不是由你的郵件服務商發出的——是 Web 伺服器自己生成的，通常經由 PHP 的 mail()。在接收方看來，這封郵件：
- 來自一個你的 SPF 記錄沒有授權的 IP（你的 SPF 覆蓋的是郵件服務商，不是虚拟主機）；
- 沒有任何 DKIM 簽名，沒有任何密碼學證據把它和你的網域綁在一起；
- 常常從一個共享主機 IP 發出，其信誉由几百個陌生人的網站共同決定。
來自混杂信誉 IP 的未驗證郵件，正是垃圾郵件過滤器存在的意義——Gmail 和 Outlook 看到的是一台隨便什麼伺服器聲稱是你。整體基線相當惨淡：46.4% 的網域完全沒有發布 SPF，而在 261,086,232 個已評分網域中只有 10.59%（27,640,987 個，普查截至 2026-06-29）強制執行 DMARC 政策。
為什麼 WordPress 網站尤其中招？
WordPress 發出的所有郵件——表單通知、密碼重置、訂單確認——都走同一個函數 wp_mail()，而它默認封装的是 Web 伺服器上的 PHP mail()。每一個沒有刻意重新設定過的 WordPress 網站，出厂狀態就是一個未驗證發送方。表單插件（Contact Form 7、WPForms、Gravity Forms）全都把郵件交給同一個函數：看上去像插件問題，實質是傳輸問題。
修法不是換一個表單插件，而是装一個 SMTP 插件（WP Mail SMTP 及其同類），把 wp_mail() 發出的一切改道到一個真實的、經過驗證的郵件帳戶——你的 SPF 本來就授權的基礎設施，還附帶 DKIM 簽名。
網站應該用哪種發送方式？
| 發送方式 | SPF | DKIM | 遷移主機後還能用嗎？ | 結論 |
|---|---|---|---|---|
Web 伺服器上的 PHP mail() / 默認 wp_mail() | 失敗 | 无 | 不適用——在哪兒都是壞的 | 這是問題本身，不是選項 |
| 經由郵箱服務商的驗證 SMTP（Google Workspace、Microsoft 365 等） | 通過 | 有簽名 | 能——與主機无關 | 大多數網站的修法 |
| 已驗證網域的事務性郵件服務（SES、Postmark、Brevo 等） | 通過 | 有簽名 | 能 | 大量發送場景的修法（電商、大型表單） |
| 把 Web 伺服器 IP 加進你的 SPF 記錄 | 通過（僅 SPF） | 无 | 不能——IP 一變就悄悄失效 | 僅作退路——見下文 |
每天只有几封通知的話，經由你已經在付費的郵箱走 SMTP 是最短路径；真到了量大的時候，事務性服務就是為此而生。兩者都給你 DKIM——而加 IP 白名單這條捷径永遠給不了。
聯繫表單郵件的送達問題怎麼修？
- 動手之前先在 defaults.exposed 執行免費掃描。 它顯示你的網域實際發布了怎樣的 SPF、DKIM 和 DMARC——你要修的是表單的傳輸、缺失的記錄，還是兩者都要。完全沒有 SPF？先看如何修復 SPF。
- 為網站建立專用的 SMTP 身份——例如在郵箱服務商處建一個
[email protected]，或在事務性服務中驗證一個發送網域。使用可隨時吊銷的應用專用密碼或 API 金鑰，別用某個人的郵箱密碼。 - 讓網站郵件經由它發送。 WordPress：安装 SMTP 插件並指向該帳戶。其他技术栈：設定框架自帶的郵件發送器，替代本地
mail()。 - 修正 From 位址（見下面的反模式）：From 必須是你自己的網域；訪客放進 Reply-To。
- 如果發送方是事務性服務，新增它的 DKIM 記錄（通常是一對 CNAME），讓郵件以你的網域簽名——DNS 步驟與 SPF 設定逐步教程如出一辙。
- 提交一次測試並重新掃描。 郵件標头應對你的網域顯示
spf=pass和dkim=pass；然後經由修復 SPF 和修復 DKIM 清掉掃描標出的其余問題。
為什麼表單在用訪客的郵箱位址當發件人？
這是表單設定中最常見的自伤，很多插件過去還默認這麼干：通知郵件以 From: 訪客的位址送達，好讓你直接點回復。感覺很方便，但這就是偽造。你的伺服器无權以 [email protected] 的名義發信——它對 gmail.com 的 SPF 和 DKIM 都會失敗，而 Gmail 的 DMARC 政策會告訴接收方把它扔進垃圾箱或直接拒收。修復零成本：
- **From：**你自己網域下的位址（第 2 步的那個 SMTP 身份）
- **Reply-To：**訪客的位址——回復照樣直達對方
每個主流表單插件都支援；就是通知設定裡的兩個字段。
為什麼不干脆把伺服器 IP 加進我的 SPF 記錄？
這是多數論坛帖子第一時間想到的修法，而它之所以只是退路，是有原因的。把 ip4:<server>（或指向虚拟主機的 a 機制）加進 SPF 確實能讓裸檢查通過——但是：
- 在共享主機上，你授權的是陌生人。 那個 IP 屬於那台機器，不屬於你；同一台伺服器上的其他所有網站現在都能以你的網域發出 SPF 通過的郵件。
- 它會悄悄失效。 主機商遷伺服器、換 IP 不會通知你；你的 SPF 會繼續授權一個你几個月前就离開的位址。
- 它給不了你 DKIM。 僅有 SPF 在轉發場景下會失效，也无法像簽名那樣支撑你走向 DMARC 強制執行。
把這條路留給真正受限的場景：一台你自己掌控、静態 IP 的獨立伺服器，加上一個不會說 SMTP 的應用——並且尽可能在這台機器上配好 DKIM 簽名。
SPF 檢查的到底是不是表單填進“From”的那個位址？
不是——一半的 DIY 診斷都栽在這裡。接收方評估 SPF 依據的是 Return-Path（RFC5321.MailFrom）網域，而不是 From 標头。Web 伺服器常常把自己的主機名蓋進 Return-Path，於是你的 SPF 記錄根本沒被查詢過——接收方查的是 srv0421.examplehost.com 的 SPF。驗證 SMTP 連這個也一並修好：Return-Path 變成你的網域，SPF 的通過終於算在你头上。這也是 DKIM 重要的原因——DMARC 對齊需要一個與 From 網域綁定的通過結果，而 DKIM 簽名是隨郵件一起走的。
常見問題
SMTP 插件能不能把密碼重置和 WooCommerce 郵件也一起修好？
能。WordPress 上一切都流經 wp_mail()，所以改道一次就把表單通知、密碼重置和訂單郵件全修了。
用了 SMTP 插件，還需要 SPF 和 DKIM 記錄嗎？ 需要——插件改變的是哪套基礎設施替你發信；記錄才是授權它的東西。如果你的網域屬於 261,086,232 個已評分網域中沒有 SPF 記錄的那 46.4%（普查，2026-06-29），單靠驗證 SMTP 救不了你。新網域郵件清單覆蓋了完整的記錄集合。
我的表單郵件 SPF 通過了，DMARC 却還是失敗——為什麼？ 几乎總是上面那個 From 偽造反模式，或者 SPF 通過的是主機商的 Return-Path 網域而不是你的。先修 From/Reply-To；還失敗的話，缺的就是一個對齊的 DKIM 簽名——見“DKIM signature not valid”。如果網站之外的 SaaS 工具也在失敗，SaaS 工具 SPF 失敗指南讲了修復順序。
為一個低流量的聯繫表單折腾這些值得嗎？ 表單通常正是钱進來的地方——一條漏掉的咨詢就是一個你永遠不知道自己失去了的客戶。而且修復是免費的；門槛只在於知道那個未驗證的發送方一直就是 Web 伺服器。
把報告發給站主
如果你是來修這個問題的開發者或外包承包商：測試提交通過後，重新執行免費掃描，把評分報告轉發給網站的所有者——一份帶日期、直白語言的記錄，證明該網域的郵件驗證已經正確，也是下一次網路保險續保或客戶安全問卷時用得上的凭證。如果你是因為咨詢突然不再送達而讀到這裡的站主：把這個頁面和你的掃描報告發給管你網站的人——一個下午就能修完，還附帶一份能給你看的前後對比。
檢查你的網域 → · SaaS 工具的 SPF 在失敗？→ · 修復 SPF → · 我們如何評分 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。