官網表單通知信收不到：SPF、DKIM、DMARC 一次設對

有一種客訴最讓老闆心涼：客戶打電話來問「我上禮拜在你們網站填了詢問單，怎麼都沒人回？」你翻遍信箱找不到那封信，最後在垃圾信匣裡撈出來，上面標著三天前的時間。或者反過來——訂單成立了，系統寄了確認信，客戶說沒收到，你又得手動補寄一次。

絕大多數中小企業會把這件事歸咎於「信箱不穩」，然後就算了。但實際上，官網寄出去的信進不了收件匣，九成以上不是意外，是網域驗證沒設定。Google、Microsoft、Yahoo 這幾年把驗證門檻拉高了不少——Gmail 與 Yahoo 從 2024 年起對大量寄件者明文要求 SPF、DKIM 與 DMARC 三項齊備，一般小量寄件雖然沒被硬性要求，但沒設定的信件被降權、被丟進垃圾信匣的機率明顯提高。這篇把這三個看起來很工程師的名詞講成老闆聽得懂的話，並且給出可以直接照做的順序。

Photo by Tasha Kostyuk on Unsplash

一、先分清楚：「信寄不到」其實有三種狀況

在動手改設定之前，要先確認你遇到的是哪一種，因為解法完全不同。

第一種，信根本沒寄出去。表單送出後畫面顯示「感謝您的來信」，但伺服器那一端寄信失敗了，前端卻沒有接到錯誤。這在用主機內建 PHP mail() 函式的 WordPress 網站上很常見——主機商為了防濫用把寄信功能關掉，或是每小時有寄送上限。判斷方式：去伺服器的郵件日誌或外掛的寄信紀錄看有沒有那一筆。

第二種，寄出去了，但被收件端擋在門外。對方的郵件伺服器直接退信（bounce），你的信箱會收到一封退信通知，裡面有代碼，例如 550 5.7.26 這類與驗證失敗有關的訊息。

第三種，寄到了，但被丟進垃圾信匣。這是最麻煩的，因為兩邊都沒有錯誤訊息，你以為寄成功、客戶以為你沒回。本篇要處理的主要就是第二種與第三種。

二、問題的根源：你的網站正在「冒充」你自己

電子郵件這套協定是 1980 年代設計的，當初完全沒有防偽冒的概念。任何一台伺服器都可以宣稱自己是 service@你的網域.com.tw 寄信出去，就像任何人都可以在信封上寫別人的寄件地址。

所以你的官網放在 A 主機、公司信箱用的是 Google Workspace 或中華電信的信箱服務，當網站用 service@你的網域 當寄件人寄出詢問單通知時，收件方看到的是：一封自稱來自你網域的信，卻從一台跟你網域毫無關係的主機寄出。在收件端的演算法眼中，這個特徵跟詐騙信一模一樣。

更糟的是另一個常見錯誤：很多表單外掛預設把寄件人設成填表客戶的 email，方便你按「回覆」就能回信。這等於用你的主機去冒充 gmail.com、yahoo.com.tw 寄信，是最容易被擋的一種寫法。正確做法是寄件人固定用自己的網域，把客戶的信箱放在「回覆地址」（Reply-To）欄位，按回覆一樣會回到客戶那裡。

Photo by FlyD on Unsplash

三、三把鎖各自在擋什麼

SPF、DKIM、DMARC 是三個互補的機制，全部都是加在網域 DNS 上的設定，不需要改網站程式碼。用寄一封實體掛號信來比喻的話：

SPF（寄件伺服器白名單）——你在 DNS 上公告一份名單：「只有這幾台伺服器，有資格用我的網域寄信」。收件端收到信，看一下來源 IP 在不在名單上。這就像郵局門口貼公告說「本公司只會從這三個地點寄件」。一筆 TXT 記錄寫在網域根目錄，內容類似 v=spf1 include:_spf.google.com include:寄信服務商 ~all。

SPF 有兩個常見地雷。其一，一個網域只能有一筆 SPF 記錄，如果你先後加了 Google 一筆、電子報服務一筆，兩筆並存等於兩筆都失效，必須合併成一行。其二，SPF 有「最多 10 次 DNS 查詢」的上限，include 疊太多會整筆判定失敗。

DKIM（數位簽章）——寄信時，伺服器用一把只有你知道的私鑰在信件標頭上蓋一個電子章；你把對應的公鑰放在 DNS 上。收件端拿公鑰驗章，對得起來就代表這封信中途沒被竄改、而且確實出自有授權的系統。它比 SPF 強在：就算信被轉寄過，簽章依然有效。

DMARC（驗不過的時候怎麼辦）——前兩個只負責「驗」，沒說「驗不過要做什麼」。DMARC 補上這塊，同時要求驗證通過的網域必須跟客戶眼睛看到的寄件人網域一致（業界稱為 alignment，對齊）。這點很重要：有些寄信服務預設用自家網域簽章，SPF 和 DKIM 都「通過」，但跟你的 From 網域對不起來，DMARC 一樣不算數。

