邮箱迁移检查清单：IMAP 切换实操指南

如果您在寻找邮箱迁移检查清单，大概已经知道风险所在。邮件迁移通常不是在复制任务中失败，而是在边缘环节出问题：遗漏的别名、过时的 DNS 数据、缓存中的 Outlook 配置、Gmail 标签的特殊行为，以及某个重要邮箱比计划多花三天才迁完。

这正是难点。更大的问题是，许多指南过于笼统，无法在实际切换时提供帮助。如果您要迁移小团队、淘汰旧主机，或降低企业邮箱支出，可以先阅读小企业邮箱的基础内容，再回来使用这份运维清单。

这份实用的邮箱迁移检查清单涵盖切换前、切换中和切换后的工作，适合创始人、IT 管理员、代理机构和 MSP，帮助他们迁往 TrekMail 等基于 IMAP 的托管服务。根据源快照，TrekMail 支持多域名邮箱、共享存储池和内置服务器端 IMAP 迁移。

邮箱迁移检查清单到底涵盖什么

邮箱迁移检查清单用于在切换时核对邮箱、DNS、身份信息和客户端访问。它旨在减少退信、文件夹缺失、移动应用无法使用，以及用户恢复工作后才发现的数据遗漏。

好的邮箱迁移检查清单不只是“导出、导入、修改 MX”。它应涵盖每一个能接收邮件的对象、每一项可能阻碍投递的依赖，以及每一个必须由用户完成的操作，否则服务器端迁移结束后仍可能出现大量支持请求。

1. 清点所有能够接收邮件的对象

清单的第一项是资源盘点。如果源端列表只有已授权的用户邮箱，就还不完整。共享邮箱、别名、catch-all 路由、转发规则、扫描仪、财务邮箱和旧通讯组都可能在切换后继续接收业务邮件。

问题往往从这里开始：有人导出“活跃用户”、创建目标邮箱、修改 DNS，就以为完成了。随后，发给 sales@ 的客户线索被退回，发给 ap@ 的发票找不到，办公室打印机开始报 SMTP 错误。

处理数据前，请按以下列表盘点：

1. 已授权的用户邮箱
2. 共享邮箱和职能账户，例如 info@、billing@ 和 support@
3. 映射到用户或共享邮箱的别名
4. 通讯组和群组地址
5. 转发规则、catch-all 行为和路由例外
6. 通过旧服务商发信的设备和应用
7. 旧 Exchange 对象，包括 X.500 或 LegacyExchangeDN 引用

一个地址应该保留为别名还是改成独立邮箱，比许多人想象的更重要。请在迁移前了解域名邮箱别名与独立邮箱的区别，不要等到开始退信才处理。

运维原则：只要某地址曾接收付款信息、客户线索、工单或重置登录凭据的邮件，在证明它已停用前，就应按生产地址对待。

TrekMail 的计费模型可能有所帮助，因为不必为每个工具性邮箱支付单独的用户费用。根据源快照，付费套餐每月 $3.50 起，使用共享存储池，可以迁往真正的 IMAP 邮箱，而不是用临时转发规则代替重要邮箱。请核对现行套餐条件。

2. 确认 IMAP 迁移会转移哪些内容

基于 IMAP 的清单应以转移邮件数据为前提，而不是默认转移所有内容。邮件和文件夹通常可以迁移；日历、联系人、规则、签名、权限和部分专有元数据通常不能。

这里很容易出现预期落差。IMAP 迁移邮件，不会重建整套协作环境。如果源系统是 Google Workspace 或 Exchange，用户可能以为日历、共享权限、分类和地址自动补全历史都会保留，但普通 IMAP 迁移通常无法做到。

项目开始前，请写明范围：

TrekMail 的导入工具用于 IMAP 邮件导入，应按这一用途使用。在承诺“迁移整个环境”之前，请通过 IMAP 迁移概览和在控制面板启动导入核对工作流程。

3. 提前复制大邮箱，让时间表更现实

现实可行的清单必须考虑限速。您本地的网速并不是唯一限制，源服务商、目标服务商和 IMAP 会话限制共同决定实际迁移速度。

这是技术条件决定的。办公室连接很快，也可能看到一个 50 GB 邮箱缓慢复制，因为源系统会放慢请求、限制连接或暂停高强度 IMAP 活动。Google 公布了 Gmail 带宽和 API 配额限制，Microsoft 环境也有各自的限流机制。

不要计划在一个周末集中迁移所有邮箱。应分阶段进行：

1. 提前两到三周复制较早的邮件。
2. 用户继续工作时，将近期邮件留在源端。
3. 在最终切换窗口执行增量同步。
4. 修改 MX 前核对邮件数量。

这一步可以让迁移更易管理，也可能减少支持请求，因为用户首次登录时已经能看到大部分历史邮件。

从 Gmail 迁移时，请注意标签问题。一封带多个标签的邮件，在不合适的 IMAP 流程中可能被视为不同文件夹里的多份副本，迅速增加容量并产生重复。实用的邮箱迁移检查清单应明确核对 Gmail 标签映射，并在适当情况下排除不适合直接迁移的结构，例如特别大的汇总归档。

如果偏好独立工具，可以比较 imapsync。如果希望直接在托管控制面板内迁移，TrekMail 的服务器端导入可避免整个任务都经过某位管理员的笔记本电脑。

4. 在切换前降低 DNS TTL，而不是切换时

切换清单必须包含 DNS 时间安排。修改 MX 后再降低 TTL，不会缩短已缓存旧答案的有效期。应至少提前 24 到 48 小时降低 TTL，并考虑原有 TTL，避免外部解析器继续长时间缓存旧答案。

