第 6 章：買完才發現——.dev 網域居然不能收信

買域名的慘痛教訓：從 bobochen.ai 到 .dev 的真實故事第 6 / 7 篇

本篇是「買域名的慘痛教訓：從 bobochen.ai 到 .dev 的真實故事」系列的第 6 / 7 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。

寫完前面五章，我以為這個系列已經收尾了——買域名的坑我都踩過了，建議也都給了，故事該結束了。

結果這個系列又長出了第六章。而且這次的坑，是我自己親手挖的。

背景：給 App 買了一個漂亮的子網域

最近我在幫自己的 Android App「AutoLaunch」做 landing page。這支 App 是排程自動啟動工具，準備上架 Google Play。

域名我沒猶豫——直接用系列主角 bobochen.dev 開了一個子網域：

autolaunch.bobochen.dev

子網域不用再買，DNS 加一筆 record 就有了，這正是我在第 4 章講的「多域名 vs 子網域策略」的好處。網站 deploy 上去、SSL 自動生效（.dev 強制 HTTPS，這點以後再聊），一切順得不得了。

我心想：「漂亮，這次學乖了，零成本擴充。」

然後我開始填 Google Play 的上架資料，填到「開發者聯絡 Email」那一欄——Play Console 要求一個能收信的客服信箱。

我很自然地打上：

support@autolaunch.bobochen.dev

打完那一刻我愣住了：這個信箱……真的收得到信嗎？

發現過程：買網域根本沒附信箱這回事

我去查了一下，然後被自己的無知打了一巴掌。

買域名，跟「擁有這個域名的 email」是兩件完全無關的事。

當你註冊一個域名，你拿到的是「這串名字的所有權」跟「設定 DNS 的權利」。如此而已。它不附帶任何信箱伺服器。

沒有人幫你架收信的伺服器（MX）
沒有人幫你存信
你在名片上印 support@yourdomain.dev，別人寄過來，信會直接彈回去或石沉大海

這不是 .dev 的問題，是所有域名都一樣。.com、.io、.tw 通通沒附信箱。我只是因為 .dev 看起來很「工程師」，下意識以為它什麼都包了。

更尷尬的是：這是一個上架卡關等級的問題。Google Play 那欄聯絡信箱不是裝飾品——審查被退、使用者客訴、政策通知，全部寄到那裡。如果我填一個收不到信的地址,等於把 App 的對外窗口直接關掉。

那要怎麼辦？傳統解法是去買 Google Workspace（一個帳號月費，要養一個信箱）。但我只是要一個轉發用的客服信箱，不需要一個完整的信箱帳號。殺雞用牛刀。

後來我找到那把剛好的剪刀：Cloudflare Email Routing。

解法：Cloudflare Email Routing，免費且 5 分鐘快速搞定

我的域名 DNS 本來就託管在 Cloudflare（這也是我第 4、5 章一直推薦的做法）。而 Cloudflare 有一個免費功能叫 Email Routing，專門解決「我想要 xxx@我的域名 但只想把信轉到現有 Gmail」這種需求。

⚠️ 2025 年中 Cloudflare 換了新版 Email Routing UI（舊版正在退場，進去可能會看到「You’re now using the new Email Routing UI」的提示）。網路上很多舊教學的截圖跟選單位置已經對不上，下面以新版介面為準。

3 分鐘快速上手

進入 Email Routing 登入 Cloudflare → 選你的域名 → 左側選單 Compute → Email Service → Email Routing → 點 Onboard Domain。
確認要加的 DNS 記錄（一鍵自動） 精靈會列出它要幫你寫進去的記錄——MX（把收信路由到 Cloudflare）、一筆 SPF(TXT) 和一筆 DKIM(TXT)（讓轉發出去的信通過驗證）。直接按 Done，Cloudflare 會自動寫好，你完全不用手刻 DNS。
設定目的地信箱（你的 Gmail） 切到 Destination Addresses 分頁，新增你的 Gmail，例如 mygmail@gmail.com。Cloudflare 會寄一封驗證信到那個 Gmail，點一下確認連結就完成綁定。

這一步是為了證明那個 Gmail 真的是你的，避免有人亂轉發給別人。
建立轉發規則 到 Routing Rules 分頁 → Create routing rule → 在 Email pattern 輸入要收信的名稱（例如 autolaunch）→ 右邊的網域下拉選你的域名 → 動作選 Send to an email，指定剛剛驗證好的 Gmail：
```
autolaunch@bobochen.dev  →  mygmail@gmail.com
```
或者懶人作法，開 Catch-all，把 *@bobochen.dev（任何地址）全部轉到你的 Gmail。

動作那欄你會看到另一個選項 Send to a Worker——那是把信丟進程式裡（Email Workers）處理，屬於進階玩法，純轉發用不到，本篇先略過（文末有延伸連結）。

😅 這裡又踩到第二個坑：Email Routing 不吃子網域。 我原本想用前面 Google Play 填的那個 support@autolaunch.bobochen.dev，結果到了 Create routing rule 這一步，Email pattern 右邊的網域下拉只有 bobochen.dev，根本選不到 autolaunch.bobochen.dev。

