Cloudflare Email Routing 可把寄到自訂網域地址的來信轉送到現有信箱，例如將網站聯絡地址轉寄至日常使用的郵箱。它適合收信和地址分流，但不等同完整電郵主機：一般轉寄規則不能讓你直接以該網域地址寄信或回覆。設定前要先決定收件、寄件和回覆的實際需要。
先確認網域使用 Cloudflare DNS
Email Routing 需要網域由 Cloudflare DNS 管理。開始前檢查名稱伺服器已生效、DNS 紀錄正常，並保存現有 MX、SPF 和 DKIM 資料。若網域目前已有 Google Workspace、Microsoft 365 或其他郵件主機，不應直接覆蓋 MX。
了解轉寄與郵箱託管的差別
轉寄服務接收指定地址的來信，再送到另一個已存在的目的地信箱；它不提供獨立收件匣、IMAP、行事曆或完整寄件身份。若團隊需要多人共享信箱、從網域地址回覆和保存郵件，應評估正式郵件服務。
新增並驗證目的地地址
先在 Email Routing 的 Destination Addresses 加入真正接收郵件的地址。系統會寄出驗證信，收件人必須點擊確認，路由規則才可啟用。未驗證的目的地保持停用，刪除目的地亦會令依賴它的規則失效。
讓平台建立必要 DNS 紀錄
網域上線流程會加入接收郵件所需的 MX，以及用於驗證的 SPF 和 DKIM TXT 紀錄。新增前先檢查有沒有舊 MX 或現有 SPF；同一網域不應建立多條互相衝突的 SPF 紀錄。若已有郵件服務，先規劃遷移而非同時競爭。
建立第一條自訂地址規則
在 Routing Rules 建立地址模式，例如聯絡、支援或帳單，再選擇已驗證目的地。每條規則應有清楚業務用途，不要建立難以辨認的大量隨機地址。同一地址模式若有多條規則，通常只會由清單中較前的一條處理。
Catch-all 要審慎啟用
Catch-all 可接收所有未被明確規則匹配的地址，方便捕捉拼寫變體，但也容易收取大量垃圾郵件和字典式攻擊。小型網站可先只建立必要地址；若啟用 Catch-all，應將目的地設在有良好垃圾郵件過濾的信箱。
使用不同帳戶完成寄信測試
從另一個外部郵箱寄信到新地址，不要由目的地信箱寄給自己，因為部分供應商會合併對話或丟棄看似自我轉寄的郵件。測試普通文字、HTML、附件和不同寄件平台，並記錄實際送達時間。
檢查原始郵件與垃圾郵件夾
若信件未出現，先檢查垃圾郵件、隔離區和目的地規則，再查看 Email Routing 活動。原始標頭可顯示收信路徑、SPF、DKIM 和 DMARC 結果。不要因單封郵件延誤便重複建立同一規則或反覆修改 MX。
回覆時會顯示目的地地址
一般 Email Routing 不支援直接從 Cloudflare 網域地址寄信或回覆。按「回覆」後，寄件人通常會是你的目的地郵箱，而不是收件時的自訂地址。若必須保持品牌寄件身份，要另外設定支援該網域的 SMTP 或完整郵件服務。
留意 DMARC 對轉寄的影響
郵件轉寄會改變傳送路徑，寄件網域若採用嚴格 DMARC 政策，部分郵件可能無法通過目的地供應商檢查。遇到特定寄件者持續失敗時，查看驗證結果和轉寄紀錄，不要把所有郵件安全檢查全面關閉。
不要把網站寄信交給轉寄規則
WordPress 表單通知、訂單郵件和密碼重設屬於寄出郵件，應使用可靠 SMTP 或交易郵件服務。Email Routing 主要處理寄入網域的郵件，不能修正 WordPress 的寄信驗證、退信或送達率問題。
規劃多人與離職交接
地址規則應記錄用途、負責人和目的地。員工離職時先驗證新目的地，再更改規則並測試，不要直接刪除舊目的地令所有相關地址停用。若一個地址需要轉寄到多個目的地，可能要用 Email Worker 處理。
定期測試重要地址
每月由外部帳戶測試聯絡、支援、帳單和私隱地址，確認驗證狀態、DNS 和目的地過濾仍正常。網域轉移、SPF 修改或郵箱政策更新後亦要重測。收不到重要通知通常比網站頁面錯誤更難即時發現。
結語
Email Routing 的可靠流程是：確認 DNS 沒有現有郵件衝突、驗證目的地、建立精確地址規則、用外部郵箱測試，再清楚規劃寄件身份。把它視為收件轉寄層，而不是完整郵件主機，便能避免回覆地址和送達預期落差。
