Cloudflare Email Routing：用你的網域別名管理註冊信箱

Cloudflare Email Routing 適合用來管理網域別名：信件寄到 shop@yourdomain.com 或其他自訂地址後，再轉寄到同一個主要信箱 (allen@gmail.com)。

這種做法不需要為每個服務建立獨立信箱，也能在某個地址開始收到垃圾信時，快速找出來源並單獨停用。本文只聚焦 Email Routing 的設定與維護，不延伸介紹 Cloudflare 的其他產品。

Email Routing 是代收轉寄服務，不是完整信箱。本文以 2026 年 10 月 Cloudflare 官方文件為準；控制台名稱和方案限制仍可能調整。

Email Routing 能做什麼

Email Routing 是「代收再轉寄」，不是完整的信箱服務。Cloudflare 會接收寄到你網域的信件，再依規則轉發到已驗證的目的地址。它不提供一般信箱的收件匣、SMTP 寄信或完整郵件管理介面。

這種模式適合幾種用途：

• 為購物、論壇、軟體服務各自使用一個地址，方便追蹤資料來源。
• 為個人網站建立 shop@yourdomain.com 等公開地址。
• 某個別名開始收到垃圾信時，單獨停用或丟棄，不必更換主要信箱。

這裡所謂的「無限別名」，是指 Catch-all 可以接住任意前綴，不是建立了無限個獨立信箱，也不代表可以繞過服務商的寄信或反垃圾郵件限制。

建立網域與目的地址

1. 準備網域和目的信箱

你需要一個由 Cloudflare 管理 DNS 的網域，以及一個實際收信的目的地址，例如 Gmail 或公司信箱。網域註冊費仍要支付；Email Routing 的接收轉寄與已驗證目的地址在目前方案中可使用免費額度，但不代表網域、其他 Workers 或郵件寄送功能都免費。

如果網域目前已有郵件服務，先確認 MX 記錄。Email Routing 需要接管收信的 MX 記錄，與既有 Google Workspace、Microsoft 365 或其他郵件主機通常不能同時當作同一網域的主要收信入口。要保留既有郵件服務時，應先設計子網域，例如 inbox.example.com，不要直接改根網域。

2. 在控制台啟用 Email Routing

1. 登入 Cloudflare Dashboard。
2. 選擇帳號與網域，前往 Compute > Email Service > Email Routing。
3. 選擇 Get started 或 Onboard domain。
4. 在 Destination addresses 新增主要收件信箱。
5. 開啟目的信箱收到的驗證信，完成驗證。

完成驗證後，Cloudflare 會在網域上建立收信所需的 MX 記錄，並依 Email Routing 的需求加入 SPF TXT 記錄。若頁面提示 DNS 記錄與既有設定衝突，不要直接覆蓋；先確認目前網域是否已經有其他郵件服務。

官方步驟可參考 Route emails 與 Email Routing pricing。

建立第一條轉寄規則

Cloudflare 官方的基本流程是先建立一條指定地址的轉寄規則。Catch-all 是額外的全域規則，會接收寄到網域、但沒有符合其他規則的地址；不需要接收所有未知地址時，不應直接開啟它。

1. 在 Cloudflare Dashboard 前往 Compute > Email Service > Email Routing。
2. 選擇要建立地址的網域。
3. 開啟 Routing Rules 分頁。
4. 點擊 Create routing rule。
5. 在 Email pattern 輸入地址的 local part。例如要建立 service@example.com，輸入 service，再選擇 example.com。
6. Action 選擇 Send to an email。
7. 在 Destination 選擇已驗證的目的地址。
8. 點擊 Save。

Routing rules 頁面可以查看 Catch-all 與個別地址規則的啟用狀態。

需要時再啟用 Catch-all

如果確實要讓所有寄到該網域的地址都轉寄到同一個目的地：

1. 在 Email Routing 頁面開啟 Routing Rules。
2. 將 Catch-all rule 啟用，確認狀態顯示為 Active。
3. 在 Catch-all 的 Action 下拉選單選擇要執行的動作，例如 Send to an email。
4. 按下 Save。

Catch-all 不需要另外輸入每個別名的 local part；它會處理未被其他規則匹配的地址，也包含拼字錯誤或尚未建立的地址。若只想管理幾個固定別名，維持 Catch-all 關閉，使用上面的個別轉寄規則即可。

測試時，請從不同於目的地址的另一個信箱寄信到新建立的地址，例如 service@example.com，再到目的信箱確認是否收到轉寄內容。部分郵件服務商會丟棄「從同一個帳號寄出、又轉寄回同一個帳號」的測試信。

垃圾信處理與資料外洩判讀

當某個別名收到與原本用途無關的廣告或詐騙信時，先查看郵件的 To、Delivered-To 或原始郵件標頭，確認信件實際送達哪個別名。這可以提供線索，但不能直接證明某個平台發生資料外洩，因為地址也可能被猜測、爬取或由合作夥伴取得。

確認不再需要的別名後，在 Routing Rules 建立較高優先序的規則，將該地址的 Action 設為 Drop。先用測試信確認規則順序，再停用 Catch-all；否則停用 Catch-all 會連未列出的其他地址一起收不到。

自訂規則可以指定收件地址、轉寄目的地，或改用 Drop 丟棄信件。

另外，Email Routing 只處理收件與轉寄。你在 Gmail 直接按回覆時，寄件人通常仍會是 Gmail 地址；若需要用網域地址寄信，必須另外配置 Gmail「以其他地址寄送」、SMTP 或 Cloudflare Email Sending，並處理 SPF、DKIM、DMARC 與寄件信譽。不要把 Email Routing 當成寄信服務。

常見故障與回復方式

收不到信

先檢查目的地址是否完成驗證，再檢查網域 MX 是否指向 Cloudflare 的郵件服務。若最近切換過 Google Workspace 或其他郵件供應商，確認 DNS 沒有殘留互相衝突的 MX 記錄。接著查看 Email Routing 的活動紀錄與寄件端的退信內容。

Catch-all 沒有命中

確認 Catch-all 狀態是 Active，再確認是否有一條更具體的規則先匹配該地址。測試時不要只寄到已經存在的自訂規則地址，應使用新的隨機前綴。

轉寄後被 Gmail 丟進垃圾信

這通常是原始寄件信譽、轉寄鏈或郵件驗證造成，不是重新設定 SPF 就能解決。保留原始標頭、檢查 SPF/DKIM/DMARC 結果，必要時在收件端建立合理的篩選規則；不要為了讓信件進收件匣而全面放寬垃圾郵件防護。

要停用或回復既有郵件服務

先記錄原本的 MX、TXT 與相關郵件設定，再停用 Email Routing，最後恢復原 MX。DNS TTL 期間仍可能有郵件送往不同入口，因此切換前後要保留觀測時間，不要在同一時間刪除所有記錄。

一個可維護的使用方式

把每個別名當成一個可撤銷的識別碼，而不是永久信箱。建議至少維護一份簡單清單，記錄：

• 別名與註冊服務。
• 建立日期與用途。
• 是否仍在使用。
• 最近一次收到異常信件的日期。
• 停用或 Drop 的原因。

每月檢查一次轉寄活動紀錄，統計未知寄件者、被停用別名的命中次數，以及重要通知是否仍能正常送達。這些數據比「我好像少收到垃圾信」更適合用來判斷設定是否有效。

結語

如果你的目標是管理註冊信箱，從一個子網域、一個已驗證目的地址和一條 Catch-all 規則開始就夠了。先確認收信、轉寄和停用流程都正常，再逐步增加自訂規則，日後維護會比較單純。