網站搬主機時若整套 DNS 設定被換掉，公司信箱可能在新站正常上線後停止收信或寄信。本文帶企業主驗收管理權、現有紀錄、變更範圍、切換時序與收寄測試，避免詢價、報價與帳務通知在交接中無聲中斷。
新網站上線後，首頁與商品頁都正常，隔天業務卻發現公司信箱收不到詢價，會計寄出的報價也進了垃圾郵件。網站廠商說信箱不在維護範圍，郵件廠商則指出網域設定剛被更換。企業真正承擔的營運損失，可能不是幾封信，而是無法察覺的名單、延遲的訂單與交接責任。
這種狀況常發生在搬主機或改版時。為了讓網站指向新主機，廠商直接更換整套 DNS。DNS（網域名稱系統）就像網域的地址簿，告訴外界網站、公司信箱與其他服務各自在哪裡。若只抄了網站地址，卻漏掉信箱的投遞與驗證資料，新站會開，郵件仍可能失聯。
可以把公司網域想成商場地址。網站是店面，電子郵件是收發室。搬店面時，只需要更新店面位置；如果連整本商場通訊錄都換掉，卻忘記把收發室、貨運入口與授權名單抄回去，顧客仍看得到店，信件和貨物卻找不到人。
搬網站不一定要搬整套 DNS
網站常透過 A 或 AAAA 位址記錄，把網域指向主機的網路地址，也可能用 CNAME 別名記錄，讓一個名稱跟隨另一個服務名稱。公司信箱則依賴 MX（郵件交換）記錄，告訴寄件系統應把信送到哪一家郵件服務。Google Workspace 與 Microsoft 365 的官方文件都說明，MX 會決定網域郵件的投遞目的地。
名稱伺服器是對外回答整個網域設定的權威來源。若改版只更換網站主機，通常可以只調整網站相關記錄；若連名稱伺服器也更換，就等於換掉整本地址簿，原有信箱、子網域、第三方驗證與安全設定都要完整帶過去。Cloudflare 也提醒，自動掃描可能找不到特定名稱的記錄，更換名稱伺服器前必須人工檢查並補齊。
用五個問題驗收「網站已經切換」
- 公司知道目前誰管理 DNS 嗎？ 確認網域註冊商、名稱伺服器供應商、管理帳號與最高權限擁有人。廠商能代管不代表公司可以不知道入口與復原方式。
- 變更前是否有完整記錄清單？ 匯出或逐筆記錄名稱、類型、內容、TTL（外界暫存答案的時間）、用途與負責廠商。除了網站記錄，也要涵蓋 MX、子網域及 TXT 文字記錄。SPF 是寄信來源授權清單，DKIM 是郵件數位簽章，DMARC 則告訴收件端驗證失敗時如何處理，三者都可能藏在 TXT 或相關記錄裡。
- 廠商改的是一筆網站記錄，還是整套名稱伺服器？ 要求提供變更前後差異，寫清楚新增、修改與刪除哪些項目。若報價只寫「DNS 指向」，仍不足以判斷影響範圍。
- 切換時間與回復條件有沒有約定？ DNS 查詢可能因各地暫存而在一段時間內得到新舊答案。事前適度調整 TTL 可縮短部分暫存時間，但不能保證全球同一秒更新。應避開重要活動與結帳尖峰，保留舊設定、負責人與明確回復門檻。
- 驗收是否包含外部收寄信，而不只看網站？ 用公司網域寄到外部信箱，再由外部信箱回信，檢查收件匣、垃圾郵件與退信；同時測試詢價表單、訂單通知、重設密碼及使用該網域驗證的第三方服務。只測同公司內部互寄，可能看不出公開 DNS 的問題。
便宜方案省下的可能是盤點與回復能力
只修改網站 A 或 CNAME 記錄，若原 DNS 供應商與信箱都不變，可能是成本最低且風險較小的做法。完整搬遷則應包含現況匯出、變更差異、郵件與第三方服務測試、觀察期及回復方案，費用自然較高。
不要為了「一次處理完」同時更換網域註冊商、名稱伺服器、網站主機與郵件服務，除非相依關係已盤點且有必要。一次變更多個入口，看似節省工期，故障時卻更難找出是哪一段出錯。低價不是問題，沒有說明省略了哪些檢查才是問題。
今天先建立一張網域服務清單
在任何切換前，先請現任廠商匯出 DNS 記錄，並建立「記錄名稱、類型、用途、服務商、負責人、變更時間、驗證方式、可否回復」清單。接著問新廠商兩句：「這次會更換名稱伺服器，還是只改網站記錄？誰負責驗收公司信箱與其他網域服務？」
若對方只能展示新網站，卻拿不出變更差異、公開查詢結果與收寄測試，代表交付仍不完整。企業主不必背下每種記錄的格式，但應能看見誰改了什麼、如何證明正常，以及異常時由誰決定回復。
自行處理的邊界與接洽準備
公司掌握 DNS 帳號、只有單一網站與單一郵件服務，而且各供應商提供清楚設定值時，可以自行完成清單、安排測試與保存畫面。若名稱伺服器在舊廠商帳號、記錄用途無人知道、有多個子網域與寄信系統，或停信會影響訂單、帳務、客服與會員登入，就值得由網站、DNS 與郵件人員共同盤點及驗證。
接洽前可準備網域名稱、註冊商與 DNS 管理入口、目前網站及信箱供應商、完整記錄匯出、預計切換時間、不可中斷的信箱與第三方服務。邊境部署可以協助把這些資料整理成變更範圍、驗收證據與回復條件，先確保網站搬家不會讓公司的收發室一起消失。