原因是 Email Routing 只在「zone」層級運作——你加進 Cloudflare 的 bobochen.dev 才是一個 zone，autolaunch.bobochen.dev 只是它底下的一筆 DNS record，不是獨立 zone，所以收不了信。

一句話記住：網站可以掛子網域，信箱只能掛根網域。 我只好把客服信箱改成 autolaunch@bobochen.dev（用前綴標記是哪支 App），再回頭把 Google Play 那欄一起改掉。

設定完，我寄了一封測試信到 autolaunch@bobochen.dev，原本預期應該幾秒後 Gmail 就「叮」一聲收到了，但是…

沒收到信？照這個順序查（我整個踩了一輪才搞懂）

這一段是我自己卡了快一小時、來回測了七八封信換來的。我把它整理成一條除錯路徑——從「最權威的證據」往「最容易被忽略的人為設定」走，照順序排除就好，不要一開始就亂改設定。

第一步：看 Cloudflare 的 Activity Log（唯一權威證據）

新版有一個 Activity Log 分頁，每封進來的信都記一筆 Result。先看這個，再決定問題在哪一端：

alt text

Activity Log 的 Result	意思	往哪查
完全沒有記錄	信根本沒進到 Cloudflare	`MX` 沒生效。`dig MX 你的域名` 要看到 `route1/2/3.mx.cloudflare.net`；新版若顯示 DNS records: Not configured，回去把 onboarding 的 DNS 那步按完。
`Dropped`	Cloudflare 收到了但沒轉	多半是目的地還沒驗證（Destination Addresses 要 `Verified` 不是 `Pending`），或規則沒生效。
`Forwarded` / `Delivered`	Cloudflare 已經把信交出去了，它沒問題	問題在收信端（Gmail）。往第二步走。

重點觀念：Forwarded 不等於「你收件匣看得到」。 它只保證 Cloudflare 把信交給了目的地的伺服器，之後信被收件端怎麼處理，Cloudflare 管不到。我卡最久就是誤把 Forwarded 當成「應該要收到」。

第二步：Result 是 Forwarded 卻收不到 → 是收信端 Gmail 的兩個陷阱

陷阱 A：你「從目的地 Gmail 自己寄給自己」測

我一開始用 me@gmail.com 寄到 autolaunch@bobochen.dev，而它又轉回同一個 me@gmail.com。Gmail 會把「自己寄給自己」的信判定為重複、不在收件匣顯示。

更坑的是：你去搜會發現「有一封欸」——但那其實是 Gmail 幫你留的 寄件備份（Sent）副本，不是轉發進收件匣的那封。看到它會讓你誤以為「自寄會通、外部信才有問題」，整個判斷被帶偏。

Cloudflare 知道這坑太多人踩，還會主動寄一封通知：標題叫 「Missing email from …@gmail.com to …?」，直接告訴你「信沒丟，是 Gmail 把自寄信去重了」。

alt text

✅ 解法：測試一律用「別的信箱」寄（手機另一個帳號、請朋友、或 mail-tester.com 順便驗 deliverability）。要翻出那封「消失」的自寄信，Gmail 搜 in:anywhere 會在「所有郵件」找到它。

陷阱 B：目的地那個 Gmail 帳號「自己」把信吃掉

排除自寄後我又踩第二層：改用一個完全外部的信箱（例如 someone@othercompany.com）寄，Activity Log 一樣 Forwarded，但 me@gmail.com 連 in:anywhere 都搜不到。

關鍵隔離測試：把轉發終點換成「不同供應商」。我改寄到一個會轉到 Yahoo 信箱的地址——秒收。

外部信箱 → hi@bobochen.dev → Yahoo 信箱        ✅ 秒收
外部信箱 → autolaunch@bobochen.dev → 某 Gmail  ❌ 消失

同一條 Cloudflare 規則、同一個寄件者，只差「終點信箱」就一個收得到、一個收不到——鐵證是那個 Gmail 帳號本身在吃信，跟 Cloudflare 完全無關。

而最後揪出來的真兇，是 Gmail 一個惡名昭彰的 POP 設定：

設定 → 轉發和 POP/IMAP → POP 下載，裡面有一個選項「當郵件透過 POP 存取後」，如果它被設成封存或刪除 Gmail 副本，那麼只要有任何 POP 用戶端連上來抓信，Gmail 就會把那封信從收件匣移走（封存→進「所有郵件」、刪除→直接沒了）。Google 官方說明白紙黑字：選了 archive 或 delete，「your messages will vanish from the inbox once your POP client accesses them」。

所以真實的時序是：

別人寄信 → Cloudflare 轉發 → 確實送進收件匣（Activity Log: Forwarded ✅）
        → 幾秒後某個 POP 用戶端連上來把它抓走
        → 依「封存/刪除」設定，這封信從收件匣消失 ❌

我把 Gmail 的 POP 停用，沒有用戶端來抓信，信就乖乖留在收件匣了。 信從頭到尾都有送達，只是送達後幾秒內被 POP 規則清掉。 alt text 這也回頭解釋了前面每一個詭異現象：

