域名郵箱實操：Cloudflare Email Routing 免費轉發（2026）
一句話結論：Email Routing 是免費轉發規則，不是郵箱：域名託管在 Cloudflare DNS 上後，發到域名下某地址的郵件會轉到已驗證的目標郵箱；發信另配，限制是每域名 200 條規則、每賬號 200 個目標地址、單封入站 25MiB。
這是什麼：轉發不是郵箱
Email Routing 只做一件事：收到發往域名下某地址的郵件，按規則轉到已驗證的目標郵箱。它沒有收件箱，不存郵件，沒有可登入的網頁郵箱；目標郵箱滿了、被封了，轉發的郵件就沒有地方去。它也不管發信：官方文件寫明，Email Routing 不支援從域名發信或回覆，回覆會從目標地址發出。收信與發信是兩條分開的鏈路，分開配置。
這條路線適合對外地址掛在自有域名下、實際收信仍在已有郵箱、願意自己維護 DNS 與規則的人；需要多人共用收件箱、長期存檔，或直接以域名地址回信且不願另配發信服務時，不適合。三種路線的對照，見海外郵箱對比文章。
前提：域名託管在 Cloudflare DNS 上
前提是域名使用 Cloudflare DNS：轉發靠寫入 DNS 記錄實現，域名不在 Cloudflare DNS 上，入駐無法完成。還需要一個已有郵箱作為目標地址。域名註冊費另付，轉發在 Workers 免費與付費計劃上都可用，入站郵件數量不限。
域名已有其他服務商的 MX 記錄時，入駐會失敗，報錯為存在非 Cloudflare 的 MX 記錄，錯誤程式碼 2008：Email Routing 要求獨佔根域名的 MX 記錄，不能與另一家郵箱服務共用同一域名。切換前備份現有 DNS 記錄，確認舊郵箱沒有未處理的重要郵件，再入駐。
啟用步驟：入駐域名
官方文件的入駐步驟只有四步。第一步，在 Cloudflare 控制檯進入 Compute、Email Service、Email Routing。第二步，選擇 Onboard Domain。第三步，從賬號裡選一個域名，可以複核 Cloudflare 將要寫入根域名的 DNS 記錄：MX 記錄，把入站郵件引向 Cloudflare；SPF 的 TXT 記錄，授權郵件轉發；DKIM 的 TXT 記錄，為轉發郵件提供認證。第四步，選擇 Done。域名入駐完成後，就可以開始配置轉發。
記錄由 Cloudflare 自動寫入，不需要手工抄寫；入駐後檢查 DNS 記錄頁，確認三類記錄都在，缺失時排障一節有補救步驟。域名解析與建站的關係，見Cloudflare 免費建站文章。
新增並驗證目標地址
建立轉發規則之前，必須先新增並驗證至少一個目標地址。目標地址在賬號級別管理，可以在賬號下的所有域名間複用：驗證一次，賬號下每個域名都能用它作目標地址。新增步驟是：進入 Email Routing 的 Destination Addresses 頁，在表單裡輸入目標地址並提交；Cloudflare 會向該地址發一封驗證郵件，開啟郵件並選擇驗證連結，地址才啟用。
未驗證的目標地址，指向它的規則都會保持停用，規則存在但不轉發。目標地址頁列出所有地址，包括待驗證的，可在那裡重發驗證郵件或刪除地址。驗證郵件沒收到時，先查垃圾資料夾，再重發。
建立自定義地址與 catch-all
規則由地址模式與動作組成：地址模式是域名下某地址的本地部分，動作決定郵件去向。建立步驟：選定域名，進入 Routing Rules 頁，選擇建立規則，填寫地址模式，在動作下拉選單裡選擇動作，在目標裡選擇已驗證的地址或 Worker，儲存。規則可隨時停用、編輯與刪除，停用後不再轉發，重新啟用後恢復。
動作有三種：發往郵箱，轉到目標地址，最常用；發往 Worker，交給 Worker 程式處理，適合自定義邏輯；丟棄，直接刪除匹配的郵件，適合想讓某地址看起來有效、實際不收信的場景。
catch-all 是兜底規則：啟用後，發往域名下所有地址的郵件都會被處理，包括拼錯的本地部分；例如發件人拼錯了一個字母，catch-all 啟用時這封郵件仍會被處理。啟用步驟：進入 Routing Rules 頁，把 catch-all 設為啟用，選好動作，儲存。catch-all 也會接住發往從未建立過的地址的郵件，包括垃圾郵件，啟用前想清楚是否需要兜底。
加號字尾是可選功能，在設定頁開啟。開啟後，加號字尾地址匹配基礎地址的規則：加號後部分不影響匹配，但保留在收件資訊裡，供 Worker 或活動日誌檢視；已存在具體加號字尾規則時，具體規則優先。加號字尾適合按來源區分地址，給不同服務各用一個帶字尾的地址，收信仍走同一條規則。
一個地址轉多人：用 Worker 逐個轉發
每條轉發規則只對應一個目標地址或一個 Worker，不能在一條規則裡直接寫多個目標地址。一個地址要轉給多人時，官方文件給出的做法是：用一個 Worker，對每個目標地址逐個呼叫轉發操作，所有目標地址必須事先驗證。Worker 路由的配置方式是：建立規則時動作選擇發往 Worker，再選擇對應的 Worker 程式。
代價是多一層程式：Worker 程式碼要自己寫、自己維護，出問題時多一個排查環節；免費計劃的 Worker 有 CPU 與記憶體限制，複雜處理可能超限失敗，失敗記錄在 Worker 日誌裡。人數不多時，每人一條規則更簡單；確實需要同一地址多人收信時，再用 Worker 路線。
發信怎麼解決：只收不發，發信另配
Email Routing 只管收信，不管發信：官方文件寫明，它不支援從域名發信或回覆；直接回復轉發來的郵件時，回覆從目標地址發出，對方看到的是目標地址。需要以域名地址發信時，有三條路。
第一條路是 Gmail 代發：在 Gmail 設定裡新增自有地址並驗證，寫信時在發件人一欄選擇該地址，最多 99 個。但這條路有時效：Google 已公告，自 2027 年 1 月起，Gmail 不再支援第三方郵箱地址的代發，Workspace 別名與本人擁有的其他 Gmail 地址不受影響；2026 年第三至第四季度為過渡期，可能限制新配置。域名地址按官方文字理解屬於第三方地址，同樣在終止範圍內，動手前先看幫助頁的當前狀態，不要把長期發信押在這條路上。
第二條路是其他發信服務：用桌面郵件客戶端或第三方發信服務，以域名地址發信。Google 幫助頁給出的常見安全連線組合是 SSL 配 465 埠、TLS 配 25 或 587 埠；各服務商的 SMTP 設定、埠與認證方式不同，按服務商的文件填寫，不要套用別家的引數。
第三條路是 Cloudflare 的 Email Sending 服務：2026 年 4 月進入公開測試，面向開發者發交易類郵件，需要 Workers 付費計劃，含每月 3000 封，超出部分每 1000 封 0.35 美元；發給已驗證目標地址的郵件在所有計劃下免費，不計入配額與每日上限。Email Sending 是程式呼叫的發信服務，面向應用發通知類郵件，不是給人手寫回信用的；未實測，以官方文件為準。
限制：200 條規則、200 個目標地址、25MiB
官方限制頁列出的數字如下，核查日期 2026-11-13，與本站已發文章口徑一致。
| 限制項 | 數值 | 說明 |
|---|---|---|
| 每域名轉發規則數 | 200 條 | 每條規則對應一個地址模式與一個目標 |
| 每賬號已驗證目標地址數 | 200 個 | 賬號下所有域名共用，須先驗證 |
| 單封入站郵件大小 | 25MiB | 超過會被拒收，不是截斷 |
| 每區配置域名數 | 30 個 | 轉發與發信域名合計，含根域名 |
| 入站郵件數量 | 不限 | 免費與付費計劃都一樣 |
| 發信服務單封收件人數 | 50 人 | 收件、抄送與密送合計 |
25MiB 是入站硬上限：超過的郵件在收信階段被拒收，目標郵箱裡不會出現。大附件改用網盤連結或檔案分享。規則數與目標地址數對個人使用很寬裕，200 條規則足夠按服務、按用途拆分地址；地址拆得太細時，維護成本先於上限成為瓶頸。
SPF、DKIM、DMARC 與轉發的關係
先講入站檢查：每封入站郵件都要經過 SPF、DKIM、DMARC 與 ARC 檢查，按發件域名的 DMARC 政策，未透過認證的郵件會被拒收，來自實時黑名單地址的郵件也會被拒收。轉發不是照單全收，發件域名的認證政策直接影響郵件能不能進入轉發鏈路。
再講轉發時的處理：郵件從 Cloudflare 的伺服器再次發出，目標伺服器看到的發件伺服器變了，不做處理時，原始發件域的 SPF 校驗可能失敗。Cloudflare 的做法分兩步：給轉發郵件加 ARC 封印，保留原始認證結果；用發件人重寫方案重寫信封發件人，改成 Cloudflare 控制的轉發域名，讓 SPF 在目標伺服器上透過。ARC 讓目標伺服器在 SPF 或 DKIM 因轉發失效時，仍能驗證轉發郵件的真實性。
SPF 記錄方面，入駐時 Cloudflare 會寫入一條 SPF 記錄，內容為包含 Cloudflare 發信域名的授權記錄，以軟失敗結尾。一個域名只能有一條 SPF 記錄，多條會讓郵件服務無法正常工作；已有其他服務的 SPF 記錄時，把授權合併進同一條，不要並排寫兩條。SPF 記錄的 DNS 查詢次數上限為 10 次，合併時注意查詢次數。
DKIM 記錄方面，入駐時 Cloudflare 會寫入 DKIM 記錄，轉發與發信服務用不同選擇器，轉發服務的選擇器名稱以 cf2024-1 開頭。記錄缺失時，到 Email Routing 設定頁找到轉發 DKIM 記錄，再到 DNS 記錄頁補上。校驗失敗時，官方排障建議包括：確認記錄存在、選擇器名稱正確、記錄裡沒有多餘空格或字元、等待 DNS 傳播，最長 48 小時。
DMARC 方面，DMARC 要求 SPF 或 DKIM 其中一項對齊：SPF 對齊指信封發件域名與發件人域名一致，DKIM 對齊指簽名域名與發件人域名一致。啟用發信服務時，若域名下還沒有 DMARC 記錄，Cloudflare 會加一條拒絕策略的記錄；已有則保持不變。收緊順序是：先用僅觀察策略，觀察報告幾周，再逐步收緊到隔離、拒絕；收緊前確認 SPF 與 DKIM 都已對齊。
排障：驗證郵件、DNS 生效、垃圾過濾
驗證郵件沒收到：先查垃圾資料夾，再到目標地址頁重發。規則已建但不轉發時，先看目標地址是否已驗證：未驗證會讓所有指向它的規則停用；規則本身被停用時，在規則頁切回啟用。
DNS 方面，記錄缺失時到 DNS 記錄頁檢查三類記錄是否齊全；SPF 記錄缺失時按官方排障頁給出的內容補上，名稱為根域名；DKIM 記錄缺失時到設定頁複製內容再補。DNS 改動需要傳播時間，DKIM 校驗最長等待 48 小時；等待期間不要反覆改記錄。
郵件被拒收時，分清發生在哪個階段：超過 25MiB 的在收信階段被拒收；未透過發件域名 DMARC 政策認證的在認證檢查階段被拒收；目標郵箱伺服器的錯誤會在會話內傳回發件伺服器。活動日誌裡有每封郵件的最終狀態，排查時先看日誌，再看目標郵箱。
垃圾過濾方面，活動日誌顯示已送達，只說明目標伺服器接受了郵件，之後進收件箱還是垃圾資料夾，由目標郵箱的信譽庫、垃圾過濾器與使用者反饋決定，認證全部透過也可能進垃圾資料夾。排查時檢視郵件原始內容的認證結果標頭；認證全部透過但仍被標記為垃圾時，問題出在域名信譽或郵件內容上，不是配置問題。
測試時用不同於目標地址的另一個郵箱賬號發測試信：有些服務商會丟棄看起來發自同一賬號的郵件，測試賬號不要用目標地址本人。目標收件箱沒看到時，先查垃圾資料夾，再查活動日誌。
成本與取捨
現金成本只有域名註冊費：轉發免費，入站不限量，目標郵箱用免費郵箱時，全年成本就是域名續費。省下的錢換來多一層配置與多一個故障點：DNS 記錄、轉發規則、目標郵箱、發信配置，任何一環出問題，收發信都會受影響；不願意維護 DNS 的人，實際成本並不低。
取捨的關鍵在發信：只收信、不回信的地址，轉發路線夠用；需要經常以域名地址回信時，發信服務要另外選好，並算上 2027 年 Gmail 代發終止的影響。重要驗證碼與通知類郵件，儘量直接發到獨立收件箱，不要只經過一層轉發。
侷限與未核實清單
本文未實測，步驟與數字來自官方文件原文，核查日期 2026-11-13，Cloudflare 可能隨時調整。未能核實：Email Sending 的實際表現與發信到達率；Email Routing 是否提供通用發信憑證（公開資料說法不一）；Gmail 代發在自定義域名地址上的完整表現；各目標郵箱的垃圾過濾表現；DNS 生效的具體時長（除 DKIM 校驗最長 48 小時外，未核實到統一數字）；轉發郵件在目標郵箱裡的顯示細節。配置前以官方文件為準，先用非關鍵地址測試收發。
2026-11-13：首發
相關：郵箱與電話號碼 · Cloudflare 免費建站 · 方法論