多數人以為 WordPress 收不到信，是因為沒裝 SMTP 外掛或設定沒弄對，把外掛裝上去、寄一封測試信，看到後台跳出寄送成功，就以為問題解決了。但不少人接下來遇到的情況是，測試信確實收到了，表單通知信、WooCommerce 訂單信、忘記密碼信卻依然不見蹤影，而且往往只有其中一兩種信件出問題，不是整個網站的寄信功能都壞掉。
會出現這種落差，是因為「後台顯示已送出」跟「對方真的收到」完全是兩件事——網站這端能證明的，頂多是寄信程序處理過程沒有出錯，收件端最後判定要不要放進收件匣，還要看 DNS 上的一整套身分驗證有沒有過關。先分清楚一封信是根本沒被觸發、還是觸發了卻在半路被擋下來，才不會把力氣全部花在重灌 SMTP 外掛，卻始終沒抓到問題真正出在哪一步。
從最前面這個「有沒有送出」跟「有沒有收到」的分界開始看起，才看得清楚問題卡在哪一段。
通知信真的觸發了，收件匣卻沒有出現
遇到 WordPress 收不到信，大多數人的直覺反應是網站的寄信功能整個壞掉了，但實際回報的案例通常不是這樣。多半只是特定類型的通知信出問題，像是表單送出後的通知信、WooCommerce 訂單成立信、忘記密碼信這三種最常被拿出來抱怨，其他信件反而正常。這個現象背後藏著一個容易被忽略的判斷習慣，遇到問題先確認的不是有沒有收到，而是有沒有送出，這兩件事完全不同，也是後面所有排查步驟的起點。
wp_mail() 回傳成功，不代表對方的信箱收到
WordPress 核心用來寄信的函式是 wp_mail()，很多外掛在畫面上顯示寄送成功，其實只是這個函式回傳了 true。WordPress 官方開發文件明白寫著，一個 true 的回傳值並不代表使用者真的收到了這封信，它只代表寄信程序在處理這個請求的過程中沒有出錯。換句話說，外掛看到的是 PHPMailer 把信件組好、交出去這一段流程有沒有出錯，跟對方的信箱伺服器最後判定要不要收下這封信，是完全不同的兩件事。
這代表「外掛顯示寄送成功」本身能證明的東西，其實比多數人以為的少很多。它只能證明網站這一端把信丟出去的動作沒有出錯，完全無法保證對方的郵件伺服器願意收下這封信、放進收件匣，還是判定為可疑來源直接丟進垃圾信匣或退回。很多排查文章看到這個成功訊息就結案，反而是最容易誤判的地方，真正該問的問題是這封信離開網站之後去了哪裡。
表單通知、訂單信和密碼信，各自從不同的程式路徑觸發
這三種最常出問題的信，其實各自來自完全不同的程式路徑，修好其中一種不代表其他兩種也一起被修好。WooCommerce 官方文件指出，WooCommerce 會針對自己的交易型信件，像是訂單成立、出貨通知這類跟訂單狀態綁在一起的信，自動記錄每一次寄送嘗試到一個叫做 transactional-emails 的專屬記錄來源。但這份記錄只涵蓋 WooCommerce 自己觸發的信件，官方文件也特別提醒，WordPress 的忘記密碼信與其他 WordPress 管理信件可能不會出現在這份記錄裡，得另外用別的方式查。
表單外掛的路徑又不一樣。多數聯絡表單類外掛是在訪客按下送出的那一刻，直接呼叫 wp_mail() 把通知信送出去，跟 WooCommerce 靠訂單狀態變更去觸發信件是兩條完全不相干的程式路徑。也因為路徑不同，同一台主機、同一組 SMTP 設定，完全可能出現表單通知信正常、訂單信卻失敗的情況，或者反過來。搞清楚眼前收不到的是哪一種信、它走的是哪條路徑，才知道接下來該去哪裡查記錄，不必三種信件混在一起亂猜。
從記錄檔查證觸發動作是否真的送出信件
多數台灣的教學文章遇到收不到信，第一個動作就是叫讀者裝 SMTP 外掛，但這其實跳過了最關鍵的一步，先看記錄檔，搞清楚問題出在寄送前還是寄送後。網站其實留了三層記錄，從 WooCommerce 自己的記錄、WordPress 核心的記錄，一路到主機端的寄信記錄，依序查下去就能分辨這封信是根本沒被觸發，還是觸發了卻沒送達。
WooCommerce 記錄裡的已送出、失敗、停用與略過
要查 WooCommerce 相關的信件，先觸發一次測試訂單或測試通知，再到 WooCommerce > Status > Logs 裡找 transactional-emails 這個記錄來源。WooCommerce 官方文件說明，這裡會看到四種結果，Sent 代表 WooCommerce 已經成功把信交給主機的寄信系統，記錄層級是 INFO；Failed 代表 WooCommerce 嘗試寄送，但主機的寄信程序回傳了錯誤，記錄層級是 WARNING，通常還會附上失敗原因；Disabled 代表這種信件類型在 WooCommerce > Settings > Emails 裡被關閉了，記錄層級是 NOTICE；Skipped 則是因為缺少必要條件，像是收件人欄位是空的，所以沒有真的寄出，記錄層級同樣是 NOTICE。
這四種狀態能幫你很快分辨問題出在哪一關。訂單相關的 Sent 與 Failed，還會同步寫進該筆訂單的私人備註裡，方便直接從訂單頁面回頭查；Disabled 與 Skipped 則只會出現在記錄檔裡，訂單備註看不到。另外要留意，官方文件也提到這份記錄不會寫入顧客真實的信箱地址，一律用 WordPress 使用者名稱或 guest 呈現，失敗訊息裡出現的信箱也會被遮蔽，所以查記錄是用來確認觸發狀態，不是拿來核對信箱地址對不對。
核心信件不進 WooCommerce 記錄，得查 wp_mail_failed
忘記密碼信這類 WordPress 核心信件不會出現在 WooCommerce 的記錄裡，得靠另一組工具。WordPress 開發文件記錄了 wp_mail_failed 這個 Hook，自 WordPress 4.4 起可用，會在 PHPMailer 拋出例外的時候觸發；對應的 wp_mail_succeeded 則是自 5.9 起可用，在信件成功交出的時候觸發。這兩個 Hook 等於是幫 wp_mail() 這個沒有內建記錄機制的函式，補上一層可以自己掛程式碼去記錄的觀察窗。
實務上的做法是先在 wp-config.php 裡開啟 WP_DEBUG_LOG，讓錯誤訊息寫進 wp-content/debug.log，再把 wp_mail_failed 掛進 functions.php，把每一次失敗的收件人、主旨與例外訊息都記下來。這樣才看得到本機端有沒有真的嘗試過寄信、失敗發生在哪一步，而不是只看到後台一個模糊的寄送失敗提示，卻不知道 PHPMailer 實際回傳的錯誤內容是什麼。有了這層記錄，才能判斷問題是出在網站呼叫寄信函式的當下，還是後面才發生。
主機層級的寄信記錄，用來確認問題不在網站本身
如果 WooCommerce 與 WordPress 核心這兩層都顯示信件已經送出，收件匣卻還是空的，下一步就要往主機端查。多數台灣中小型虛擬主機採用 cPanel 控制台，cPanel 官方文件說明其中的 Track Delivery 工具，預設會列出這個帳號底下最近 250 筆寄出與收到的信件事件，包含遞送成功、延遲遞送、遞送失敗等各種狀態。
這一層記錄能確認的是一件很具體的事，網站已經把信交出去了，問題出在主機或對方伺服器那一端把信擋下來，而不是網站根本沒有觸發寄信動作。這跟前兩層記錄查到的「網站端就沒送出」是完全不同的故障點，對應的解法也不一樣。前兩層失敗要回頭改程式或外掛設定；這一層失敗，通常代表要往下查 DNS 紀錄或收件端的判定邏輯，而不是繼續在 WordPress 後台裡打轉。
PHP 內建 mail() 函式沒有身分驗證機制
查完記錄檔，如果發現信件確實有被觸發、也確實被主機交出去，卻還是被收件端拒絕或丟進垃圾信匣，問題往往出在更底層的地方。WordPress 從來沒有內建自己的郵件傳輸引擎，wp_mail() 說到底只是把訊息包裝好，交給 PHP 內建的 mail() 函式去處理，而這個函式先天沒有任何反垃圾郵件的身分驗證機制。收件端要判斷這封信可不可信，完全得靠 DNS 上的 SPF、DKIM、DMARC 這三筆紀錄，沒有它們，再正常的內容也可能被當成可疑來源處理。
預設寄件位址不存在時，收件端當作可疑來源處理
WordPress 官方文件寫得很清楚，wp_mail() 從未提供完整的郵件使用者代理或傳輸代理，只是把訊息格式化之後交給 PHPMailer 函式庫，預設用的是 PHP 內建的 mail() 函式，這需要主機上有 sendmail 相容的程式來實際處理寄信，多數代管主機通常已經配置好、可以開箱即用。如果沒有另外設定寄件人，From 欄位預設會是 wordpress@你的網域，開頭的 www. 會被去掉，From 名稱預設則是 WordPress 這個字。
這個預設值藏著一個很多網站主都沒注意到的陷阱。官方文件明講，有些主機商會直接擋掉這個地址寄出去的信，因為這個信箱在收件伺服器上根本不存在，收件端一看就知道是可疑來源。建議的做法是先確認 wordpress@你的網域這個信箱真的存在、也收得到信，或者透過 wp_mail_from 與 wp_mail_from_name 這兩個過濾器，把寄件人換成一個真實存在的網域信箱。這一步看起來基本，卻是台灣中小型網站最常被跳過的一關，很多人直接跳去裝 SMTP 外掛，卻沒發現連最源頭的寄件人設定都沒對。
沒有 SPF 記錄，收件伺服器只能假設來源可疑
SPF（Sender Policy Framework）的正式技術規範 RFC 7208，把它定義成一種用 DNS TXT 紀錄描述哪些主機被授權替這個網域寄信的機制。這筆紀錄以 v=spf1 開頭，後面列出被授權的 IP 位址、主機或 include 對象，收件端的郵件代理收到信之後，會拿寄件伺服器的位址去比對這筆紀錄，判斷它是不是這個網域授權的來源。
WordPress 官方文件補充了一個很多人會漏掉的細節。如果你的網站是透過多個管道在寄信，例如原本網域自帶的信箱、WordPress 本身，再加上另外設定的 SMTP 轉送服務，就必須把每一個真的會寄信的來源都寫進同一筆 SPF 紀錄裡。漏掉任何一個來源，那個管道寄出的信就會被收件端判定為未授權來源，結果是同一個網站，有的信正常、有的信卻被當成垃圾信擋下來，原因就出在 SPF 紀錄沒有列全。
DKIM 簽章用來證明內容在傳輸中沒有被竄改
DKIM（DomainKeys Identified Mail）做的事跟 SPF 不一樣，SPF 驗證的是寄件來源有沒有被授權，DKIM 驗證的則是信件內容在傳送過程中有沒有被竄改。做法是在寄出的信件加上一段用私鑰產生的數位簽章，寫進 DKIM-Signature 這個標頭裡，收件端再拿這個網域公開在 DNS 裡的公鑰去驗證這段簽章，確認內容沒被動過手腳，也確實是這個網域授權寄出的。
WordPress 官方文件指出，如果是自己管理郵件傳輸引擎，可以在那一端直接設定簽章；部分 SMTP 外掛本身就內建 DKIM 簽章功能；比較進階的做法則是透過 phpmailer_init 這個 Hook，呼叫 PHPMailer 函式庫自行設定。不管走哪一種，重點是簽章驗證失敗時，收件端的郵件代理多半會直接把這封信當成垃圾信處理，即使 SPF 那一關驗證通過也一樣。SPF 與 DKIM 要一起看，任何一項單獨過關都不代表信件真的會被放進收件匣。
DMARC 政策決定驗證失敗的信件被隔離或退回
DMARC（Domain-based Message Authentication， Reporting and Conformance），DMARC.org 官方說明它建立在 SPF 與 DKIM 兩者之上，額外把驗證結果拿去跟信件 From 欄位的網域做比對，這個動作叫 alignment，再讓網域所有者發布一個政策，明確指示收件端遇到驗證失敗時該怎麼處理。政策分成三種，p=none 代表仍然放行、只回報，p=quarantine 代表隔離、視為可能垃圾信，p=reject 則是直接拒收。這個政策以 DNS TXT 紀錄的形式，發布在 _dmarc.你的網域 底下。
少了 DMARC 紀錄，收件端在 SPF、DKIM 驗證失敗時，就只能自己判斷要不要當垃圾信處理，等於少了一層明確指示。Google 官方的寄件人規範，從 2024 年起適用於每天寄給個人 Gmail 帳號超過 5000 封信的寄件者，明確要求寄件網域至少要有一筆 DMARC 紀錄，最低要求是 p=none 這個等級，否則會被歸類為無法提供投遞支援或緩解措施。多數中小企業網站的寄信量遠遠達不到這個門檻，但這條規範本身透露了一個訊號，沒有 DMARC 紀錄，信件在 Gmail 這類嚴格檢核的信箱面前，先天就處在比較不利的位置。
SMTP 轉信取代沒有驗證機制的內建寄信方式
前面三層都在講為什麼 PHP 內建的 mail() 先天缺乏身分驗證，解法是把 WordPress 的寄信方式，從這種沒有驗證機制的管道，換成走有帳號密碼認證的 SMTP 服務。這個動作本質上是在補上 SPF、DKIM 這些身分證明，不是單純換一個發信的水管而已。設定完也不能只看外掛顯示連線成功就結案，還要實際驗證 SPF、DKIM 是不是真的通過。
自架 MTA、轉送第三方與外掛直連，三種串接方式的差異
WordPress 官方文件把自架站台的寄信方案分成三種。第一種是自己架設一套完整的郵件傳輸引擎，直接對外寄信，管理者要自己承擔所有維運工作跟 IP 信譽的風險，官方文件形容這通常只適合有經驗的伺服器管理者。第二種是自架一個本機的郵件傳輸引擎，再把信轉送給第三方寄信服務，官方文件形容這是多數自架站台推薦的方法，比第一種好落地，也仍然保留 WordPress 原本的運作邏輯。
第三種是直接在程式層設定 SMTP，轉送給第三方服務，這也是多數 SMTP 外掛採用的做法，適合寄信量不大、不想處理郵件傳輸引擎複雜度的情況。不過官方文件也提醒，這個做法會讓每一次寄信都增加額外的效能負擔，因為每次都要重新走一次 SMTP 交握的流程。如果網站架在代管主機上，官方文件建議先直接問主機商有沒有內建 SMTP 轉送選項，很多代管方案其實已經幫你把這一步做好了，不必再另外裝外掛。
信件標頭裡的 SPF、DKIM、DMARC 是否真的顯示通過
設定完 SMTP 之後，正確的驗證動作不是看外掛顯示連線成功就結案，而是要去看信件標頭。以 Gmail 收信驗證為例，收到信之後點右上角的三個點選單，選顯示原始郵件，會開啟一份包含完整標頭與 Authentication-Results 摘要的頁面，逐項列出這封信的 SPF、DKIM、DMARC 各自是 pass、fail 還是 none。
只有這三項都顯示 pass，才代表這封信真的通過驗證，不是單純連線沒有出錯。Google Workspace 官方文件也指出，Gmail 會確保收發的郵件都經過驗證，未經驗證的訊息可能被歸類為垃圾郵件。這也是為什麼外掛顯示寄送成功，跟收件端判定為已驗證的合法郵件，是兩件不能劃上等號的事。設定完 SMTP，花兩分鐘打開一封測試信的原始郵件看一眼，比只看外掛的成功提示可靠得多。
沿用個人 Gmail 帳號當中繼，本身也有寄送上限
不少小型網站圖方便，直接拿自己的 Gmail 帳號密碼或應用程式密碼當 SMTP 中繼站。Google Workspace 官方文件列出了這個做法本身隱藏的限制，一般帳號透過 SMTP 傳送，也就是 POP 或 IMAP 使用者，每封信的收件者人數上限是 100 人，達到帳號的每日寄送上限之後，最長可能需要等待 24 小時才能再寄出新郵件，這段期間仍然收得到信，只是送不出去。
Google 官方文件也說明，Gmail 的 SMTP 服務會核對 From 欄位的寄件地址，只有跟登入認證用的帳號本身相同、或事先在 Gmail 的代收郵件設定裡明確授權過的地址，才會被視為合法的寄件人，用其他網域的位址當 From 會被擋下或被強制置換。這代表把個人 Gmail 帳號拿來當 WordPress 的 SMTP 中繼，平常低流量沒有問題，但通知信量一旦變多，像是促銷期間訂單信暴增，就可能觸頂被暫時封鎖寄信，而且網站的寄件位址也必須跟這個 Gmail 帳號本身一致，不能隨意換成網站自己的網域信箱。
測試信正常送達，真正的通知信卻依然消失
前面把 SMTP 設好、標頭也確認 SPF 與 DKIM 都顯示 pass，照理說問題應該解決了。但真正棘手、也是最常讓人摸不著頭緒的場景，恰好落在這裡，SMTP 外掛的寄送測試信顯示成功，測試信也真的收到了，表單通知信、訂單信、忘記密碼信卻仍然收不到。多數教學文章寫到裝好 SMTP 外掛就結束，沒有處理這個落差。這個落差多半來自兩個常見原因，一個藏在寄件人欄位裡，一個藏在排程機制裡。
表單外掛把訪客的信箱填進寄件人欄位，觸發偽冒攔截
這是最常見、也最容易被忽略的落差成因，問題不在 SMTP 設定本身，而在表單外掛的一個習慣。許多聯絡表單類外掛為了讓網站管理者收到通知後可以直接按回覆聯絡填表的訪客，預設會把訪客自己輸入的 Email 位址，放進通知信的 From 欄位。這個位址通常跟網站網域完全不同，也沒有被網站的 SPF、DKIM 紀錄授權過。
收件端，尤其是 Gmail 這類會嚴格核對驗證結果的信箱，一看到 From 的網域跟實際寄出這封信的伺服器對不起來，就會判定是偽冒風險。即使 SMTP 本身設定完全正確、也通過驗證，這封特定的信仍然會被丟進垃圾信匣，或者直接被退信。正確的做法是讓 From 欄位維持網站自己網域下、已經被授權的位址，把訪客的信箱改放進 Reply-To 欄位，這樣管理者一樣能直接回覆訪客，寄件人身分卻不會被冒用。SMTP 外掛內建的寄送測試信功能，From 固定使用網站自己已授權的位址，完全不會踩到這個問題，這正是測試信正常、表單通知信卻不正常這個落差最常見的成因。
WP-Cron 排程只在有人瀏覽網站時才會被觸發
第二個常見的落差成因，跟寄件驗證完全無關，而是 WordPress 排程機制本身的特性，很容易被誤判成又是垃圾信問題，結果白繞了一大圈遠路。WordPress 官方外掛手冊說明，WP-Cron 是靠每次有頁面載入的時候，去檢查一份排定任務清單，把到期的任務在那次頁面載入中一併執行。官方文件明講，如果排定一個任務在下午兩點執行，卻遲遲沒有頁面載入發生，一直到下午五點才有訪客進站，就可能發生排程延誤的情況。
官方文件也指出，WP-Cron 之所以會用這種方式運作，正是因為多數共享主機不開放系統層級的排程器存取權限，WP-Cron 算是在這個限制底下的變通方案。對流量本來就不高的中小企業網站，如果某些通知信是透過排程佇列處理，而不是在請求當下立即同步寄出，就會出現後台測試信因為是立即同步觸發、秒收沒問題，真正的通知信卻隔了很久，甚至遲遲沒有送出的現象。分辨這兩種其實不難，如果收不到的通知信本來就會把訪客或客戶的信箱填進寄件人欄位，那多半是第一種偽冒攔截的問題；如果是各種信件都偶爾發生、發送時間抓不準，同一封測試信在流量高的時段秒到，流量低的時段卻拖了老半天，那就比較像是 WP-Cron 排程延遲，要查的是有沒有真實流量或系統排程器定期觸發 wp-cron.php，而不是回頭懷疑 SMTP 設定又壞了。
主機端與外掛端的分工，決定下一步該聯絡的對象
把前面幾節查到的線索放在一起看，才會知道這次問題的責任邊界落在哪一端，是該調整 WordPress 這端的設定，還是該回頭核對 DNS 紀錄，或者聯絡主機商、SMTP 服務商協助處理。
退信與拒收訊息裡的錯誤代碼，指出問題發生的那一端
退信訊息本身其實夾帶了不少線索，不必逐項亂猜。Google 官方的寄件人規範說明，Gmail 對不符規範的信件會回覆特定的錯誤代碼，4.7.x 系列屬於暫時性失敗，代表信件被延遲或降頻處理，常見原因像是驗證不完整，或是 DNS 的正向與反向解析缺失，寄件端還有機會補齊條件後重新送達；5.7.x 系列則屬於永久性失敗，代表信件直接被拒收。
這些代碼加上附帶的文字說明，通常會指出是缺少 SPF、DKIM 對齊，還是網域缺少正確的正逆解析紀錄，或是垃圾信比例過高。把這些線索拿來對照前面幾節查到的記錄檔，如果記錄顯示 wp_mail_failed 捕捉到例外，代表本機端就沒有真的送出信，問題要往程式或外掛設定找；如果記錄顯示信件已經送出，收件端卻回了退信代碼，問題就轉移到 DNS 的驗證紀錄或收件端的判定邏輯。有了這個對照，接下來該回頭調整網站設定，還是該聯絡主機商核對 DNS 紀錄，或聯絡 SMTP 服務商查詢退信原因，答案就清楚了。
WordPress 收不到信這件事，很少是單一原因造成的，往往是好幾層條件疊在一起才會出現。從先分辨有沒有送出開始，查完記錄檔再往 DNS 紀錄查，最後把測試信正常、通知信卻消失這種落差抓出來，每一步查到的線索都在幫你縮小問題的範圍。下次再遇到收件匣空空如也的狀況，與其急著重灌一個新的 SMTP 外掛，不如先照著這個順序把記錄檔翻一遍，通常都能在其中一層找到答案。