典型问题是新旧投递目标并存：部分系统看到新 MX，另一些继续投递到旧服务器。面板显示迁移“完成”，但新邮件仍悄悄留在旧服务商处。

可以参考以下时间安排：

TrekMail 所需记录见必需 DNS 记录文档。如果在切换期同时使用两家服务商发信，SPF 可能需要暂时授权双方。SPF 定义见 RFC 7208，DMARC 行为定义见 RFC 7489。

example.com. 300 IN MX 10 mail.trekmail.net.
example.com. 300 IN TXT "v=spf1 include:_spf.google.com include:spf.trekmail.net -all"

临时合并 SPF 授权是邮箱迁移检查清单中的实用项目。旧 include 应在适当的后续阶段移除，而不是 MX 切换五分钟后就自动删除。

5. 按邮件数量验证，而不是只看容量

严谨的清单应先验证邮件数量。邮箱容量容易产生误导：服务商计量方式不同，附件编码存在额外开销，Gmail 标签又可能让同一邮件出现在多个文件夹中。

管理员在这里容易不必要地担心。源端显示 10.2 GB，目标端显示 9.8 GB，并不自动意味着数据丢失。MIME 编码、存储引擎和去重机制都会影响报告的容量。

建议按以下顺序验证：

1. 检查邮件总数。
2. 检查收件箱、已发送、草稿和归档等重要文件夹。
3. 抽查日期范围及附件较多的会话。
4. 最后再将报告的容量作为粗略参考。

数量一致且抽查通过，通常是迁移成功的良好迹象。数量不符时，应停止并调查，再决定是否宣布完成。

也要测试实际邮件流：从域外、域内，以及公司最容易出问题的设备发信。Outlook、iPhone Mail 和旧扫描仪能揭示控制面板没显示的问题。

6. 安排客户端重新登录和配置重建

如果清单止于服务器状态，就还不完整。用户需要在手机、电脑、平板和旧邮件应用中重新登录。很多时候，删除后重新添加账户比修复旧配置更快。

这时可能迎来大量支持请求。邮箱和 DNS 正常，但 Outlook 仍尝试上次的配置，或手机保留着 Google、Microsoft 的旧令牌，无法连接新 IMAP 服务。

首次使用说明应写清楚：先保存本地尚未同步的数据，再移除旧账户、添加新账户，并使用准确的 IMAP 和 SMTP 设置。TrekMail 在适用于所有客户端的 IMAP 和 SMTP 设置中公布参数。源快照列出的标准值如下：

IMAP host: imap.trekmail.net
IMAP port: 993
SMTP host: smtp.trekmail.net
SMTP port: 465
Username: full email address
Password: mailbox password

还有一点：根据源快照，TrekMail 仅支持 IMAP，不支持 POP3。在 2026 的配置中，设备间共享同步状态可能比旧式的下载后删除行为更重要。

如果管理许多域名或客户环境，这一步支持工作会很快复杂起来。此时运营结构不亚于迁移工具本身的重要性。这方面需要更广泛地规划多域名邮箱托管。

7. 决定是否需要迁移所有旧邮件

合理的清单有时会建议“不必全部迁移”。如果用户很少查看十年前的邮件，单独导出归档并建立新的工作邮箱，可能降低风险、缩短切换时间并减少故障影响。应同时满足保留义务并保证归档可访问。

人们常跳过这一环节，因为协调起来不容易。但在在线迁移中转移 15 年的收据、简报和已结束项目会话，会增加时间成本和失败风险。如果归档很少使用，在核对要求后，可以将它移出关键路径。

传统方式与另一种选择的区别很简单：

传统方式：因为一个邮箱有几乎无人查看的 40 GB 历史邮件，长期承担按用户计费的支出。

另一种选择：归档不再用于日常工作的内容，只迁移用户实际需要的数据，并采用共享存储，避免单个大邮箱给全团队的许可安排带来额外压力。

这也是整理过度扩张的邮箱环境时可以考虑 TrekMail 的原因之一。根据源快照，可免费开始，付费套餐每月 $3.50 起，提供需要信用卡的 14 天免费试用。Nano 被描述为无需信用卡且持续免费。请核对现行条件。

邮箱迁移检查清单：最终操作流程

这份简版可以放入变更工单，涵盖实际 IMAP 切换中的基本控制措施，帮助避免常见故障。

1. 清点每个邮箱、别名、共享邮箱、群组、路由和发信应用。
2. 确认 IMAP 可迁移内容，以及需要单独导出的内容。
3. 切换前预先复制旧邮件。
4. 提前 24 到 48 小时降低 MX TTL。
5. 如果新旧系统在过渡期都要发信，准备临时 SPF 双方授权。
6. 修改 MX 前执行最终增量同步；随后保留旧服务器，检查后续投递，并在有新邮件时再次同步，直到验证完成。
7. 核对数量、检查文件夹，并实际测试发送和接收。
8. 必要时重建客户端配置，不要在损坏的缓存设置上浪费数小时。
9. 核对保留要求后归档不再使用的历史内容，不要默认全部迁移。
10. 验证结束前，保留访问旧系统的能力，以便回退。

邮箱迁移检查清单的目的就在于此：不是追求形式漂亮，也不是理论，而是减少意外。

如果在寻找适合 IMAP 迁移的目标平台，请到 TrekMail 价格页面比较套餐。源快照列出了自定义域名、IMAP 邮箱、catch-all、BYO SMTP 或托管 SMTP、邮箱转发和内置迁移工具；具体可用性取决于套餐，计费模型被描述为不按用户收费。