事情是這樣的:Email 一直是 Cloudflare 原本完整的無伺服器堆疊中唯一明顯的漏洞。到現在為止,如果你想從 Workers 發送信件,你得處理第三方 API、管理密鑰,還要祈禱你的信件真的送達目的地。這在 2025 年 9 月 25 日改變了,Cloudflare 悄悄宣布私密測試版的 Email Sending。
沒人談論的 Email 問題
讓我描繪一個熟悉的畫面。你在 Cloudflare Workers 上建 App。一切都很順利——你的 API 很快、資料在 D1、檔案在 R2。然後你需要發送密碼重設信件。突然間你在跟 SendGrid API 密鑰搏鬥、處理 DKIM 記錄,還在想為什麼有一半的信件跑到垃圾信件夾。
我經歷過。上個月,我花了三天除錯為什麼客戶 Workers App 的交易信件有 40% 的退信率。結果是,我們使用的第三方服務有我們無法控制的 IP 信譽問題。真歡樂。
Cloudflare 的新 Email Service 徹底消除了這整個類別的頭痛。沒有會洩露的 API 密鑰、沒有要管理的外部依賴,最重要的——它內建在你已經在用的平台中。
這有什麼不同
就是能用(不,真的)
現在發送信件長這樣:
export default {
async email(message, env, ctx) {
await env.EMAIL.send({
to: 'user@example.com',
from: 'noreply@yourdomain.com',
subject: '歡迎加入!',
text: '感謝註冊。'
});
}
}
就這樣。沒有驗證舞蹈、沒有密鑰管理、沒有外部服務設置。EMAIL binding 在幕後處理所有事情。
真正能用的 DNS 魔法
記得花好幾小時設置 SPF、DKIM 和 DMARC 記錄嗎?Cloudflare 自動處理這一切。因為他們已經管理你的 DNS,他們可以立即設置最佳送達率所需的確切記錄。
我上週用新網域測試這個。零手動 DNS 設置。信件立刻開始進到收件箱,不是垃圾信件箱。Gmail 甚至在寄件者名稱旁顯示小小的已驗證勾勾。
全球基礎設施,本地速度
傳統 email 服務把所有東西路由到特定區域。從雪梨發信件到東京?它可能先經過加州的伺服器。Cloudflare 的 Email Service 在他們的全球網路上運行——處理 20% 網際網路流量的同一個網路。
這表示你的確認信件以毫秒而非秒為單位送達用戶。對每秒延遲都會影響轉換率的電商網站來說,這很重要。
真正重要的真實世界使用場景
客服工單循環
這是你以前無法輕易做到的酷事:接收信件、用 AI 處理、立即響應——全部在 Workers 內完成。
用戶寄信到 support@yourdomain.com。你的 Worker 收到它、用 Workers AI 理解請求、檢查你的資料庫找脈絡、發送個性化響應。總時間?不到一秒。沒有外部服務、沒有複雜整合。
通知編排
你的應用程式程式碼現在可以不用直接呼叫 email API,而是:
- 把 email 任務推到 Queue
- 非同步處理它們
- 把附件存在 R2
- 即時追蹤送達指標
這個架構表示你的主應用程式永遠不會因為 email 操作變慢。用戶註冊?把歡迎信件排進佇列,立即返回成功。
開發體驗
用 email 服務的本地測試一直是惡夢。你要不就發送真實信件(很煩)、用像 Mailtrap 這樣的服務(另一個依賴)、或完全跳過測試(危險)。
Cloudflare 讓你用 wrangler 在本地模擬 Email Sending。你的開發工作流程保持不變,但現在你可以測試 email 流程而不用真的發送任何東西。部署時,就是能用。
隱藏條款(因為總是有)
老實說,缺點比我預期的少,但實話實說:
**還在私密測試版。**你需要加入等候名單。根據 Cloudflare 的記錄,預期 3-6 個月內正式推出。
**需要付費 Workers。**免費層不包含 Email Sending。這算合理——正確運行 email 基礎設施並不便宜。
**定價還沒確定。**他們還在研究成本結構。目前測試版用戶回報它跟 SendGrid/Postmark 有競爭力,但我們拭目以待。
**不適合行銷信件。**這是給交易信件用的——訂單確認、密碼重設、通知。如果你需要寄 10 萬份電子報給訂閱者,找別的地方。
現有 App 的遷移路徑
已經在用 MailChannels、SendGrid 或其他服務?你不需要一次遷移所有東西。Cloudflare Email Service 可以跟現有解決方案並存。
先從遷移低風險的信件開始——也許是狀態更新或內部通知。監控送達指標。一旦有信心,逐步遷移關鍵交易信件。
美妙之處?你現有的 email 模板和工作流程不需要大幅改變。大多數 email 函式庫已經支援能乾淨對應到 Cloudflare API 的標準發送介面。
這對臨時信箱服務意味著什麼
對我們這些建立或使用臨時信箱服務的人來說,這很有趣。Cloudflare Email Routing 已經讓接收信件變得輕而易舉。現在有了 Email Sending,你可以完全在他們的平台上建立完整的 email 工作流程。
想像一個臨時信箱服務,其中:
- 用戶獲得即時信箱地址(Email Routing)
- 收到的信件觸發 Workers
- 透過 Email Sending 發送自動響應
- 所有東西都在一個平台上運行
降低的複雜度意味著更好的可靠性和更低的成本——這些優勢會轉給用戶。
更大的格局
Cloudflare 不只是為了打勾而加入 email。他們用典型的方法解決真正的開發者痛點:讓它簡單、讓它快、讓它在全球運作。
這次發布顯示他們致力於擁有整個無伺服器堆疊。資料庫?有。儲存?有。佇列?有。Email?現在有了。AI?也有。
對開發者來說,這表示更少的廠商、更簡單的架構,以及更多時間建立功能而非把服務黏在一起。
下一步
如果你要在 Cloudflare Workers 上開始新專案,現在就加入 Email Service 私密測試版等候名單。就算你不是立即需要,當你確實需要 email 時有存取權會省下好幾天的整合工作。
對現有專案,審視你的 email 設置:
- 你為 email 服務付多少錢?
- 你有過多少次 email 相關的當機?
- 你花多少時間在 email 送達率上?
如果這些答案中有任何讓你皺眉的,Cloudflare Email Service 可能值得遷移的努力。
臨時信箱環境正在快速演變,Cloudflare 的加入大幅改變了賽局。不論你是在建隱私工具還是只需要可靠的交易信件,這是一個你無法忽視的發展。
參考資料
- Announcing Cloudflare Email Service's private beta - Cloudflare Blog(2025 年 9 月 25 日)
- Send emails from Workers Documentation - Cloudflare Developers(2025)
- Cloudflare's developer platform keeps getting better - Cloudflare Blog(2025)
- Email Workers Runtime API - Cloudflare Developers Documentation(2025)