邮件迁移到另一家服务商：IMAP、文件夹与核验

把邮件从一家服务商迁到另一家听起来简单，直到邮箱被导入两遍，或有人发现已发送邮件的历史不见了。很多指南恰恰略过这一步，把邮件当作文件。邮箱迁移并不只是复制文件。

你正在两个服务器之间复制不断变化的 IMAP 数据。它们的文件夹规则、UID 行为，以及“已发送”文件夹的定义都可能不同。一个错误假设就可能造成文件夹看似为空、会话重复，或邮件分散在新旧系统中。

解决办法不是碰运气，而是分阶段执行 IMAP 同步、明确文件夹映射，并在切换后认真核验。如果还需要规划服务商、价格和管理权限，先阅读我们的企业邮箱指南。本文集中讨论迁移本身。

准备迁到 TrekMail 时，先查看最新的 IMAP 迁移概览，再按源服务器选择 Gmail 或 cPanel 指南。原文介绍付费方案提供服务器端 IMAP 迁移，价格从每月 $3.50 起，Nano 免费且无需信用卡，付费方案可免费试用 14 天。请在安排迁移前核实当前价格、功能和试用条件。

把邮件迁到另一家服务商，实际发生了什么？

简而言之，IMAP 工具登录旧邮箱，读取文件夹和邮件，再复制到新邮箱。它不一定会自动统一文件夹名称、清理源数据中的重复邮件，或避免 DNS 切换时机的错误；这些需要流程中的专门措施。

IMAP 迁移是在两个邮件系统之间复制数据。单纯复制通常保留源账户，在目标中建立新的邮件副本、文件夹，以及工具和服务商支持的已读、未读等标记。联系人、日历和规则不属于这项 IMAP 复制。关键问题之一是两台服务器如何识别邮件。

RFC 3501 描述的 IMAP 模型为每个文件夹提供邮件 UID 和 UIDVALIDITY。UID 只在该文件夹及相应 UIDVALIDITY 下有效，不是全局标识，也不能直接跨服务器比较。工具可能结合这些值与保存的映射跟踪复制状态；状态变化时，部分匹配方式可能不再识别先前的副本。

因此，首轮看似正常，第二轮仍可能出问题。不能仅凭面板显示“完成”，就向用户承诺整个迁移已经结束。

为什么迁移邮件会产生重复副本

简而言之，当工具无法可靠识别邮件是否已复制时，就可能产生重复。原因包括 UIDVALIDITY 变化、目标文件夹被重建，或把 Gmail 标签当成普通文件夹。具体结果取决于匹配策略：已有邮件可能被当作新邮件再次复制。

UIDVALIDITY 的陷阱

一些工具保存文件夹内的 UID 映射。服务器重新索引不一定改变 UID，但重建文件夹、实际改变 UIDVALIDITY 或丢失工具状态可能使旧映射失效。不是所有工具都用同一种策略：imapsync 默认匹配 Message-Id 和 Received；使用相应 UID 模式时依赖本地缓存映射，而不是假定两台服务器的 UID 相同。

RFC 3501 描述的原则要求 UID 在同一 UIDVALIDITY 下保持稳定，并能通过 UIDVALIDITY 识别相关变化。UIDVALIDITY 改变后，不能未经验证继续信任旧 UID 映射。缺少适当的重新匹配时，第二轮可能再次导入数千封邮件。

例如，首轮从收件箱复制 38,000 封邮件。管理员在超时后重跑任务，而源文件夹或目标文件夹已在夜间重建。工具无法沿用旧 UID 映射，某些策略下可能再复制 38,000 封邮件。

Gmail 标签需要单独规划

Gmail 的标签机制不同于普通的文件夹式 IMAP。一封邮件可以有多个标签，归档邮件仍在“所有邮件”中。Google 的 Gmail 帮助说明了多标签机制，也解释了归档会移出收件箱，但邮件仍保留在“所有邮件”。

