更換 DNS 代管前，先盤點哪些系統正在用公司網域寄信

更換 DNS 代管前，應先列齊實際寄信服務，再把每項服務對應到現有 DNS 紀錄、維護者及前後測試。不要只複製網站 A 紀錄，也不要把自動掃描視為完整備份。這篇要完成的是切換前的來源盤點與交接表；實際變更仍由有權限的管理者依供應商程序執行。

從業務系統找來源，先補出 DNS 清單看不到的用途

先找出哪些系統會使用公司網域對外寄信。員工信箱只是其中一項，還可能有官網詢問表單、CRM、客服回覆、訂單通知、發票或設備告警。請各系統負責人確認實際服務及使用中的寄件身分，不要只問「有沒有用公司信箱」，否則平台代發的通知容易被漏掉。

盤點時間也要涵蓋低頻工作。每天的客服信很容易看到，每月的帳務通知或只在異常時發出的告警，未必出現在最近一天的投遞紀錄。把各系統的觸發情境列出，再請負責人確認測試方法；不能因短期沒看到寄送，就判定服務已停用。

每項服務至少指定一位能回答設定問題的人。業務知道 CRM 名稱，不一定能確認簽署網域；網站廠商能處理表單，也不一定有權管理企業信箱。把業務用途與技術維護分開記錄，才知道缺哪個資訊時該找誰。

• 系統用途：員工信箱、表單、客服、CRM 或通知。
• 實際寄件服務與相關帳戶代號，不記錄密碼。
• 顯示寄件網域與管理者確認的技術寄件身分。
• 使用頻率、可安排的測試方式及維護窗口。

保留現有區域資料，再逐筆記錄名稱與值

請 DNS 管理者從目前真正使用的代管服務保存紀錄匯出與必要畫面，記下匯出時間和區域名稱。另保留註冊商、名稱伺服器、DNSSEC 狀態及其管理窗口。這些資料分屬不同管理位置，不能只因同一人持有登入權限，就假設全部設定都在一個後台。

Cloudflare 的官方遷入文件明確提醒，自動掃描不保證找齊所有既有 DNS 紀錄。因此可以用掃描作為比對起點，但仍需和原代管匯出、各服務設定及子網域用途核對。這個提醒不是說所有平台匯入方式相同，操作仍應按目的供應商的說明確認。

每筆紀錄保存完整名稱、類型、完整內容與 TTL。畫面可能省略根網域，也可能把多段 TXT 顯示成不同欄位；交接時應保留原始表示，再由管理者核對目的平台應如何輸入。不要讓業務為了方便貼表，擅自刪除引號、分號或名稱中的一部分。

把 SPF、DKIM、DMARC 與 MX 接回各自服務

接著把紀錄與來源清單連起來。SPF 相關資料不能只留一張截圖而不知道它服務哪些來源；DKIM 則要讓每個 selector 對應到目前簽署的服務。服務商若使用 CNAME 指向自己的金鑰位置，也要保留原類型和目標，不自行改成一段看起來相似的 TXT。

DMARC 的名稱與現有值應完整保存，報告收件設定與相關管理者另列。這次盤點的目的不是替公司重新選政策，所以不要趁搬遷時順手把 p=none 改成 reject。先確保既有已確認設定能被正確對照，政策調整若有必要，另立變更和驗證範圍。

MX 是郵件接收路徑的一部分，不是所有寄件服務的清單。保留 MX 的優先序和目標，也請管理者確認目標依賴的相關紀錄。不能因為 MX 搬過去就說寄件來源全部完成，更不能把網站主機地址直接當成郵件出口。

• SPF：完整原值、對應服務、來源確認人。
• DKIM：selector、簽署服務、TXT 或 CNAME 及其原值。
• DMARC：完整名稱、現有政策、報告相關設定與窗口。
• MX：優先序、目標、接收服務與相關依賴。

先做可比較的基準，再安排切換後檢查

由管理者挑選能代表各來源的受控測試，在切換前保存對外 DNS 觀察、投遞事件及收件端結果。各系統使用同樣的測試收件帳號並非必要，但每個來源前後應有可比條件。測試信不能包含客戶合約或名單，也不能發給未同意配合的對象。

記錄查詢位置與時間。原服務後台顯示的設定、新服務預備區的設定，以及外部當時解析到的結果，是不同觀察。切換後發現差異時，這些紀錄能幫助管理者判斷是漏項、輸入錯誤、委派狀態，還是尚需查核的快取現象，而不是只憑感覺等待。

驗收表要按來源分列。員工信箱成功，不能代表 CRM、官網和低頻通知都成功；收到信，也不代表每一項驗證或資料夾落點都符合預期。先寫明這次要觀察什麼，再填結果，未測項目保留未測，不把單一成功複製到整張表。

指定變更與回復責任，不在同一窗口混入其他修改

切換前確認誰操作名稱伺服器或相關委派、誰核對目的區域、誰觀察寄收信，以及誰能決定暫停。若涉及 DNSSEC，應由管理者按目前與目的服務的程序核對委派資料，不把它簡化為一個所有公司通用的開關步驟。本文不要求業務自行修改任何設定。

回復資料不只是一張舊截圖，還要知道保存的是什麼時間的版本、由誰確認可使用，以及發現哪種問題時啟動評估。DNS 相關狀態有不同觀察點，不能保證按回原設定便立即讓所有地方一致。回復的執行和驗收同樣需要管理者負責。

避免把切換和其他變更疊在一起，例如同時改寄信平台、旋轉 DKIM 金鑰、換追蹤網域，又調整驗證政策。這些工作可以有必要性，但若放進同一個未分項的窗口，失敗後很難分辨原因。先把本次改動範圍寫清楚，額外需求另做記錄。

• 操作窗口：具備權限的管理者與可聯絡時段。
• 檢查窗口：各寄件來源的負責人。
• 暫停條件：資料缺漏、責任不明或基準不可用。
• 回復依據：原始版本、核准人與後續驗證項目。

完成逐來源交接，未確認的服務不要提前關閉

虛構停止案例：公司準備換 DNS，後台掃描只找到員工信箱相關紀錄，但帳務人員提醒每月有另一套發票通知。因為該系統的寄件身分與維護者尚未確認，應先補齊盤點，不因最近沒有寄件就刪除它可能需要的紀錄，也不把未完成測試當成已停用。

切換後依來源逐項更新結果，保存外部觀察、投遞事件和收件端確認。舊代管何時退場，應由管理者依完整盤點與服務程序決定，不用固定天數替所有公司下結論。若只是部分來源完成，交接表就保留部分完成的狀態。

需要比較切換前後落點時，可另安排獲准的 Inbox Check 測試，把來源和測試時間記清楚。它不能代替 DNS 區域備份、委派或 DNSSEC 查核，也不保證搬遷不中斷。對業務而言，最重要的是知道哪個流程已核對、哪個仍不能依賴。

官方資料查閱於 2026-10-18：Cloudflare Docs「Set up a primary zone」，https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/。引用範圍為遷入前紀錄覆核、自動掃描限制與郵件紀錄注意事項；本文的雙清單、責任分工及驗收表為編輯整理。

實際上可以用免費的收件匣到達率測試（check.live-direct-marketing.online）來驗證。

常見問題