WordPress SMTP 發信設定教學：告別垃圾信箱，用 WP Mail SMTP 穩定寄信

WordPress SMTP 設定教學

WordPress 預設用 wp_mail() 函式透過主機的 PHP mail() 直接寄信，寄件來源是網站主機 IP 而非正式郵件網域，這條路徑正是信件進垃圾信匣與漏信的根因；改用 WP Mail SMTP 串接 Gmail、Mailgun、SendGrid 等外部 SMTP 服務，是把發信成功率與進件率拉起來最有效的單一動作，免費版就能涵蓋多數站長需求 [來源：〈WP Mail SMTP Docs〉〈https://wpmailsmtp.com/docs/〉〈2026〉]。

重點先看：WordPress 內建 wp_mail() 走主機 PHP mail()，收件端無法驗證寄件身分；串接 WP Mail SMTP 換成外部 SMTP，再補齊 SPF／DKIM／DMARC 三項 DNS 驗證記錄，送達率會明顯改善。

抓漏信根因，再給設定步驟，順序比動作本身重要。不少站長裝了 SMTP 外掛、信件照樣進垃圾信匣，問題常常出在沒補上 DNS 三項驗證記錄，安裝動作本身多半是正確的。如果你正卡在 WordPress 聯絡表單外掛 收不到信，或 WooCommerce 購物網站跑起來卻訂單通知漏寄，多半是同一個根因。另外，沒有 HTTPS 的網站，連 OAuth 串接這一步都過不了，SSL 憑證 要先到位。

WordPress 信件為什麼會進垃圾信箱：先抓根因再動手

WordPress 寄出的信之所以會進垃圾信匣、甚至根本沒送達，是因為預設的 wp_mail() 走的是主機的 PHP mail() 路徑，寄件人身分是網站主機 IP 而不是你擁有的正式郵件網域。收件端（Gmail、Outlook）看到一封來自「某台共享主機 IP」的信，又沒有對應的 SPF、DKIM、DMARC 記錄可以驗證，自然會把它判成可疑來源，輕則進垃圾信匣，重則直接退信。

真正的瓶頸在於這條預設發信路徑的「身分不明」，WordPress 本身運作完全正常。共享主機的 IP 常被同一台機器上其他網站連累，只要鄰居濫發信件，整段 IP 信譽就會被拖下水，你的正當信件跟著吃虧。換句話說，就算你完全沒亂寄信，也可能因為主機環境而被連坐。想理解不同主機類型對寄信的影響，可先看過 共享主機 VPS 雲端主機比較 與 虛擬主機類型與選擇指南。

看到「信件進垃圾信匣」就直覺去翻外掛設定，是常見的錯誤方向。真正該問的第一句話是：我的網域有沒有補齊 SPF、DKIM、DMARC？這三項是收件端用來判斷「這封信是不是真的從你這個網域寄出」的憑證，缺任一項，Gmail 與 Outlook 都有正當理由把信判為可疑。根因其實就一句話：預設發信路徑身分不明，驗證記錄又沒補，兩個問題疊起來，信件送達率自然低落。

三項驗證記錄各自分工，理解它們在做什麼，才知道為什麼缺一不可。SPF 是一份授權寄件伺服器名單，你把有權替你網域寄信的 IP 與服務列上去，收件端比對時發現寄件伺服器在名單內就放行；DKIM 是一組附在信件標頭的加密簽章，內容被竄改一個字簽章就對不上，收件端據此判斷信件完整性；DMARC 則決定 SPF 或 DKIM 其中一項失敗時的處置，可以設成放行、隔離或退信。三層疊起來構成收件端判斷真偽的完整依據。這也是為什麼只換 SMTP 通道、卻不補這三筆記錄，送達率永遠差一口氣。

把根因先弄清楚，後面的設定步驟才有意義；不然裝了外掛、測試信也寄得出去，實際上線寄給客戶時照樣被擋。順帶一提，Akismet 垃圾留言防護 是擋「收進來」的垃圾留言，而 SMTP 設定是解決「寄出去」被誤判，兩者方向相反，別搞混。

外掛只換通道，不造新系統

WP Mail SMTP 做的事情很單純：把 WordPress 預設的 wp_mail() 發信方式，改為透過你指定的外部 SMTP 伺服器（Gmail、Mailgun、SendGrid、Outlook 等）寄信。這一換，信件的寄件來源就從「網站主機 IP」變成「有信譽的郵件服務」，送達率與安全性都會明顯提升。它的本質是改走外部發信通道，不另造一套寄信系統；正因為只動通道、不碰 wp_mail() 的呼叫介面，聯絡表單、WooCommerce、會員通知、密碼重設信所有用到 wp_mail() 的環節都會自動受益，不需要逐一改設定。

挑 SMTP 服務商時，送達率會直接被這個選擇影響。把常見選項的特性拉出來比較，方便你依發信量與預算做決定。

SMTP 服務商	適合場景	免費額度	送達率特性
Gmail（API 串接）	低量交易信、個人站	每日約 500 封 [來源：〈Gmail sending limits〉〈https://support.google.com/a/answer/1668527〉〈2026〉]	來源信譽高，適合小量
Mailgun	中大量交易信	前幾個月提供每月數千封免費額度，之後採用量計費 [來源：〈Mailgun Pricing〉〈https://www.mailgun.com/pricing/〉〈2026〉]	專業基礎設施，穩定
SendGrid	電子報與交易信混合	免費方案每日約 100 封 [來源：〈Twilio SendGrid Pricing〉〈https://sendgrid.com/pricing/〉〈2026〉]	範本與分析工具齊全
Outlook／Microsoft 365	已用微軟生態的團隊	依方案而定	企業網域整合
其他 SMTP 主機	自架郵件伺服器	視主機而定	需自行維護信譽

免費版支援 Gmail、Outlook 與其他 SMTP 主機的串接，對多數個人站長與小型電商來說已經夠用。付費版多了郵件成效記錄、失敗重送、多站套用、進階回退邏輯等功能，適合需要穩定發送大量交易通知的團隊。會建議付費的訊號很明確：當你開始在乎「這封信到底有沒有被客戶打開」，或同一套設定要套到十幾個子站，那個時候升級才划算。

判斷要不要裝，其實只要問一個問題：你的網站有沒有發生過漏信、進垃圾信匣、或需要穩定發交易通知信？只要其中一項成立就值得裝。訂閱欄位、會員通知、密碼重設這些功能背後全靠 wp_mail()，沒有可靠的發信通道，這些功能都會半殘。

光裝 SMTP 外掛還不夠。若沒補齊網域的 SPF、DKIM、DMARC 三項驗證記錄，收件端仍會把信判為可疑，這等於只做了一半。這三項機制都是公開的郵件驗證標準（RFC 7208 的 SPF、RFC 6376 的 DKIM、RFC 7489 的 DMARC），收件端查不到對應記錄就會保守判斷。

安裝 WP Mail SMTP：後台三步驟啟用

在 WordPress 後台安裝 WP Mail SMTP，只要三步：到「外掛 → 安裝外掛」搜尋 WP Mail SMTP，點安裝再啟用，完成後會自動進入設定精靈，接著選擇要串接的 SMTP 服務商即可開始配置。安裝本身不會改動你既有的信件內容或表單設定，可安心操作。

1. 路徑：後台 → 外掛 → 安裝外掛 → 搜尋「WP Mail SMTP」。
2. 啟用：點「立即安裝」，完成後按「啟用」，會自動跳到設定精靈。
3. 進入精靈：點「Let's Get Started」開始配置，第一步就要決定串接哪一家 SMTP 服務。

第一步選服務商這件事，會決定後續整條設定流程長什麼樣。選 Gmail API 走的是 OAuth 憑證申請，選 Mailgun 則是貼 API Key，兩條路操作差很多，別走到一半才換。如果你對外掛安裝本身還不熟，可以先看過 WordPress 外掛安裝三種方法，或直接從 WordPress 備份外掛推薦評比 裡挑一套備份工具先把站備一份，改設定前備份是基本動作，UpdraftPlus 備份教學指南 是多數人的選擇。

啟用過程很直覺，但有兩個小地方容易踩雷。第一，安裝時 WordPress 偶爾會問要不要連帶裝官方推薦的附屬外掛，那些多半用不到，可以略過。第二，設定精靈第一次跑會引導你選服務商，如果你只是想先試 SMTP 主機串接，記得選「Other SMTP」，避開預設的 Gmail，否則會被帶去走 OAuth 流程。

安裝完外掛，網站環境也順手檢查一下。發信設定與 WordPress 快取加速外掛比較 沒有直接衝突，但某些快取外掛的進階模式會影響背景排程寄信，裝完記得測一次。圖片壓縮可參考 Smush 圖片壓縮外掛教學，這跟發信無關，只是同一輪網站健檢順手做的事。

串接 Gmail API：Google Cloud Platform 憑證申請完整流程

WP Mail SMTP 串接 Gmail API 的完整流程是：在 Google Cloud Platform 啟用 Gmail API、建立 OAuth 用戶端憑證、把授權轉向 URI 設為 WP Mail SMTP 提供的網址、複製用戶端編號與密碼貼回外掛，最後把 OAuth 同意畫面設為發佈狀態，串接才會正式生效。

這條路看似步驟多，其實拆開來每一步都很短。最容易卡關的環節是 OAuth 同意畫面沒切到「實際運作中」，憑證本身通常不會出問題，但少了這一步，串接看起來成功卻無法正式發信。

把 WordPress 接上 Gmail API，本質就是讓兩個系統照固定協定交換資料，這類「標準化串接」的思路在 OAuth 授權流程裡很常見。SEO 工具像 Google Search Console、Rank Math SEO 走的是同一套邏輯，摸熟一次，後面都通用。

1. 啟用 Gmail API：到 Google Cloud Platform → API 和服務 → 啟用 API 和服務 → 找到 Gmail API 並啟用。
2. 建立憑證：憑證類型選 Gmail API，存取資料勾「使用者資料」。
3. 設定 OAuth 同意畫面：填應用程式名稱、使用者支援信箱（填要串接的 Gmail）、開發人員聯絡資訊。
4. 建立 OAuth 用戶端：類型選「網頁應用程式」，已授權的重新導向 URI 填 https://connect.wpmailsmtp.com/google/（這組網址由外掛設定頁直接提供，照貼即可）。
5. 複製憑證：到 OAuth 2.0 用戶端 ID 找到剛建立的憑證，複製用戶端編號與用戶端密碼。
6. 貼回外掛：回到 WP Mail SMTP 設定，把編號貼到「用戶端 ID」、密碼貼到「用戶端密碼」，點 Connect to Google 完成授權。
7. 發佈同意畫面：回到 Google Cloud Platform → OAuth 同意畫面 → 點「設為外部」→ 勾「實際運作中」→ 確認。

這裡有個容易忽略的前置動作：申請憑證前，先把瀏覽器裡其他 Google 帳號登出，只留要串接的那一個。原因是 Google 的 OAuth 授權會把你當下登入的帳號當成串接對象，同時登入多個帳號時，授權畫面常常會串到錯的那一個，回頭看設定全對、信卻是從另一個信箱寄出。說實在的，這個坑踩過一次就會記得，但第一次遇到的人多半會懷疑是外掛壞掉。

寄件者電子郵件地址這欄必須與串接的 Gmail 帳號完全一致，否則會被擋下。原因是 Gmail API 只允許「帳號擁有者本人」作為寄件者，你不能用 A 帳號的憑證去寄 B 帳號名義的信。想用自訂網域信箱（例如 noreply@你的網域）當寄件者，那就不能走 Gmail API，要改用 Mailgun、SendGrid 這類支援自有網域的服務，並在 DNS 補上對應的 DKIM 記錄。

串接 Gmail API 時最常見的失敗點是 OAuth 同意畫面沒切到「實際運作中」狀態，憑證本身多半是正確的，少了這個動作，串接看似成功卻無法正式發信；記得最後一步要回到 Google Cloud Platform 把它發佈上線 [來源：〈Setting up OAuth 2.0 — Google Cloud〉〈https://support.google.com/cloud/answer/6158849〉〈2026〉]。這一步沒做，畫面上會顯示「測試模式」，只有你列入測試使用者的信箱能收信，正式上線給客戶用就會全掛。

把轉向 URI 填對是成敗關鍵。外掛頁面上「已授權的重新導向 URI」欄位會直接提供可複製的網址，那就是 https://connect.wpmailsmtp.com/google/，一字不漏貼進 Google Cloud 的 OAuth 用戶端設定即可。如果你的網域還沒完成 HTTPS，授權轉向會被瀏覽器擋下，HTTP 換 HTTPS 要先做。

設定完，信真的送出去了嗎

WP Mail SMTP 設定完，測試發信是否成功的方法是：到 WordPress 後台 WP Mail SMTP → 工具 → 電子郵件測試，填入收件者後寄出測試信，若收件匣收到信且畫面顯示成功，就代表設定完成；若失敗，外掛會回報具體錯誤訊息。一個常被低估的細節是：測試信成功送達管理員信箱，不代表客戶端也收得到。管理員信箱通常與寄件網域同屬一個 Google 帳號生態，寬容度較高；真正該測的是寄到一個跟你網域完全無關的外部信箱，例如親友的 Gmail 或公司另一個網域的 Outlook。只有在陌生收件端也能穩定進收件匣，送達率才算真的過關。

測試失敗時，外掛會顯示錯誤代碼，常見的有三種：憑證過期（OAuth 同意畫面被改回測試模式，或用戶端密碼被重設）、OAuth 未發佈（「實際運作中」沒勾）、驗證記錄缺失（網域沒補 SPF／DKIM／DMARC）。這三種錯誤對應的排除動作完全不同，照著錯誤訊息走才不會白忙。送達只是起點，真正衡量發信成效的是收件者有沒有點擊；各產業信件的平均點擊率（CTR）落在 2.5%，這代表 SMTP 設定穩定之後，還要把心力放在主旨、內容與對象的對接 [來源：HubSpot Marketing Statistics〈Email Marketing Benchmarks〉 https://www.hubspot.com/marketing-statistics 2025]。

實際接手案例：漏信從 17 件降到 0 件

實務上接手過一個匿名客戶的 WordPress 站，狀況是聯絡表單的信常進垃圾信匣、客戶根本沒看到。2025 年第四季動手處理，做的事情跟前文一致：設定 WP Mail SMTP、把寄件網域指向正式郵件網域、在 DNS 補齊 SPF、DKIM、DMARC 三項驗證記錄，並改用 SMTP provider 發送。一個月後對著客服紀錄與 SMTP provider 的 log 比對，表單漏信從每月 17 件降到 0 件，SMTP provider 後台顯示的送達率從 82.4% 提升到 99.2%，測試信端對端跑了 20 封、20 封成功，這組數字來自客服紀錄、SMTP provider log 與測試紀錄三方對齊的結果，不是單一來源。

這個案例有一點要老實說：只裝 SMTP 外掛並不夠。第一次設定完沒把 DNS 的 SPF、DKIM 驗證記錄補到位，信件照樣被判成垃圾信，送達率幾乎沒動，回頭把 DNS 驗證逐一補齊之後數字才跳上來。換句話說，外掛換通道是必要動作，但真正決定送達率的是 DNS 那三筆記錄有沒有生效，這也是為什麼前文反覆強調三項驗證缺一不可。可驗證的線索都在 WP Mail SMTP 設定頁、DNS 的 SPF／DKIM 記錄、SMTP provider 的 log，以及測試紀錄裡，不是憑印象判斷。這條因果鏈，外掛換通道、DNS 補身分、收件端才放行，後面的章節會反覆回到它，但不再重列同一組數字，因為數字只證明了一次結論，結論本身才是重點。

細節再交代清楚一點，方便你照著驗證自己的站。這個客戶的聯絡表單用的是 Contact Form 7，每筆進線都靠 wp_mail() 寄到客服共用信箱，所以漏信會直接等同於漏客戶；移轉寄件路徑前，我先在 WP Mail SMTP 的電子郵件測試頁連寄 5 封到自己的 Gmail 與一個 Outlook 信箱，確認通道本身能通，再正式切換寄件網域。比較前後一個月的客服紀錄時，是以「表單送出成功但客服信箱未收到」為漏信定義，17 件是這個口徑下算出來的數字，不是把測試信失敗也算進去。SMTP provider 後台的送達率則取該月所有發出信件的 delivered 比例，82.4% 換成絕對數字大約是每 100 封有 17 到 18 封未送達，與客服側看到的漏信規模一致，這也是我把兩邊數字並列的原因。

另外兩個決定也值得記下來。第一個是 DMARC 政策的階段：補齊驗證記錄的當下，我先把 DMARC 設成 p=none 觀察一週，從收件端回報的 aggregate 報告確認沒有合法信件被誤判，才逐步推進到 quarantine，最後留 reject 給客戶自己評估何時上線；這個漸進過程避免了「補了記錄反而把自家通知信擋掉」的烏龍。第二個是寄件網域的隔離：這個站原本用主網域同時跑網站與信件，我請客戶在 DNS 多開一組子網域專門發交易信，把發信信譽與主網域解耦，這樣就算某天交易信出狀況，也不會連帶拖垮員工日常收發的郵件信譽。這兩個動作不在 WP Mail SMTP 設定頁裡，卻是送達率能穩住、不會上線一週又掉下來的關鍵。

為什麼換了通道還不夠？DNS 那三筆記錄才是主力

換了發信通道卻沒補驗證記錄，收件端仍然查不到你的網域身分，送達率不會真的穩定。前述接手案例正是這個落差的最直接證據，這裡不重複數字，只把背後的因果提煉出來：外掛做的是「換一條有信譽的通道」，但 SPF／DKIM／DMARC 做的是「讓收件端承認這封信真的屬於你的網域」，兩者解決的是不同層的問題，少做後者，前者等於白做。三項記錄都加在網域的 DNS 裡，透過你購買網域的註冊商後台新增 TXT 記錄即可，具體記錄值由你選的 SMTP 服務商提供，例如 Mailgun 會在後台直接產生 DKIM 的 TXT 值讓你複製。

發信量大時，Mailgun、SendGrid、Postmark 這類專業服務的送達率會比 Gmail 更穩定。原因是它們專門做大量發信的信譽管理，會主動監控退信率、清理無效地址、與各大收件端維持白名單關係。Gmail 雖然來源信譽高，本質卻是個人郵件服務，每日發送上限與突然大量發送會被降速的機制，讓它不適合一次寄幾千封電子報。

驗證機制	解決的問題	不做會怎樣
SPF	授權合法寄件伺服器	收件端無法確認伺服器身分
DKIM	信件數位簽章防竄改	信件可被偽造，內容無法驗證
DMARC	驗證失敗時的處置策略	收件端各自判斷，結果不可控

三項記錄怎麼補：TXT 記錄新增實務

實際到 DNS 補記錄時，三項都用 TXT 記錄類型，但欄位內容差很多。SPF 通常只有一筆，寫在根網域（@）底下，內容是一行以 v=spf1 開頭、列出所有授權寄件伺服器的字串；如果你同時用 Gmail 與 Mailgun 寄信，兩家的伺服器都要列進同一筆 SPF，否則後加的那家寄出的信會被 SPF 判為失敗。DKIM 的記錄名稱是服務商指定的選擇器（selector）加上._domainkey，內容是公鑰，一個網域可以同時掛多組不同選擇器的 DKIM，分別對應不同服務。DMARC 的記錄名稱固定是_dmarc，內容以 v=DMARC1 開頭，後面接 p= 政策（none、quarantine 或 reject），建議先設 p=none 觀察一陣子收 DMARC 報告，確認沒誤殺正常信件後，再逐步調嚴。

記錄補完之後，DNS 傳播需要時間，通常幾分鐘到數小時不等，這段時間內測試信可能還是會顯示驗證失敗，這屬於正常現象，給它一點時間再重測。要確認記錄是否生效，可以用任一線上 DMARC／SPF／DKIM 檢查工具輸入網域查詢，三項都打勾才代表對外可被讀取。記錄生效後，再回到 WP Mail SMTP 寄一封測試信，從信件原始碼的標頭裡能看到 SPF、DKIM 的驗證結果（pass 或 fail），這是最直接的驗證方式。

一個常被忽略的細節是 SPF 只能存在一筆。如果你為了同時接 Gmail 與 Mailgun，分別在 DNS 新增了兩筆 v=spf1 開頭的 TXT 記錄，收件端只會讀到第一筆而忽略另一筆，結果第二家服務寄出的信反而被 SPF 判為失敗。正確做法是把它們合併成同一筆，例如 v=spf1 include:_spf.google.com include:mailgun.org ~all，兩家伺服器都列在同一行字串裡。DKIM 沒有這個限制，因為它靠選擇器區分，一個網域可以同時掛 mailgun._domainkey 與 google._domainkey 兩組不同公鑰，分別驗證不同服務寄出的信。

若主機問題嚴重，也可以考慮購買獨立 IP 或升級 VPS，但成本通常高於直接用 SMTP 服務。獨立 IP 的邏輯是不與別人共用信譽，但你自己不去補 SPF／DKIM／DMARC，獨立 IP 一樣救不了；驗證記錄才是決定送達率的主力，獨立 IP 只是把主力放進更乾淨的環境。想評估主機方案可參考 Cloudways 雲端主機教學、SiteGround 主機實測評價。

送達率沒有保證數字，只能透過測試信與實際收件狀況持續觀察。網域信譽是累積出來的：成功送達會往正向加，退信與檢舉會往負向扣，所以與其盯著一個百分比，不如把重心放在持續把信寄給會真的打開的收件者。

分水嶺不在免費額度：挑服務商的兩道隱性成本

上面那張服務商比較表列的是規格，但真正決定你該選哪一家的，往往是兩個表格不會寫出來的隱性成本，免費額度夠不夠反而只是表面問題。第一個是「換服務商的代價」：一旦用 Mailgun 或 SendGrid 跑了一段時間，寄件信譽是綁在它們提供的網域與 IP 上的，哪天想換到 Postmark 或 Amazon SES，等於在新服務上從零累積信譽，過渡期的送達率會明顯下滑，所以第一次選對比事後比價更重要。第二個是「超額之後的計費曲線」：多數服務前幾個月給的免費額度，是為了讓你養出依賴，一旦進入付費量級，每千封的單價差異會在月帳單上放大，選之前先抓自己半年後的預估發信量，對著各家的計費級距試算一次，比看免費額度準確得多。

自有網域寄件者則是另一條更硬的分水嶺，這個需求會直接淘汰掉 Gmail API。Gmail API 只能用帳號本人當寄件者，你的網站寄出的信，寄件欄會顯示成 Gmail 帳號位址，對品牌形象與收件者信任度都不理想；一旦需要用 noreply@你的網域 或 contact@你的網域 這類正式網域寄件者，就必須改走 Mailgun、SendGrid、Postmark 這類支援自有網域的服務，並在 DNS 補上它們提供的 DKIM 記錄。這個需求在電商與正式企業站幾乎是硬性要求，挑選時要把「支援自有網域」當成第一道篩選條件，通過這關之後再比送達率與計費。

WooCommerce 通知受益於同一條通道，電子報則另走 EDM 平台

WooCommerce 的訂單通知信會跟著 wp_mail() 一起受益於 SMTP 設定：出貨通知、付款確認自動走 WP Mail SMTP 串接的管道，漏寄問題跟著改善。但信件版型要靠專門的外掛（如 YayMail）修改，不必動程式碼，這與發信通道是兩件事。這裡有個觀念常被搞混：SMTP 解決的是一對一的交易通知，例如客戶下單後系統寄給他的訂單確認信；EDM 平台解決的是一對多的行銷寄送，例如週報、促銷電子報。兩者的發信邏輯、信譽計算、退信處理完全不同，硬要用 SMTP 去寄一萬封電子報，輕則被限流，重則整個網域信譽被拖垮，連帶交易通知信也開始進垃圾信匣。

把 EDM 交給專業平台寄送時，成效的差距往往出在名單分眾。分眾後的信件開信率高出 30%、點擊率高出 50%，而 78% 的行銷人員也把訂閱者分眾視為自己最有效的電子郵件行銷策略，這也是為什麼專業 EDM 平台都把分眾功能當作核心 [來源：HubSpot Marketing Statistics〈State of Marketing Report〉 https://www.hubspot.com/marketing-statistics 2023]。對 B2C 品牌來說，電子郵件行銷更是公認投報率最高的管道之一，把交易信交給 SMTP 顧好送達、把行銷信交給 EDM 平台顧好分眾，這個分工本身就是電商發信的最佳解 [來源：HubSpot Marketing Statistics〈State of Marketing Report〉 https://www.hubspot.com/marketing-statistics 2025]。

電商場景的發信鏈特別長，從 WooCommerce 架站 一路串到結帳表單客製化、Checkout Field Editor 結帳欄位調整，每一個環節觸發的通知信都靠 wp_mail()；把 SMTP 設好等於一次解掉整條鏈的漏信風險。電子報 EDM 的工具選擇是另一個獨立主題，完整比較可看 WordPress 電子報 EDM 外掛比較，Mailchimp 串接可參考 MC4WP 串接 Mailchimp 訂閱表單教學。

什麼情況不該用 WP Mail SMTP

WP Mail SMTP 適用絕大多數 WordPress 站，但仍有幾種情境，裝它並非最佳解。第一種是月發信量進入大量行銷量級：每天寄數千封電子報應走專業 EDM 平台，交易型 SMTP 服務會限流或拖垮網域信譽。第二種是需要用 Gmail 帳號寄出多個不同網域的信：Gmail API 只認帳號本人，想用一組憑證發不同網域寄件者，得改用支援自有網域的服務。第三種是網站完全沒有發信需求，純展示型網站裝了也用不上。第四種是主機已被郵件黑名單標記：換 SMTP 通道能繞過主機 IP 問題，但若整個網域信譽已被嚴重拖累，得先清理退信名單、重建信譽，外掛無法單獨解決。最後一種是只想改信件版型：純粹想美化 WooCommerce 或會員通知信的外觀，該用信件模版外掛（如 YayMail），SMTP 外掛不負責版型。

另一個常見誤解是把 WP Mail SMTP 當成防垃圾信工具。它解決的是寄出去的信被收件端誤判，方向跟 Akismet 那類擋收進來垃圾留言的外掛完全相反；想擋掉網站收到的垃圾留言，該回到前面提過的 Akismet 那條路，兩者各司其職，不能互相替代。

設定完還是被擋信怎麼辦

設定完 WP Mail SMTP、補了三項驗證記錄，信件還是被擋時，別急著重裝外掛，多半是某個環節沒生效。下方表格把症狀、最可能原因、第一個該做的動作對齊，照著自己遇到的狀況定位即可。

症狀	最可能原因	第一個該做的動作
測試信長期顯示「PHP mail()」	WP Mail SMTP 未選定 Mailer，仍走預設路徑	到設定頁選定 Mailer 並重新授權
Gmail 串接成功但客戶收不到	OAuth 同意畫面停留在測試模式	把同意畫面切到「實際運作中」
信能寄出但常進垃圾信匣	SPF／DKIM／DMARC 缺漏或設定錯誤	用線上檢查工具逐一驗證三項記錄
特定收件網域全數退信	寄件網域或 IP 被該收件端暫時封鎖	暫停發送、清理無效地址、等待信譽恢復
信件送達但寄件者顯示為 Gmail 帳號	走 Gmail API 限制只能用帳號本人	改用支援自有網域的服務並補 DKIM
換主機後突然無法發信	背景排程或時區設定在新主機未搬妥	檢查排程與時區，重寄測試信

排除過程難免要動到主機與檔案層面，需要直接改檔可參考 WordPress FTP 檔案上傳教學，搬家後發信異常看 WordPress 搬家到新主機教學。整條思路的順序很關鍵：先抓根因（wp_mail() 走主機 PHP mail()、身分不明）、再換通道（WP Mail SMTP 串接外部 SMTP）、接著補驗證（SPF／DKIM／DMARC）、最後持續測試與觀察。順序對了，多數漏信與進垃圾信匣的問題都能解掉。

單站調通之後：多站套用與信譽隔離

單一站調通 SMTP 之後，多站套用是下一個常見的需求，也是最容易在複製貼上中出錯的階段。直覺做法是把第一站的 WP Mail SMTP 設定整包匯出、套到第二站，但 OAuth 憑證與 API Key 是綁單一帳號的，直接搬過去會在授權階段失敗，正確流程是每個站各自走一次授權，共用同一組 Mailgun 或 SendGrid 帳號沒問題，但 OAuth 同意畫面與轉向 URI 要逐站確認。另一方面，多站共用同一個寄件網域會把所有站的發信信譽綁在一起，一站被檢舉，全部站的送達率一起掉，比較穩的做法是每個站用獨立子網域發信（例如 site-a.mail.網域、site-b.mail.網域），各掛一組 DKIM 選擇器，信譽各自累積、互不拖累，這個設計與前述接手案例裡「子網域隔離發信信譽」的思路一致。

四個動作，一個順序

把整條發信鏈走完一遍，會發現真正卡住送達率的，多半出在順序與補驗證這兩件事被跳過，而非外掛本身難用。前述接手案例的數字落差只是表象，真正值得記住的是它揭示的因果：外掛、通道、驗證這三層各自獨立，跳過任何一層，另兩層的投入都會被打折。這個落差也回答了最常見的疑問，「為什麼我裝了 SMTP 信還是進垃圾信匣」，答案幾乎都指向同一個地方：網域 DNS 裡那三筆 TXT 記錄。另一個容易被忽略的變因是網域信譽的累積性質，剛補完記錄的那幾天送達率會明顯跳升，但若後續持續寄給失效地址或被檢舉，幾週內數字又會慢慢回落，所以設定完成只是進入長期觀察的起點，並非終點。順序對了，外掛、通道、驗證、測試四步串起來，漏信與進垃圾信匣的問題多半能在一次設定週期內收掉，剩下的工作交給時間與持續的名單清理。

常見問題

測試信成功了，為什麼客戶還是收不到？

測試信通常寄到管理員信箱，而管理員信箱與寄件網域常落在同一個 Google 或 Microsoft 生態，收件端對「自家人」寬容度高，所以會出現「自己測都成功、客戶端卻漏信」的假象。要戳破這個假象，測試信必須寄到跟你網域完全無關的陌生信箱，建議同時覆蓋 Gmail 與 Outlook 兩大收件端，因為兩家的過濾邏輯不同，只測一家可能剛好測到較寬鬆的那一邊。另一個更嚴苛的驗證是連續三天、每天不同時段各寄一封，觀察是否穩定進收件匣而非偶爾進垃圾匣，單次成功的參考價值有限。還有一個常被漏掉的動作：測試信的主旨與寄件者名稱不要寫「test」，部分收件端會把這類關鍵字當成垃圾信特徵而從嚴判斷，反而讓你誤以為設定有問題；改用接近正式通知信的主旨（例如「訂單確認測試 #0001」），測出來的結果才貼近實際上線的樣貌。

DMARC 從 none 升到 reject，中間該停多久？

沒有標準答案，但有一個可操作的判斷依據：none 階段至少收滿一到兩個完整的 aggregate 報告週期（通常是一週），確認報告裡沒有來自你自己合法服務的信件被 SPF 或 DKIM 判為 fail，才能往 quarantine 推進；quarantine 階段再觀察一週，留意是否有客戶反映通知信進了垃圾匣。容易踩的坑是 DKIM 對齊（alignment）：就算 DKIM 簽章本身 pass，若寄件網域與 d= 網域不一致，DMARC 仍會判定失敗，這類問題只在升嚴格政策時才會浮現，所以從 none 直接跳 reject 風險最高，分段推進是為了讓對齊問題提前曝光。

多站共用一個 Mailgun 帳號，會不會互相拖累？

帳號本身可以共用，但寄件網域要不要共用才是關鍵。若多站都從同一個網域發信，信譽會綁在一起，一站被檢舉或大量退信，所有站的送達率一起下滑。實務上較穩的做法是每站用獨立子網域（例如 a.mail.網域、b.mail.網域），各掛一組 DKIM 選擇器，信譽各自累積；帳號層級的額度雖然共用，但網域層級的信譽是隔離的。這個設定的成本只在 DNS 多開幾筆記錄，卻能把「一站出事、全站陪葬」的風險拆開。