TL;DR
- DNS 配置错误是邮件迁移失败的头号原因——MX 记录顺序错误或 SPF 合并遗漏。
- 5 个常见错误：DNS 错误、本地数据遗漏、未做盘点、日历丢失、切换过快。
- 遵循 3 个阶段：准备（盘点、备份、降低 TTL）、迁移（同步、按顺序改 DNS）、迁移后（保留旧系统、持续监控）。
- 关键原则：切换后两个系统至少并行运行 72 小时。
描述
企业邮箱完整迁移指南。涵盖 5 个常见错误、三阶段迁移检查清单、DNS 修改顺序、迁移后稳定措施以及工具推荐。
为什么邮件迁移关乎业务风险
你正在更换服务商——这是小型企业风险最高的 IT 操作之一。大多数人把它当成纯技术任务。结果邮件停发、日历消失、CRM 系统崩溃。
首要原因：DNS 配置错误。MX 记录顺序不对、SPF 合并遗漏、DKIM 跳过——这些问题会导致邮件持续几天退信或被标记为垃圾邮件。解决方案是一份经过验证的检查清单。
5 个最常见错误
1. DNS 错误。 过早修改 MX 会导致投递分裂。未降低 TTL 意味着传播缓慢。多条 SPF 记录会破坏认证。
2. 本地数据遗漏。 PST、MBOX、POP3 邮件——这些都不会自动转移。此外还有服务端规则、签名、模板。
3. 未做盘点。 遗漏别名、共享邮箱、通讯组、通配地址、非人类账户。
4. 日历/联系人缺失。 邮件工具只转移邮件，不转移事件、联系人或权限。这些需要单独导出。
5. 切换过快。 两个系统至少并行运行 72 小时（理想情况 7-30 天）。
迁移检查清单
第一阶段：准备（第 1-10 天）
- 盘点所有邮箱、别名、通讯组、通配地址、非人类账户
- 记录 DNS：MX、SPF、DKIM、DMARC。截图以备回滚
- 将所有邮箱备份为 PST/MBOX（每 GB 约 1-4 小时）
- 在切换前 24-72 小时将 DNS TTL 降低至 300 秒
- 在修改 DNS 前先在目标系统创建所有邮箱
- 通知团队：时间线和所需操作
第二阶段：迁移（切换日）
- 执行初始 IMAP 同步。对于大邮箱，提前几天开始
- 单独导出/导入联系人和日历
- 手动重建规则、签名、权限
- 按顺序更新 DNS：MX → SPF（合并为一条记录）→ DKIM → DMARC（p=none）
- 执行增量同步；验证入站、出站、别名、移动端
- 如果验证失败：恢复旧 DNS，保留旧服务商，24 小时后重试
第三阶段：迁移后（第 1-30 天）
- 旧服务商保持活跃 72 小时至 30 天
- 重新连接 CRM、项目工具、网站表单
- 启用 MFA，禁用旧版认证
- 监控 DMARC 2-4 周
- 仅在以下条件满足后停用旧系统：数据已验证、无旧 SMTP 依赖、系统稳定运行超过 7 天
工具： BitTitan MigrationWiz（14 美元/用户）、Cloudiway（9-14 美元/用户）、MailJerry（9 美元/邮箱）
你的行动方案
本周： 开始盘点。列出邮箱、别名、DNS 记录。导出一个测试邮箱。
迁移前一个月： 降低 TTL。建立目标系统。执行初始同步。通知团队。
迁移周： 按顺序执行第二阶段。两个系统保持运行。验证失败则回滚。
核心要点： 正确顺序——准备、搭建、同步、切换 DNS、验证、保持——能大幅降低迁移风险。