如果不加规划地同时导入 [Gmail]/All Mail 和标签文件夹，同一邮件可能出现在目标的多个文件夹中。这会占用更多空间，也可能让用户困惑。不过，多文件夹副本也可能是有意保留标签的表现形式。应先约定目标邮箱需要怎样呈现这些邮件。

手动处理 Gmail 时，可以从 TrekMail 的从 Gmail 导入指南了解源端登录要求。应用专用密码是否可用取决于两步验证、账户类型和组织策略。TrekMail 文档中的直接导入使用 IMAP 用户名和密码，不提供交互式 OAuth 登录；无法取得合适直接凭据时，需考虑其他支持 OAuth 的工具或服务商支持的方法。

命令行工具可以参考下面的检查示例，但不能把它当成普遍安全、直接可用的迁移命令：

imapsync \
  --host1 imap.gmail.com \
  --user1 user@gmail.com \
  --password1 'APP_PASSWORD' \
  --host2 mail.newhost.com \
  --user2 user@example.com \
  --password2 'DEST_PASSWORD' \
  --exclude "\\[Gmail\\]/All Mail" \
  --useheader "Message-ID" \
  --dry

检查运行不会复制邮件，也不能完整验证后续内容传输。Message-ID 可能缺失或重复，单靠它不能保证可靠去重。排除“所有邮件”会遗漏没有其他被导入标签的归档邮件，因此要另行安排并验证整个归档的迁移。确认连接加密和证书验证，避免真实密码暴露在命令历史或进程列表中。更多操作细节见 imapsync 指南。

为什么迁移后看不到文件夹

简而言之，文件夹往往并未消失，而是进入错误层级，被当成普通文件夹而非系统文件夹，或带有客户端显示方式不同的前缀。也可能确实被遗漏，需要核验。

命名空间和层级分隔符冲突

不同 IMAP 服务器使用不同命名空间和层级分隔符。有的用点，例如 INBOX.Sent；有的用斜杠，例如 Inbox/Sent Items；还有的要求 INBOX. 前缀。

如果导入前或导入时没有正确映射，层级就可能改变。Project.Alpha 可能变成 Project 下的子文件夹，系统文件夹可能显示成自定义文件夹。手机邮件应用还可能订阅错误文件夹，让真正需要的文件夹不可见。

已发送文件夹名称不一致

已发送邮件往往最先引起用户担忧。一家服务商写入 Sent，另一家期待 Sent Items，还有的显示为 Sent Messages。

如果旧文件夹被复制成普通自定义文件夹，而没有映射到目标的系统文件夹，默认“已发送”可能仍为空。用户会觉得多年邮件丢失，尽管数据实际存放在别处。

源端是虚拟主机时，TrekMail 的从 cPanel 或其他主机迁移指南介绍常见 IMAP 凭据配置。它能帮助准备连接，但不能替代实际登录、命名空间、系统文件夹用途和客户端设置的检查。表中的映射只是示例。

分 3 阶段规划邮件迁移

简而言之，三阶段同步有助于控制风险。先预复制旧邮件，在切换前后进行增量同步，再修改 MX 并持续安排必要的补同步。这通常能减少中断和重复风险，但不能保证零停机或零重复。

1. 历史同步。先复制较旧邮件，例如早于 30 天的邮件。这样可以在用户仍使用旧系统时完成大部分数据传输。
2. 增量同步。再次同步新增或变化的数据，并可靠匹配已导入历史。还要覆盖切换期间移动的邮件和带有较旧日期的迟到邮件，不能只按日期窗口筛选。
3. 切换与补同步。完成预检查后修改 MX。保留旧服务器接收邮件和管理员同步访问；DNS 缓存及投递重试可能在 TTL 到期后仍把邮件送到旧端。

