邮箱迁移步骤：从 T-7 到 T+1 的执行计划

邮箱迁移步骤：按天执行的低停机切换计划

邮箱迁移并不是简单地复制文件。用户仍在两端修改数据时，管理员需要在两个在线数据库之间完成状态切换。如果数据层 (IMAP) 与路由层 (DNS) 不同步，就会出现分流问题：组织中的一部分邮件送到旧服务器，另一部分则送到新服务器。

本操作手册列出了从 T-7 到 T+1 每天应执行的准确顺序，只讲实际步骤，不展开理论。有关整体架构，请参阅完整的邮箱设置指南。

迁移涉及的三个层面

每次邮箱迁移都涉及三个层面，其中任何一个出现问题都可能造成服务中断。

1. 数据层：历史邮件 (IMAP)
2. 路由层：决定新邮件投递位置的 DNS 记录 (MX)
3. 访问层：Outlook 和移动应用等邮件客户端的账户配置

T-7 天：盘点与清理

不了解的数据就无法迁移。用户列表并不等于完整清单，第一阶段要做的是全面掌握现状。

盘点所有对象

• 列出全部对象类型：邮箱、别名、通讯组和公用文件夹
• 找出超大邮箱：筛查超过 20 GB 的邮箱。Google 将 IMAP 下载量限制在约 2,500 MB/day。迁移一个 50 GB 的邮箱可能需要数周，而不是数小时。Google Workspace 数据迁移指南详细说明了这些限速规则。
• 清理闲置数据：离职员工不需要继续保留活动邮箱。请将其导出到本地归档。

如果从 Exchange 迁移，请用 PowerShell 获取实际项目数。由于压缩方式不同，按 GB 比较容量并不可靠：

T-2 天：预同步

不要等到周五晚上才开始。请在用户仍正常工作时迁移 90% 的历史数据，这样能显著降低正式切换时的风险。

开始同步

将迁移工具或 imapsync 设置为迁移早于 30 天的邮件，并监控 HTTP 429 (Too Many Requests) 或 Google 11001 错误。

需要了解的限速规则

Gmail 注意事项：不要把 All Mail 与每个标签同时当作独立文件夹迁移。Gmail 标签指向同一封邮件，并不代表存在多份真实副本，但错误的标签到文件夹映射仍可能在目标端生成重复邮件。请谨慎映射标签，并在这种迁移方案中排除 Gmail/All Mail。

T-1 天：降低 TTL，300 秒规则

DNS 记录通常会缓存 24 小时 (TTL 86,400)。迁移中最容易遗漏的步骤之一，就是提前降低 TTL。如果未经准备便切换 MX 记录，部分递归解析器可能会继续依据已有缓存将邮件送往旧服务器，直到缓存过期。

1. 登录 DNS 服务商控制台 (Cloudflare、Route53 等)
2. 找到 MX 记录
3. 将 TTL 改为 300 秒 (5 分钟)
4. 暂时不要删除旧记录，只修改 TTL

使用 dig 检查：

T-0 (周五晚)：正式切换

用户已经停止工作，现在执行切换。这是整个迁移中最关键的阶段。

步骤 1：冻结变更

要求用户停止发送邮件。如果条件允许，请锁定源端账户，以免产生滞留在旧系统中的邮件。

步骤 2：增量同步

再次运行迁移工具。这一轮将获取最近 30 天的数据以及所有新增项目。大部分数据虽已迁移，但实际耗时仍取决于数据量、变更量和服务商限制。

注意 UIDVALIDITY 问题：如果源服务器重新索引了文件夹，工具可能会再次下载重复内容。请务必先进行模拟运行。IMAP RFC 3501详细说明了 UIDVALIDITY 的语义。

步骤 3：切换 MX 记录

更新 MX 记录，使其指向新服务商。TrekMail 用户应使用：

TTL 设为 300 秒后，遵守该值的缓存可能在约 5 分钟内更新，但其他解析器和已有缓存可能需要更长时间。

步骤 4：更新 SPF 和 DKIM

请在新服务商开始发信之前，将新的发信 IP 地址加入 SPF 并验证记录。只要旧服务商仍可能发信，就应继续保留其授权。详情请参阅域名邮件身份验证设置指南。

T+1 (周一上午)：验证

最后阶段的重点是验证。不要假定迁移成功，应当实际确认结果。

核对项目数量

比较源端与目标端的项目数量。低于 1% 和高于 5% 只是用于记录与调查的操作阈值，并不能直接证明迁移成功或失败。每项差异都应查明原因。较大的差异可能来自文件夹层级限制或过滤器配置错误。

重新配置邮件客户端

将邮件客户端切换到新账户。根据客户端和服务变更方式，有时可以安全地修改现有配置文件；在其他情况下，删除旧账户后再添加新账户更可靠。

日历与联系人

TrekMail 提供专业的企业邮箱托管，并通过 CalDAV 托管服务器端日历，通过 CardDAV 托管联系人。不过，IMAP 迁移只传输受支持的邮件和文件夹，并不迁移这些数据。请从旧服务商导出 .ics 日历和 .vcf 联系人，再导入 TrekMail，随后在每台受支持的设备上检查同步结果。

继续或停止的核验关卡

回退计划

如果新系统拒收邮件或缺少关键数据：

1. 恢复 MX：将 MX 记录重新指向旧服务商。部分缓存可能在 5 分钟内更新，因为此前已将 TTL 设为 300s，但不能保证完整路由在此时间内恢复
2. 导出间隔数据：在此窗口期间送达新服务商的所有邮件，都必须导出为 EML/MBOX 并导入旧服务器
3. 排查问题：再次尝试之前，检查 550 5.7.1 (Relay Access Denied) 错误和防火墙拦截

TrekMail 自动化部分邮箱迁移步骤

手动迁移工作量大且存在风险。TrekMail 可以自动化部分基础设施操作，让您更专注于客户。

适合小型企业

TrekMail 内置迁移工具可处理受支持邮件和文件夹的 IMAP 连接、重试及限速逻辑。输入凭据后请监控迁移过程，并在完成后将结果与源端进行最终核对。

适合代理商和 MSP

为 100+ 个域名进行批量配置。所有客户共用存储空间池，无需按用户分别设置限额。托管 SMTP 可减少自行进行 IP 预热的工作。

所有付费套餐均提供 14 天免费试用 (需要银行卡)。Nano 套餐无需银行卡。

总结

邮箱迁移之所以需要严格按时间表执行，是因为每个阶段都依赖前一阶段。如果没有提前降低 TTL，受已有缓存影响，部分路由可能持续分流最多 24 小时。如果跳过预同步，正式切换窗口可能比计划长得多。

按照时间表执行，核对项目数量，并准备好回退计划，这就是完整的方法。

准备开始了吗？创建免费的 TrekMail 账户，使用内置迁移引擎减少手动工作。