課程網站最容易被低估的地方之一，就是 Email。
付款成功後，學員可能要靠 Email 收到訂單、帳號、密碼與課程入口；忘記密碼時要靠 Email 重設；分期扣款失敗，也可能透過 Email 才知道要補款。只要其中一封關鍵通知沒有送到，學員看到的就不是「郵件系統有問題」，而是「我付錢了，為什麼沒有課程？」
所以交易郵件要當成課程交付的一部分，而不是網站做好之後順手裝一個 SMTP 外掛就算完成。
先分清楚：網站有觸發、郵件有送出、收件人有收到，是三件事
很多排錯只做到第一層：WordPress 顯示「Email 已傳送」，就以為流程正常。
- 網站是否正確觸發通知。
- 郵件服務是否接受這封信。
- 寄件網域是否通過必要驗證。
- 收件方是否接受，而不是退信或延遲。
- 最後進到收件匣、分類頁籤或垃圾郵件。
因此「沒收到」不能只看 WordPress。有時網站根本沒有觸發；有時 SMTP 已接受，但收件方拒絕；也可能信件成功送達郵件伺服器，最後卻被分類到垃圾郵件。比較有效的做法，是每一層都留下一個可查的狀態。
交易郵件和行銷郵件，任務不同
交易郵件是因為使用者已經做了一個動作，系統需要回覆必要資訊，例如訂單確認、付款狀態、會員帳號建立、密碼重設、課程入口與必要開課資訊。
行銷郵件則是內容培育、電子報、活動邀請、促銷與其他推廣訊息。兩者可以使用同一品牌，但寄送目的、頻率、退訂規則與風險不同。至少要在流程上分清楚，不要把「學員一定要收到的登入信」和「這週的行銷電子報」當成同一種任務處理。
如果你在規劃 Email 行銷與 CRM，可以先看Brevo 是什麼？Email 行銷、CRM、SMTP 與免費方案介紹，再決定交易信與行銷信各自交給哪個服務。
第一個基礎：不要只靠主機預設寄信
WordPress 能呼叫主機的寄信功能，不代表這條路徑適合重要交易郵件。如果主機沒有完整設定寄件驗證、寄信紀錄與退信處理，發生問題時很難知道卡在哪裡。
對有訂單、會員與課程權限的網站，通常會改用專門的 SMTP 或郵件 API 服務，讓寄送可以被驗證、記錄與監控。選服務時不要只看「能不能寄」，也要看能不能使用自己的寄件網域、是否支援網域驗證、是否有退信與延遲狀態，以及遇到失敗時能不能看到可讀的錯誤資訊。
第二個基礎：寄件網域要完成 SPF、DKIM、DMARC 規劃
Google 的 Gmail 寄件者規範目前要求所有寄件者至少設定 SPF 或 DKIM；若一天寄送接近或超過 5,000 封到個人 Gmail 帳號，則要符合更完整的大量寄件者要求，包括 SPF、DKIM 與 DMARC。Google 也建議寄件者把這些驗證完整做好。
- SPF：告訴收件方哪些郵件伺服器可以代表你的網域寄信。
- DKIM：用數位簽章讓收件方確認信件確實由授權服務寄出，而且內容沒有在途中被竄改。
- DMARC：建立寄件身份對齊與處理規則，也能協助你看見網域被冒用或驗證失敗的情況。
Brevo 的官方文件也把寄件網域驗證、DKIM 與 DMARC 放在到達率與防冒用的核心設定裡。其他郵件服務名稱不同，但原理相近。
第三個基礎：寄件地址要和你能控制的網域一致
課程網站如果用自己的品牌網域寄送，比拿免費 Gmail／Yahoo 地址去假裝代表網站網域更容易做完整驗證。重點不是一定要使用某一種子網域，而是寄件身份、驗證紀錄與實際寄送服務要一致。
如果同時使用多個服務寄信，例如交易信由 A 服務、電子報由 B 服務，就要確認合法來源都有完成必要驗證。新增寄送服務時，也要重新檢查既有交易信是否仍能正常通過。
驗證通過，不代表寄件信譽一定良好
SPF、DKIM、DMARC 可以證明寄件身份與授權，但收件平台還會綜合判斷寄送行為。
如果一個新網域突然大量寄信、退信率高、很多人標記垃圾郵件，或長期對無效地址持續寄送，即使 DNS 驗證都正確，信件仍可能被延遲、拒絕或送進垃圾郵件。
因此寄件網域上線後要維持穩定的寄送方式。交易郵件依真實事件觸發，行銷名單則要有合理來源與退訂機制；不要為了「測試到達率」反覆對同一批地址大量重送。
不要把「已接受寄送」當成「已到收件匣」
郵件服務顯示 sent 或 accepted，通常只能證明服務已接受寄送任務。後面仍可能發生延遲（deferred）、退信（bounce）、地址不存在、驗證失敗、被收件方拒絕，或送達後被分類到垃圾郵件。
因此重要交易信最好保留最少必要的寄送紀錄，例如收件人、訊息 ID、寄送時間、狀態與錯誤原因。這不是為了蒐集更多資料，而是當學員說「沒收到」時，有辦法判斷問題在哪一段。
到達率不是只靠 DNS，寄件行為也會影響
網域驗證做好，只是基本門檻。Google 的寄件者規範同時要求寄件者控制垃圾郵件率、使用安全連線、遵守郵件格式等規範；大量寄件者還有更完整的要求。
- 不要把來源不明的陌生名單直接大量寄送。
- 處理永久退信，不要對不存在的地址一直重試。
- 行銷郵件要有合理的退訂方式。
- 交易信內容保持清楚，不夾帶大量不必要促銷。
- 不要在短時間突然用新網域寄出遠高於平常的信量。
重試要有邊界，不能遇到錯誤就一直寄
郵件服務遇到暫時性錯誤時，系統可能會延遲後重試；永久退信則代表地址或收件條件有明確問題。這兩種情況不應該使用同一種處理方式。
可靠性設計的原則是：暫時性失敗可以有限度重試，永久失敗要停止並留下可查狀態。無上限的重試不會讓郵件更可靠，反而可能增加重複寄送、寄件信譽與客服問題。
網站管理者不一定要自己寫重試程式，但要知道目前使用的郵件服務如何處理 deferred、bounce，以及是否能看得到最終結果。
交易信裡的寄件人、品牌與連結最好保持一致
學員剛付款後收到的信，如果寄件人是一個陌生名稱、內文品牌和網站不同、按鈕又跳到另一個完全不熟悉的網域，很容易增加疑慮。
- 寄件人名稱使用學員認得的品牌。
- 寄件地址使用已驗證的網域。
- 主要連結導向正確網站或可信任的必要服務。
- 不要使用過期、測試站或錯誤環境連結。
- 回覆地址如果顯示可回覆，就要有人能處理。
這些細節未必直接決定郵件是否進收件匣，但會直接影響學員收到信後敢不敢點、知不知道下一步。
另外，測試站與暫存站不要毫無限制地使用正式寄件設定。測試流程可以使用指定測試收件人、測試模式或受控環境，避免開發過程大量觸發正式交易信，讓學員誤收通知，也讓正式寄送紀錄變得難以判讀。
課程網站至少要驗收這 6 種信
| 測試情境 | 要確認什麼 |
|---|---|
| 新訂單 | 訂單確認是否送達、內容是否正確 |
| 新會員 | 帳號建立與密碼設定入口是否可用 |
| 購課完成 | 課程入口與下一步是否清楚 |
| 忘記密碼 | 重設連結能否正常送達與使用 |
| 付款異常 | 通知是否能正確對應訂單與補款方式 |
| 客服測試 | 不同信箱服務能否收到，錯誤能否被查到 |
購買後的信件順序與內容，可以再搭配學員購課後第一封歡迎信怎麼寫？一起規劃。
不要只測自己的 Email，要測不同收件環境
如果你只用自己的同網域信箱測試，很容易得到「我收得到，所以沒問題」的結論。正式上線前，至少準備幾個不同郵件服務的測試信箱，走完訂單、帳號、密碼與課程入口流程。
測試時除了看有沒有收到，也要看是否進垃圾郵件、寄件人名稱是否正確、連結是否可點、手機版是否容易找到主要動作，以及回覆地址是否真的有人能處理。
這和一般網站功能測試一樣：設定頁顯示成功，只能證明設定存在，不能證明使用者端的結果。
Email 失敗時，網站要有第二條路
交易郵件很重要，但課程交付不能只剩 Email 一條路。
付款完成頁可以直接說明下一步；會員中心應該有可找到的登入入口；密碼忘記時可以重新發送；客服也應該能查訂單、會員與課程權限。
這就是系統可靠性的概念：外部郵件服務出現延遲時，整個學員旅程不應該完全停住。
付款完成後的訂單、帳號與開課流程，可以延伸看付款完成後不要斷線：訂單確認、帳號建立與開課通知怎麼接起來。
寄不到時，依序查這 5 層，比一直重寄更有效
- 觸發：網站有沒有真的產生這封通知。
- 寄送：SMTP／API 服務有沒有接受。
- 驗證：SPF、DKIM、DMARC 是否正常。
- 收件：是否退信、延遲或被拒絕。
- 收件匣：是否進垃圾郵件或其他分類。
如果每次沒收到都只是按「重新寄送」，你只是在重複同一條可能已經壞掉的路徑。先知道哪一層失敗，再決定要重送、修網域、換地址，還是處理郵件服務問題。
把關鍵通知整理成一張寄信責任表
如果網站有訂單、會員、課程、CRM 與不同郵件服務，最好把關鍵通知整理成一張簡單責任表。至少記錄「哪個事件觸發、由哪個系統產生、哪個服務寄出、失敗時去哪裡查」。
例如訂單確認由訂單系統觸發、密碼重設由會員系統觸發、開課通知由課程流程觸發。這樣學員說沒收到信時，不需要先猜是哪個外掛，也能避免兩套系統同時寄出重複通知。
這張表不用很複雜，但每次新增外掛、改寄件服務或換網域時，都應一起更新。通知流程改了，責任表沒有跟著改，之後排錯還是會回到靠記憶。
常見問題
WordPress 能寄信，還需要 SMTP 嗎？
不一定每個網站都必須用 SMTP，但有訂單、會員與課程通知時，使用可驗證、可記錄狀態的專業寄送服務通常更容易維護與排錯。
設定 SPF 就夠了嗎？
不建議只停在 SPF。Gmail 對所有寄件者有基本驗證要求，對大量寄件者則要求 SPF、DKIM、DMARC；實務上應依目前使用的郵件服務與收件平台規範完整設定。
DMARC 一開始就要設成 reject 嗎？
不一定。先確認所有合法寄件來源都有正確通過與對齊，再依網域風險與郵件服務建議調整政策。不要在還沒盤點寄件來源時直接把合法郵件一起擋掉。
交易郵件可以順便放促銷內容嗎？
必要服務通知最好以完成交易或交付任務為主。過多促銷會讓訊息焦點模糊，也可能讓交易信與行銷信的管理邏輯混在一起。
寄送紀錄顯示 delivered，為什麼學員還說沒收到？
Delivered 通常代表收件方郵件伺服器已接受，不一定代表信件出現在主要收件匣。還要請對方檢查垃圾郵件、分類頁籤與搜尋寄件人。
需要把交易信和電子報完全分成兩個網域嗎？
不是所有網站都需要。重點是用途、寄送服務、驗證與信譽管理要清楚；當寄送量、團隊或風險增加時，再評估是否使用不同子網域或寄送流。
通知信不是網站附加功能，而是交付鏈的一部分
課程通知信的可靠性，會直接影響付款後的第一印象與學員能不能順利開始。
先把網站觸發、專業寄送服務、寄件網域驗證、寄送紀錄與備援入口規劃好。這樣當有人說「我沒收到信」時，你不需要靠猜，也不會只剩下重寄一次看看。
能知道信在哪一層失敗、能快速恢復學員的下一步，才是一套可長期營運的課程網站通知流程。
參考資料：
Google Gmail Help｜Email sender guidelines。
Google Gmail Help｜Email sender guidelines FAQ。
Brevo Help｜Authenticate your domain with Brevo。