先抓大方向：你只是把「導航員」換成 Cloudflare
網域轉移後，Google Workspace 的資料、信箱、Google 協作平台內容通常不會因為 DNS 移走就消失；真正改變的是「網域要去哪裡」這件事改由 Cloudflare 的 DNS 記錄決定。
📬 Gmail 信箱
使用者帳號、信箱內容、Google Workspace 後台仍在 Google。Cloudflare 只負責把外界寄來的信導向 Google。
🧩 Google 協作平台
網站內容存在 Google Sites。Cloudflare 只負責讓 www.你的網域 找到 Google Sites。
🧭 DNS 指路
MX、CNAME、TXT 這些「路標」改在 Cloudflare 管。填錯，服務可能還在，但外面的人找不到。
🔧 排錯能力
以前 Google 幫你自動串好；現在你要懂灰雲、MX、SPF、DKIM、DMARC 與驗證指令。
一眼看懂：Google × Cloudflare 分工心智圖
把這張圖記起來，之後遇到信箱、網站、驗證問題，就知道要回 Google 還是 Cloudflare 檢查。
搬到 Cloudflare
轉到 Cloudflare 的壞處，不是不能用，而是「你要自己管路標」
原始文件提到的核心風險是對的：分家之後會增加手動設定、帳務、客服與 Proxy 判斷成本。這裡把每個壞處改成「補救做法」。
不要讓 Cloudflare Email Routing 接管 Google Workspace
Cloudflare Email Routing 是「轉寄信」功能，不是 Google Workspace Gmail。若你的網域要使用 Google Workspace 收信，MX 應該指向 Google，而不是讓 Cloudflare Email Routing 佔用 MX。
安全做法：Cloudflare Email Routing 不啟用；DNS 裡保留 Google Workspace MX。
Google Sites 的 CNAME 不要急著開橘雲
Cloudflare 橘雲會讓流量先進 Cloudflare 代理。Google Sites 本身有自己的 SSL 與站台綁定流程，實務上建議 www → ghs.googlehosted.com 這條先設灰雲 DNS Only，減少憑證或驗證衝突。
客服會分邊
信箱帳號、Google Sites 後台屬於 Google；DNS 記錄、Name Server、Proxy 屬於 Cloudflare。問客服時要先截圖 DNS 與錯誤畫面，才不會兩邊來回踢球。
建立「DNS 變更紀錄表」
每次改 DNS 都記錄：日期、改哪一條、原本值、新值、原因、測試結果。你未來做房仲工具、短網址、Cloudflare Pages 都會用到這個習慣。
互動 DNS 實作：輸入你的網域，自動套入範例
這裡用「新手最安全版本」呈現。請先在 Cloudflare DNS 新增 / 檢查這些記錄，再回 Google 後台啟用或驗證。
🧪 我的設定教練
提醒：若你的舊版 5 條 MX 已經正常收信，不必為了新版而硬改；新設或重設時可用單一 smtp.google.com。
你要填的 DNS 表
| 類型 | 名稱 | 內容 / 目標 | 優先 | 代理 | 複製 |
|---|
DKIM 的值不是固定範例，必須從 Google Admin Console 產生後再貼到 Cloudflare。DMARC 的回報信箱也請換成你真的能收的信箱。
操作流程：照這 6 關做，不要跳關
建議順序：先備份 DNS，再動 MX / CNAME / TXT，最後用指令驗證。不要一邊設定一邊亂刪未知記錄。
截圖或匯出 zone file。
讓信寄到 Google。
CNAME 到 Google。
提高寄信可信度。
不要只靠感覺。
上線前檢查清單
最重要：指令中心，所有常用查詢一次列好
把你的網域輸入上方實作區，這裡會自動換成你的網域。按一下即可複製。Windows 新手建議先用 nslookup；PowerShell 可用 Resolve-DnsName；Mac / Linux 用 dig。
排錯急救包：看到錯誤時先看這裡
DNS 最大的麻煩不是難，而是「錯一格就像整個壞掉」。這裡用症狀反推檢查位置。
先查：MX 是否指向 Google；Cloudflare Email Routing 是否開啟；是否殘留 Microsoft 365、Zoho、舊主機 MX。
安全修法：同一個根網域的收信服務只選一個。若用 Google Workspace，就保留 Google MX，不要混用 Cloudflare Email Routing MX。
先查：www.yourdomain.com 的 CNAME 是否為 ghs.googlehosted.com；Cloudflare 是否灰雲 DNS Only；Google Admin Console 是否已新增 Custom URL。
安全修法：先把 CNAME 改灰雲，等 Google Sites 綁定正常與 SSL 生效後，再評估是否需要其他 Cloudflare 代理設計。
先查：Google Admin Console 給你的 TXT 值是否完整複製；Cloudflare Name 通常填 @ 或 Google 指定主機名稱。
注意：驗證 TXT、SPF TXT、DKIM TXT、DMARC TXT 都是 TXT 類型，但名稱與值不同，不要混在同一欄。
先查：SPF 是否只有一筆；DKIM 是否啟用；DMARC 是否存在；寄件量是否突然暴增。
安全修法：先補 SPF + DKIM + DMARC p=none，觀察後再調整成 quarantine 或 reject。
先查：Cloudflare 畫面是否已儲存；你查的是不是正確網域；本機 DNS 快取是否還沒更新。
建議：用 1.1.1.1、8.8.8.8 或 Google Admin Toolbox 交叉檢查；剛改完可能需要等待快取同步。
小測驗：3 題確認你真的懂
答錯沒關係，這是用來幫你抓盲點的。
www CNAME 實務建議先設成？深化理解：DNS 記錄像什麼？
用生活比喻來記，比背英文縮寫更快。
📮 郵差路線
告訴全世界：寄到 @你的網域 的信，要送去哪個郵局。Google Workspace 的郵局就是 Google 的 MX。
🏠 網址別名
告訴瀏覽器：www.你的網域 其實要去 ghs.googlehosted.com 找 Google Sites。
🪪 身分證明
Google 驗證、SPF、DKIM、DMARC 都常用 TXT。它們不是導向網站，而是放一段文字讓系統查證。
✉️ 誰可以代表我寄信
如果只用 Google 寄信，常見值是 v=spf1 include:_spf.google.com ~all。若還用其他寄信平台，必須合併在同一筆 SPF。
🔏 信件防偽簽章
Google 會產生一組公鑰放在 DNS。收件方可用它確認信件沒有被假冒或竄改。
🧑⚖️ SPF/DKIM 不過時怎麼處理
一開始建議 p=none 觀察報告；成熟後再逐步改 quarantine 或 reject。