尽量减少中断，将邮件迁移到新主机
需要将邮件迁移到新主机时，并不一定会出现长达24小时的中断，也不一定会导致邮件退信或丢失。可怕的邮件黑洞通常源于管理员忽略DNS缓存时间，并试图一次完成所有工作。采用新旧系统并行运行的方式，可以让旧系统保持在线，同时在后台同步新系统，等源端和目标端核对一致后再切换。
本指南给出运维人员将邮件迁移到新主机并尽量减少中断时使用的具体切换方案。如需了解完整的迁移原理，请参阅我们的IMAP迁移指南。
为什么一次性切换容易失败
一次性切换的做法是周五晚上复制全部数据、切换DNS，然后只能祈祷一切顺利。它容易失败，是因为传输速度并不恒定。限流产生的HTTP 429错误和带宽上限都可能让迁移中途停滞。到了周一早上，一半邮箱还是空的，服务台则被求助请求淹没。
将邮件迁移到新主机时，专业做法是让两套系统并行运行。先配置新环境并在后台同步历史数据，等目标端与源端完成核对后再更新DNS。开始前还应阅读如何在切换期间维护邮件发件信誉的指南。
邮件迁移的4个阶段
| 阶段 | 时间 | 操作 | 目标 |
|---|---|---|---|
| 预迁移 | T-7天 | 通过IMAP同步30天以前的邮件 | 在不造成带宽压力的情况下迁移90%的存储数据 |
| 降低TTL | T-48小时 | 将MX和SPF的TTL降至300秒 | 让遵守TTL的DNS缓存可在约5分钟的窗口内切换 |
| 正式切换 | T-Zero（周五晚间） | 将MX记录改为新主机 | 把新收到的邮件路由到新服务器 |
| 增量同步 | T+1小时 | 同步最近30天的项目 | 收取过渡期间投递到旧服务器的邮件 |
阶段1：DNS传播与300秒规则
有些发件人连接旧服务器、另一些连接新服务器的分流现象，源于DNS记录的TTL过长。递归解析器会根据TTL缓存MX记录。常见的标准TTL是86,400秒（24小时）。如果没有提前降低TTL就切换MX，缓存的记录可能在切换后一整天内继续将邮件路由到旧服务器。因此，将邮件迁移到新主机前应先调整TTL。
操作方法很简单：检查当前TTL，将MX和SPF的TTL降至300秒，然后至少等待原TTL所对应的时长。跳过等待就意味着旧缓存记录仍可能生效。
SPF的10次查询陷阱
迁移期间，你可能想在旧服务商的SPF include旁边加入新服务商，但务必谨慎。RFC 7208将SPF的DNS查询次数限制为10次。同时叠加Google、Outlook和新主机等多个服务商，往往会超过上限，造成PermError和投递失败。只有在底层IP地址能够持续维护更新时才可扁平化SPF记录，否则可在切换期间暂时移除非关键的营销工具。更多建议请参阅SPF设置指南。
阶段2：通过IMAP同步数据
将邮件迁移到新主机时，迁移使用IMAP协议（RFC 3501）。这不是简单复制文件，而是同步状态。imapsync等工具可以承担繁重工作，但了解协议本身仍然很重要。
Gmail的幽灵邮箱问题
如果迁移Gmail的All Mail，并把标签当作文件夹处理，目标端可能出现多份邮件。Gmail通过IMAP把标签呈现为文件夹，因此一封带有3个标签的邮件可能显示在3个独立的IMAP文件夹中，而不合适的工具会把这3处显示当成独立项目。Google自己的数据迁移文档说明了这种模式。应配置迁移工具合理映射标签，或明确排除[Gmail]/All Mail文件夹。
限流与错误代码
将邮件迁移到新主机时，要为源服务器的限制做好准备。如果IMAP访问被禁用或遭防火墙阻止，Google可能返回11001/11002连接错误。HTTP 429表示请求受到了限流。许多服务商会在流量超过2 GB/hour/user时限制连接。请选择支持指数退避的迁移工具，让它识别限流并自动暂停。
阶段3：对客户端的影响
邮件迁移到新主机后，服务器端往往是较容易处理的部分。我们的邮箱迁移指南详细介绍了DNS切换。客户端设备才更容易引发服务台工单激增。
证书不匹配：如果切换DNS时Outlook仍在运行，它会连接到已指向新主机的mail.yourdomain.com，但可能继续使用旧凭据，随后就会出现SSL/TLS证书警告。建议用户在周一早上重启邮件客户端并检查连接。
移动端OAuth：现代移动邮件客户端使用与特定租户绑定的OAuth令牌。根据客户端和服务商的不同，账户有时可以重新授权或重新配置。其他情况下，用户需要删除旧账户并添加新的IMAP连接。
内部路由环路：切换MX后，旧服务器可能仍认为自己托管该域名。如果旧系统上的用户A给同样位于旧系统的用户B发信，服务器会在本地投递，而已经从新邮箱收信的用户B将看不到这封邮件。旧DNS缓存失效前，应将旧主机配置为把迟到的邮件安全转发到新主机。只有验证切换流程后才能停用本地投递。
回滚：最初15分钟的安全措施
由于已将TTL降至300秒，许多解析器可以较快接受回滚，这项准备在阶段1完成。如果迁移到新主机失败，例如防火墙阻断、许可证异常，或者30+分钟没有邮件流量，可将MX记录改回旧服务商。对于遵守TTL的缓存，新流量可能在约5分钟后返回旧系统。其他缓存可能需要更久，因此两套系统都应保持可用并接受监控。
TrekMail如何简化迁移
手动将邮件迁移到新主机，需要管理imapsync脚本、分析0x800CCC0E等晦涩错误，还要持续观察DNS传播。TrekMail内置IMAP迁移引擎，可针对受支持的IMAP数据自动处理文件夹映射、限流退避和增量同步，但完成后仍须与源端做最终核对。
| 套餐 | 价格 | 适用场景 |
|---|---|---|
| Free | $0 | 测试、个人域名（无需银行卡） |
| Starter | $3.50/mo | 小型企业、单个域名 |
| Pro | $10/mo | 多个域名、高级用户 |
| Agency | $23.25/mo | 使用共享存储迁移50+个客户域名的MSP |
所有付费套餐都包含14天试用期（需要银行卡）。Nano套餐完全不需要银行卡。
TrekMail专注于高性能邮件存储和投递，同时通过CalDAV和CardDAV为每个邮箱提供日历和联系人。如果还需要使用自己的域名创建邮箱，我们的设置指南会逐步说明操作方法。迁移本身只会迁移邮件，请从旧服务商导出日历和联系人，等邮箱上线后再将其导入。
对于经常一次将数十个域名的邮件迁移到新主机的代理机构，TrekMail提供共享存储，可在所有域名之间分配200 GB空间，还提供具有预热IP信誉的托管SMTP，以及可将DNS和迁移设置立即应用到100个域名的配置模板。
结论：迁移邮件，避开邮件黑洞
成功将邮件迁移到新主机，需要同时管理DNS、数据和客户端访问的状态转换。每位运维人员都应为这种复杂性做好计划。目标是尽量避免退信、数据丢失和紧急求助。提前设置300秒TTL，采用并行运行架构，完成最终数据核对，并准备好回滚方案。
接下来可阅读如何选择合适的邮件平台，以及如何在切换期间保护域名信誉的指南。
不要再为自己不用的功能按用户付费。免费试用TrekMail，了解专为运维人员打造的邮件托管服务。
