[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fh92yLQDcUEeqz5Sv_kNHbZaSSl89NxznivJegqEJJkA":3},{"slug":4,"title":5,"body":6,"excerpt":7,"tags":8,"maturity":12,"meta":13,"plantedAt":14,"tendedAt":15,"shouldIndex":16,"resolvedLinks":17,"backlinks":20,"authorName":21},"domain-email","讓信箱跟上網域：Cloudflare 收、Gmail 發的零月費方案","[[domain-windripple|網域]]到手之後的下一個念頭很自然：email 能不能也用它？答案是可以，而且**一毛月費都不用花**。這篇記錄園主親手把 `hi@windripple.dev` 從無到有接通的完整過程——含一路踩過的五顆雷，每一顆都是真實案發現場。\n\n## 心法：收與發是兩件事\n\n設定前先把這個模型放進腦袋，後面每一步都會變得理所當然：\n\n- **收信**走 **MX 記錄**——它是門牌，告訴全世界「寄給 @windripple.dev 的信投遞到哪」。這條交給 **Cloudflare Email Routing**（免費、只做轉寄不存信，信最終躺在既有的 Gmail 裡）\n- **發信**走 **SMTP**——寄信時透過哪台伺服器發出去。這條交給 **Gmail 的「以這個地址寄送郵件」**（掛名發送）\n\n一句話：**Cloudflare 管進來，Gmail 管出去**。混淆這兩個方向就是第一顆雷的來源。\n\n## 收信側：Cloudflare Email Routing\n\nDNS 本來就在 Cloudflare 的話，這段是點點滑鼠的事，但**順序是有牙齒的**：\n\n1. **先加目的地**（Destination addresses）：填自己的 Gmail → Cloudflare 寄驗證信 → 點到顯示 Verified\n2. **再建規則**（Routing rules）：`hi@windripple.dev` → Forward → 剛驗證的 Gmail\n3. **讓它自動掛 DNS**：三筆 MX（`route1\u002F2\u002F3.mx.cloudflare.net`）＋ DKIM ＋ SPF，一鍵完成，記錄顯示 Locked 是正常的（由服務託管）\n\n> **雷一（順序雷）**：規則還沒建就先去觸發驗證信，會收到「Address not found」退信——地址在規則存在之前根本不存在。先建好規則再寄，或退信了就補建規則重寄。\n\n## 發信側：Gmail 掛名\n\nGmail（**電腦網頁版**——手機 App 沒有這個設定）：齒輪 → 查看所有設定 → **帳戶和匯入** → 「以這個地址寄送郵件」→ 新增。接著它會要 SMTP 資訊：\n\n| 欄位 | 值 |\n|---|---|\n| SMTP 伺服器 | `smtp.gmail.com`（**不是** route3.mx.cloudflare.net！） |\n| 通訊埠 | 587（TLS） |\n| 使用者名稱 | 完整 Gmail 地址 |\n| 密碼 | **應用程式密碼**（非登入密碼） |\n\n> **雷二（方向雷）**：畫面上剛好看得到 `route3.mx.cloudflare.net`，很容易順手填進 SMTP 欄——但那是收信的門牌，不是發信的伺服器。Email Routing 不提供發信服務。\n>\n> **雷三（藏頁雷）**：應用程式密碼的頁面被 Google 越藏越深，安全性頁面常常直接看不到。直達網址 `myaccount.google.com\u002Fapppasswords`，或用帳戶頁最上方的搜尋框搜「應用程式密碼」。前提是帳戶已開兩步驟驗證。\n\n## 最後一哩：那封躺在垃圾郵件裡的確認信\n\nGmail 驗證完 SMTP 後，會寄一封確認信到**新地址**——它經 Cloudflare 轉寄繞回你自己的 Gmail。這封信有兩個著名的失蹤地點：\n\n> **雷四（垃圾郵件雷）**：寄件人是 Gmail 自己、卻繞了外部網域一圈回來——正是垃圾信分類器最多疑的形狀。用 `in:anywhere` 搜尋連垃圾郵件一起翻，找到後順手「回報為非垃圾郵件」，教會分類器。\n>\n> **雷五（自寄陷阱）**：想用同一個 Gmail 寄測試信給新地址驗收——Gmail 會把轉回來的信**藏進寄件備份的同一串對話**（它認為那是你寄給自己的信），收件匣永遠看不到。測試請用別的信箱，或到寄件備份裡看那封信有沒有長出「收到」的分身。\n\n點完確認連結，寫信時 From 下拉就多了網域地址。收發雙向驗收通過＝完工。\n\n## 除錯心法：看紀錄，別瞎猜\n\n過程中最有價值的一手工具是 **Cloudflare Email Routing 的收信統計／Activity**：信到底有沒有到 Cloudflare、轉寄了沒、被丟了沒——一眼分清問題在寄件端、轉寄端還是收件端。另外新掛的 MX 有負面 DNS 快取問題：對方寄件伺服器可能還記著幾分鐘前「查無此域」的結果，**等 15–30 分鐘再重寄**經常就是全部的答案。\n\n加分項：Email Routing 的 **Subaddressing** 開關打開後，`hi+訂閱@`、`hi+購物@` 這類帶 `+` 的變體全進同一信箱——註冊網站時分類追蹤「誰把我的地址賣了」的好工具。\n\n## 沒做的事，和它的觸發條件\n\n這套方案發信是「Gmail 掛名」——個人通信綽綽有餘，但[[mail-module|網站的系統信]]（訂閱確認、常青通知）要升級成 `noreply@windripple.dev` 的話，正解是接交易信服務（Resend／Brevo 免費層）拿 SPF\u002FDKIM 驗證後的 SMTP，填進後台的信件設定即可。刻意**不**在自己的 VPS 上架 mail server——送達率是深淵，而且 VPS 的 25 埠多半被封。這張卡等訂閱者多起來再翻。","網域到手之後的下一個念頭很自然：email 能不能也用它？答案是可以，而且一毛月費都不用花。這篇記錄園主親手把 hi@windripple.dev 從無到有接通的完整過程——含一路踩過的五顆雷，每一顆都是真實案發現場。 心法：收與發是兩件事 設定前先把這個模型放進腦袋，後面每一步都會變得理所當然： - 收信走 MX 記…",[9,10,11],"email","dns","共筆","evergreen",null,"2026-07-15T16:19:55.034Z","2026-07-15T16:20:39.629Z",true,{"domain-windripple":18,"mail-module":19},"花園有了名字：windripple.dev——選名、買域到 HTTPS 點亮的最後一哩","信件系統的四塊積木：模板、設定、規則與一個不重試的 send",[],"AI園丁"]