DNS 配置有误，可能让新邮件继续进入旧主机或遭到拒收。切换时可参考 TrekMail 的必要 DNS 记录文档。下列记录仅作示例：核对当前文档和账户面板，保留所有合法发送服务的 SPF 授权，并验证有效且对齐的 DKIM 签名。不要迁移时盲目启用更严格的 DMARC 策略。

; Example cutover records
@      MX   10 mail.trekmail.net.
@      TXT     "v=spf1 include:spf.trekmail.net -all"
_dmarc TXT     "v=DMARC1; p=quarantine;"

只有在结果核验和客户端切换完成后，才限制旧服务器的用户访问和写入。旧 SMTP 接收、管理员补同步及回退能力可能还需要保留。如果用户继续同时操作两个系统，收到的邮件和新发出的邮件会分散在两端，之后就需要持续核对邮件并补同步。

分阶段方法也可以帮助服务机构和托管服务提供商。管理多个品牌或客户域名时，难点不只是复制邮件，还有流程协调。适合多域名邮箱托管的平台可以提供帮助，但不能自动代替全部迁移管理。

迁移后的核验清单

简而言之，检查邮件数量、最早和最新邮件日期，以及文件夹层级。不要只看总容量。压缩、索引和附件处理可能改变显示大小，并不一定意味着邮件缺失。

1. 比较邮件数量，而不只是邮箱大小

如果源收件箱有 4,502 项，在统计范围一致并考虑约定排除项后，目标通常应有 4,502 项。容量可能不同，但数量一致不证明完整性。还要比对邮件、内容、附件、标记、日期和文件夹映射。Gmail 应区分唯一邮件数量与标签副本数量。

2. 检查最早和最新的邮件

按日期排序，比较收件箱、已发送等关键文件夹里最早和最新的邮件。缺少最早邮件，应检查历史同步；缺少最新邮件，应检查增量和切换补同步。过滤条件和映射错误也可能是原因。

3. 查找位置异常的文件夹

检查根层级的 INBOX.Sent、残留的 [Gmail] 文件夹，以及重复的已发送文件夹。它们可能提示映射错误，也要与约定的目标结构核对。

4. 测试真实收信和发信

从外部邮箱发信，再从目标账户回复。确认接收情况、可能的过滤或隔离，以及回复是否保存在正确的已发送文件夹。一次测试不能代表所有实际投递路径。

5. 检查新客户端设置

数据复制正确，客户端仍指向旧服务器，也会让用户以为迁移失败。切换后按 TrekMail 最新 IMAP 和 SMTP 设置更新应用。如果新平台已收信但用户看不到，检查登录、文件夹订阅和过滤规则。

因此，迁移数据和更换服务商要一起规划。我们的 Titan Email 替代方案文章从服务商切换角度说明同一问题：复制邮箱只是整体变更的一部分。

手动流程与 TrekMail 管理方式

简而言之，手动迁移可能重复繁琐且存在许多边界情况。服务器端 IMAP 迁移、适当的重复检测、共享存储和集中管理可以减轻工作，但取决于当前方案功能和实际源端、目标端的支持。

小团队可能减少管理负担，服务机构可能更方便核算成本。管理员可以把原本分散在五处的工作集中起来，但这不表示所有旧方案都较差。请查看最新 TrekMail 价格。Nano 免费和付费方案免费试用 14 天是原文中的说明，实际以当前条件为准。

总结

如果需要把邮件从一家服务商迁到另一家，并尽量减少重复、文件夹遗漏和停机风险，应把它当作受控的 IMAP 切换，而非批量文件传输。导入前映射文件夹，安排整个 Gmail 归档的迁移，分阶段同步，核验的不只是数量。客户端切换和结果确认后再关闭旧用户访问，同时保留必要的接收与补同步。

如果考虑迁移后由 TrekMail 托管，可从 trekmail.net 开始。核实当前多域名方案计费、共享存储和内置 IMAP 迁移条件。新增用户的费用与限制取决于方案，不能保证所有迁移都无数据损失、无中断或永远不增加成本。