觀點 · 資訊分享
Cloudflare Email Service 開放 SMTP 寄信（beta）：舊網站不改程式架構也能接
Cloudflare Email Service 在 6 月 8 日新增經過驗證的 SMTP 寄信通道，成為繼 REST API、Workers 綁定之後的第三種方式。Nodemailer、PHPMailer 等現成函式庫改個設定就能用。
- 發布
- 2026-06-08
- 篇幅
- 約 3 分鐘 · 1,472 字
- 結構
- 8 節 + 3 題常見問題
- 標籤
一句話看懂：Cloudflare 的寄信服務新增 SMTP 通道，已經會用 SMTP 寄信的網站，只要換掉主機與帳密就能接上，不必改寫成 API 呼叫。
先用白話講：SMTP 是什麼？
想像寄實體信：你可以自己跑去郵局櫃檯寄（用 API 呼叫），也可以請里長伯代收（Workers 綁定），而 SMTP 就像是全世界郵局都認得的「投遞窗口」，所有現成的寄信程式都知道怎麼把信丟進去。
Cloudflare 的 Email Service 原本提供兩種寄信方式，這次多開了一個最通用的窗口：SMTP。
發生什麼事
Cloudflare 在 6 月 8 日的更新日誌宣布，Email Service 以 beta 形式支援經過驗證的 SMTP 寄信。官方形容 SMTP 是繼 REST API 與 Workers 綁定之後，寄交易郵件（驗證信、通知信、收據這類）的第三種方式，特別適合：
- 已經在用 SMTP 的既有應用程式
- 語言內建的 SMTP 函式庫，例如 Nodemailer、smtplib、PHPMailer、JavaMail
設定值整理
| 項目 | 內容 |
|---|---|
| 主機 | smtp.mx.cloudflare.net |
| 連接埠 | 465（隱式 TLS） |
| 驗證方式 | PLAIN 或 LOGIN |
| 帳號 | api_token |
| 密碼 | Cloudflare API token（帳號擁有或使用者擁有皆可），需 Email Sending: Edit 權限 |
用 SMTP 寄出的信，會進入跟 REST API、Workers 綁定相同的寄送管線：限制一樣、自動 DKIM 與 ARC 簽章、後台紀錄共用。
三種寄信方式怎麼選？
- REST API：從任何後端程式直接呼叫，適合新專案
- Workers 綁定：寄信的程式本身就跑在 Cloudflare Workers 上時最直接
- SMTP：舊系統、現成的網站套件或函式庫已經會用 SMTP 時，換設定就能用，不必改程式邏輯
三者共用相同的限制與紀錄，差別只在「怎麼把信交給 Cloudflare」。以上的使用情境整理是依官方描述自行歸納。
給開發者的技術細節
官方給的一行指令測試方式，如下（<API_TOKEN> 請換成自己的權杖，別貼進程式碼或版本控制）：
curl --ssl-reqd \
--url "smtps://smtp.mx.cloudflare.net:465" \
--user "api_token:<API_TOKEN>" \
--mail-from "[email protected]" \
--mail-rcpt "[email protected]" \
--upload-file mail.txt
- 寄件網域的設定細節、回應代碼與各語言範例，官方放在 SMTP 參考文件，這則公告沒有展開
- 目前是 beta，限制與穩定度可能還會調整
- 權杖只給 Email Sending: Edit 這類最小需要的權限，放在環境變數，不要寫死在程式裡
我的看法
接案時最常見的情況是：客戶的舊網站早就用 SMTP 在寄註冊信與通知信，要換寄信服務，最麻煩的不是申請帳號，而是改程式。SMTP 這條路讓「換個主機與帳密」就能試用，成本低很多。
不過它還在 beta，我不會一次把所有信都切過去。比較穩妥的做法是先挑非關鍵的信件（例如內部通知）跑一陣子，確認送達率與後台紀錄都正常，再把驗證信、收據這類重要信件慢慢搬。
名詞小辭典
- SMTP：寄送電子郵件的標準協定。
- 交易郵件：由系統自動寄出的信，例如驗證碼、訂單通知。
- DKIM：替信件加上數位簽章，證明信確實來自該網域。
- ARC：信件被轉寄時保留原始驗證結果的機制，降低被誤判為偽造的機率。