郵件搬遷的流程與注意事項

郵件搬遷比網站搬遷麻煩

原因有三個：

• 信件會持續進來——切換期間的信可能分散在新舊兩邊
• 歷史信件要搬移——資料量可能很大
• 影響是立即且明顯的——收不到信，業務馬上受影響

所以規劃要比網站搬遷更謹慎。

搬遷前的盤點

1. 列出所有信箱——包含很少用的、以及純轉寄的
2. 確認各信箱的資料量
3. 列出所有轉寄與別名設定——這一項最常被遺漏
4. 列出各信箱綁定的服務——網域註冊商、主機、分析工具
5. 確認目前的 DNS 記錄——MX、SPF、DKIM、DMARC
6. 確認是否有郵件群組或共用信箱

第三項與第四項最容易出事

轉寄設定——舊系統上設了 info@ 轉寄到某人，搬遷後忘了設，那些信就靜默消失了。

綁定的服務——若某個信箱是網域註冊商的聯絡地址，搬遷期間若無法收信，剛好遇到需要驗證時就麻煩了。

搬遷的建議流程

第一階段：新環境準備

1. 在新服務建立所有信箱與群組
2. 設定與舊系統相同的轉寄與別名
3. 完成網域驗證
4. 設定 SPF、DKIM——但先不要改 MX
5. 設定 DMARC（若尚未設定）

第二階段：搬移歷史信件

多數服務商提供搬移工具，可從舊系統匯入。要注意：

• 資料量大時需要較長時間——可能數小時到數日
• 先搬一個信箱測試，確認結果正確再全部執行
• 確認資料夾結構、標籤是否保留
• 確認中文的主旨與內容沒有亂碼

歷史信件可以在切換 MX 之前先搬，切換後再補搬一次差異的部分。

第三階段：切換 MX

1. 提前調低 DNS 的存活時間——建議提前一到兩天
2. 選在離峰時段——例如週五晚間或假日
3. 修改 MX 記錄為新服務的值
4. 務必移除舊的 MX 記錄
5. 同步更新 SPF——移除舊服務、確認新服務已納入

第四項是最常見的錯誤。 舊記錄殘留會造成部分信件送到舊系統，症狀是「有些信收得到有些收不到」。

第四階段：驗證

1. 從外部信箱寄測試信到每一個信箱
2. 從新信箱寄信到外部，確認不會進垃圾桶
3. 測試轉寄與別名是否正常
4. 從網站表單送出一次，確認通知信收得到
5. 檢視測試信的原始檔，確認驗證都通過

第五階段：善後

• 舊服務保留一段時間——建議至少兩週到一個月
• 期間持續檢查舊信箱是否還有新信進來
• 補搬切換期間的信件
• 更新綁定該信箱的各項服務
• 確認所有員工都能正常收發

切換期間的信件分流

DNS 擴散期間，部分寄件方會用新的 MX，部分還在用舊的。

降低影響的做法

• 提前調低存活時間——縮短擴散時間
• 選在信件量最少的時段
• 切換後持續檢查舊信箱，把漏接的信轉過去
• 必要時在舊系統設定轉寄到新信箱

最後一項很實用——在舊系統設定全部轉寄到新信箱，即使有信送到舊系統也不會漏掉。

常見問題與排查

切換後完全收不到信

1. 確認 MX 記錄是否正確且已生效
2. 確認舊記錄已移除
3. 確認新服務端的網域驗證已完成
4. 確認信箱確實已建立

有些收得到有些收不到

典型的舊 MX 記錄殘留症狀，或 DNS 尚未完全擴散。

寄出去的信進垃圾桶

• 確認 SPF 已包含新服務
• 確認 DKIM 已設定且驗證通過
• 檢查是否有多筆 SPF 記錄
• 確認網域或位址是否在黑名單中

詳細排查見公司信箱收不到信或被當垃圾信怎麼查。

網站表單的通知信收不到

網站主機是獨立的寄信來源，必須另外納入 SPF。這是搬遷後最常被遺漏的一項。

另外要確認寄件位址的設定——不要把寄件人設成填表者的信箱，那等於以他人網域名義寄信，幾乎必然被擋。

見表單資料存哪裡、通知信收不到怎麼辦。

搬遷後的一週檢查

1. 每天確認舊信箱是否還有新信
2. 詢問各部門是否有收發異常
3. 確認自動寄出的系統通知都正常
4. 檢視 DMARC 報告，確認沒有遺漏的合法來源
5. 確認行動裝置都已重新設定完成

第五項容易被忽略——員工的手機需要重新設定帳號，若沒有明確通知，可能有人一直以為信箱壞了。

給員工的通知範本要包含

• 切換的時間
• 切換期間可能的影響
• 行動裝置需要重新設定的步驟
• 新的登入網址
• 遇到問題時的聯絡窗口

提前通知，並準備好簡單的設定教學，可以省下大量的個別協助時間。

一個避免麻煩的建議

不要同時搬遷網站與郵件。

兩者一起做，出問題時難以判斷原因，而且工作量與風險都會疊加。

建議先搬郵件、確認穩定後再搬網站——因為郵件中斷的影響較立即，值得單獨處理。

網站搬遷的流程見主機搬遷的完整流程。

各郵件服務商的方案內容、設定值與介面會不定期調整，本文說明的是原則與該確認的項目。實際的設定值請以服務商後台提供的當前資訊為準，不要沿用網路教學中的舊數值。