DMARC 的政策有三段：p=none（只觀察、只寄報告，不做處置）、p=quarantine（可疑的丟垃圾信匣）、p=reject（直接退回）。實務上的順序是先掛 p=none 蒐集一到兩個月報告，確認所有合法的寄信來源都設定好了，再逐步收緊。一上來就設 p=reject，很可能把自己公司的電子報、報價系統、ERP 通知信一起擋掉。

四、比起自己調設定，更根本的一步

設定 DNS 只解決「身分」問題，還有一個「信譽」問題：如果你的網站跟其他幾百個網站共用一台虛擬主機，那台主機的 IP 信譽是所有人共業，隔壁的購物網站被檢舉發垃圾信，你的詢問單通知也會一起被降權。

所以比較穩的做法是讓網站不要自己寄信，改用專門的寄信服務（SMTP relay 或 API）。Google Workspace 的 SMTP relay、Amazon SES、SendGrid、Mailgun、Brevo 都屬於這類，多數對小量寄送有免費或低價方案，一個月幾千封通常不是成本問題。它們的價值在三件事：IP 信譽是專業維護的、DKIM 簽章由服務商幫你處理好、而且每一封信的投遞結果（送達、退信、開信）都有紀錄可查。

對 WordPress 網站來說，這件事等於裝一個 SMTP 外掛把寄信改接到服務商；對客製化系統來說，是把寄信函式換成服務商的 SDK 或 SMTP 設定。兩者都屬於一次性工程，後續維運成本很低。

Photo by Jakub Żerdzicki on Unsplash

五、照這個順序做，一個下午可以收尾

第一步，盤點寄信來源。把所有會用你網域寄信的系統列出來：公司信箱、官網表單、電商訂單通知、電子報平台、金流串接的通知、客服系統。漏掉任何一個，之後收緊政策時就會出事。

第二步，把官網寄信改接 SMTP 服務商，並在服務商後台完成網域驗證（通常是加幾筆 CNAME 或 TXT）。

第三步，合併 SPF 成單獨一筆，把所有來源的 include 收進同一行，結尾建議用 ~all（軟性失敗）而不是一開始就 -all。

第四步，確認每個來源都有 DKIM，各服務商會給你各自的 selector 與公鑰，一個一個加上去。

第五步，加上 DMARC，先用 p=none，並在 rua= 填一個收得到報告的信箱。報告是 XML 檔，可以丟給免費的 DMARC 報告解析服務看圖表。

第六步，自我檢測。最簡單的方式是用 mail-tester 這類網站：它給你一個一次性信箱，你從官網表單實際送一封過去，它會回一個 10 分制的分數與逐項診斷。MXToolbox 可以單獨查 SPF、DKIM、DMARC 記錄是否正確；如果你的收件人以 Gmail 為主，Google Postmaster Tools 能看到自家網域在 Gmail 眼中的信譽走勢。

第七步，觀察一到兩個月再收緊到 p=quarantine，確認沒有誤傷，再視情況考慮 p=reject。

六、幾個常見誤區

「我信箱用 Gmail，應該沒問題吧？」公司信箱用 Google Workspace 只代表 Google 那條線設好了，官網自己寄出的信是另一條路徑，兩者互不相干。

「加了 SPF 就夠了吧？」SPF 在信件被轉寄時會失效，而且只驗「哪台機器寄的」，不驗「內容有沒有被改」。現在主流收件端普遍更看重 DKIM 與 DMARC 對齊，只做 SPF 的保護力有限。

「加了設定為什麼還是進垃圾信匣？」驗證只是門票，不是保證。內容本身也會被評分：整封信只有一張大圖沒有文字、標題出現過多驚嘆號與「免費」「限時」、內文塞滿縮網址、或是名單裡有大量無效信箱造成高退信率，都會拉低信譽。行銷信還要附上可用的取消訂閱連結。

「表單通知信只有我自己收，不用管吧？」那更要管——因為收件人是你自己，出問題時沒有人會通知你，商機就這樣安靜地掉在垃圾信匣裡。合理的做法是表單同時寫進資料庫或後台清單，信件只當通知，這樣即使信掉了也追得回來。

結語：這是成本最低、回報最直接的一次設定

官網轉換率的討論通常集中在版面、文案、按鈕顏色，但在那之前有一個更基本的前提：客戶願意填的表單，內容真的要送得到你手上。花好幾萬投廣告把人帶進來、辛苦優化表單把填寫率拉高，結果通知信躺在垃圾信匣裡，這是最不划算的漏水點。

建議今天就做兩件事：第一，從自己官網的表單送一封測試信到公司信箱與一個 Gmail，看看進的是收件匣還是垃圾信匣；第二，去查一下自己的網域有沒有 DMARC 記錄。這兩件事加起來十分鐘，但足以判斷你是不是正在安靜地漏掉詢問單。