現象	真正原因
Activity Log 寫 `Forwarded` 卻收不到	信送達了，是送達之後才被 POP 清走
自寄信「看得到」	看到的是 Sent 寄件備份——POP 只抓收件匣新進信、不動 Sent，所以它留著（這就是當初把我帶偏的元兇）
外部信消失	那是貨真價實的「新進收件信」，正好是 POP 會抓走的對象
轉到 Yahoo 秒收	Yahoo 沒有那個 POP 用戶端在背景抓信，不受影響
篩選器找半天找不到	因為根本不是篩選器，是 POP 的「下載後動作」

✅ 解法：把那個「當郵件透過 POP 存取後」改成 「在收件匣保留 Gmail 的副本」（或乾脆停用 POP）。POP 要生效一定有個用戶端在連——可能是你另一個信箱用「檢查其他帳戶的郵件（POP3）」在匯入它、某支舊手機郵件 App、或某個忘了的第三方服務；Gmail 網頁版最下面的「上次帳戶活動 → 詳細資料」能看到是誰在 POP 連線。懶得追查的話，換一個乾淨的終點信箱（Yahoo、Outlook、另一個沒掛 POP 的 Gmail）最快。

一句話總結這條除錯路徑

先看 Activity Log 的 Result 分「哪一端」（沒記錄=DNS／Dropped=Cloudflare／Forwarded=收信端）→ Forwarded 卻收不到，幾乎都是收信端 Gmail：先排除「自寄去重」，再用「換不同供應商的終點」隔離出是不是「那個帳號自己在吃信」——而帳號吃信最陰險的一種就是 POP 的『下載後封存/刪除』。全程不要用『從目的地自己寄給自己』來測，這是萬惡之源。

整個過程大概 5 分鐘，$0。

具體數據 / 結果

項目	Google Workspace	Cloudflare Email Routing
費用	每帳號月費	免費
設定時間	要建帳號、設 DNS	約 5 分鐘
可用地址數	看方案	無限 alias / catch-all
DNS 設定	部分要手動	一鍵自動
適合場景	真的要一個獨立信箱	只要「收信轉發」

對一個獨立開發者、只想要客服信箱能收得到信的情境，後者完勝。

反思

技術面：收信和寄信是兩回事

這次最重要的觀念釐清是——「收信」跟「寄信」是兩套機制，不要混為一談。

收信：靠 MX 紀錄告訴全世界「寄到這個域名的信要送去哪台伺服器」。Cloudflare Email Routing 解決的是這一半。
寄信：要讓別人相信「這封信真的是 autolaunch@bobochen.dev 寄的，不是冒名」，得設 SPF / DKIM / DMARC，否則會被丟進垃圾信。

還有一個 zone 的觀念：Email Routing 只認根網域（zone），不認子網域。 bobochen.dev 是 zone，autolaunch.bobochen.dev 只是它底下的 DNS record——所以信箱掛得上前者、掛不上後者。網站可以盡情用子網域，但要收信，地址得回到根網域。

Email Routing 是單向轉發——你能收，但預設不能用這個地址「寄」出去。如果之後我想用 Gmail 直接以 autolaunch@... 的身分回信，還得另外做 Gmail 的「Send mail as」+ SMTP 設定；如果要程式化發送驗證信、電子報，那又是 Resend 之類服務的範疇。這部分我在下一章單獨寫了完整作法：第 7 章：信收得到了，但能用它「寄」信嗎？（想看程式化發信的，也可以參考 Email Workers：程式化處理電子郵件）。

但對「上架填一個收得到的客服信箱」這個當下的需求，免費轉發剛剛好。

心態面：上線前的「隱形必備項」最容易漏

寫程式的時候，我們的注意力都在功能、UI、效能。但一個產品要真的「上線」，有一堆不寫 code 的隱形必備項：能收信的客服信箱、隱私權政策頁、應用程式截圖、Data Safety 表單……

這些東西平常不會出現在開發待辦清單裡，偏偏每一個漏掉都能讓你卡在上架的最後一哩路。我這次就是填表單填到一半才驚覺信箱問題——還好是現在發現，不是 App 被退件、使用者寄信來卻人間蒸發之後。

教訓很簡單：上架前，把「對外窗口」都實際測一遍。 信箱寄一封測試信、隱私權頁開無痕視窗點一次、截圖在不同手機看一眼。別假設它會動。

有趣發現：我又幫這個系列加了一章

最諷刺的是，這個系列叫「買域名的慘痛教訓」，我以為第 5 章「給想買域名的人的五個建議」已經把坑講完了。結果第六個坑，是在我自以為學乖、零成本開子網域之後，從一個我根本沒想過的角度冒出來的。

域名的學習大概就是這樣——你以為畢業了,它總有辦法再教你一課。所以如果要我把第 5 章的「五個建議」補成第六個：

建議六：買完域名別急著慶祝。先想清楚你要不要用它收信——要的話，去開 Cloudflare Email Routing，免費五分鐘，別等到要用的那天才發現它是個空殼。