迁移邮箱账户：盘点、IMAP 与分阶段切换

企业迁移邮箱账户，不能只照搬个人收件箱的做法。新邮件仍在到达，用户仍在回复，别名继续路由，DNS 错误可能把投递分散到两个系统。正确顺序是先盘点、再预复制、最后切换。修改 DNS 前，可先读企业邮箱指南了解整体运维。

常见问题是，有人导出 PST，有人在 Outlook 拖文件夹，还有人把所有地址都看成普通邮箱。周一 sales@ 不再收信，大邮箱仍在同步，团队不清楚哪台服务器的数据才是准的。应把迁移当作运行中基础设施的切换，而非复制文件。

本指南说明如何用可控流程迁移邮箱账户，涵盖手动 IMAP、切换顺序、主要故障和团队、服务机构、托管服务商的 TrekMail 管理方式。平台可以减少脚本维护，但不能保证更快或完全无中断。

迁移邮箱账户是什么意思？

先复制 IMAP 邮箱内容，再单独恢复别名、转发等路由配置，必要时切换自己管理的域名的接收 DNS。个人 Gmail 或 Outlook 的导入不会让你控制其域名 MX，也不会自动迁移原地址。

这个定义很重要，因为 IMAP 只覆盖部分工作。它复制文件夹和受支持的邮件状态，不会迁移邮箱相关的全部设置和服务。RFC 3501 描述的是邮件访问与邮箱操作协议，并非完整导出企业账户身份的格式。

因此实际有三项任务：

1. 复制并核验邮件和文件夹结构。
2. 获得必要授权后恢复别名、分发组和转发。
3. 自有域名更换接收系统时，在目标就绪后切换 DNS。

遗漏必要任务，就还没有完整验证迁移，之后可能转化成支持问题。

IMAP 能迁什么，不能迁什么

源端与工具支持时，IMAP 可以复制邮件、文件夹，通常也保留已读和未读状态。日历、联系人、任务、桌面签名和客户端规则不随它迁移。要先单独规划，避免用户到新端后才发现缺少功能。

应书面约定范围。TrekMail 的文档流程基于 IMAP，并不等同于协作办公系统迁移。指南因此关注源主机、端口、用户名、密码和目标邮箱，而不是日历与共享日程。

盘点时可用下面的分类：

最后一项最容易漏掉。独立邮箱和别名有什么不同，可参考别名与邮箱指南。正确分类能减少后续修正。

迁移账户前先盘点

第一次同步前建立尽量完整的清单，有助于控制风险。给每个邮箱、别名、组、转发规则和存储需求安排对应目标对象及迁移批次。

用户导出表还不够，隐蔽功能也要登记。

至少检查这些对象：

1. 主要邮箱：活跃用户、共享邮箱和职能邮箱。
2. 别名：投递到其他邮箱的附加地址。
3. 分发列表或组：不是普通 IMAP 收件箱的路由对象。
4. 转发：服务器端路径，例如 info@ 到 owner@。
5. Catch-all：明确决定保留、收紧还是停用未知收件人接收。
6. 大邮箱：提前启动并核实限制。

大邮箱会改变整体时间安排。服务商可能限制 IMAP，大归档可能要几天而非几小时。没有测量试点结果，不应为多年附件承诺周末完成。

例如，周五安排 60 位用户切换，一位高管的邮箱有 48 GB。到周日，59 位用户完成，而大邮箱仍在复制。这是可能出现的规划风险示例，不是通用工期，应该提前考虑。

迁移中也要规范新账户创建时，可以结合批量创建邮箱账户操作指南。目标准备不全，和 DNS 一样可能引发问题。

多个邮箱如何分批迁移

分批处理，而非一次性切换全部。试点确认凭据、文件夹映射和连接；预复制在后台传旧邮件；接着用补同步覆盖变化，并与 DNS 切换协调。

一个实用顺序是：

第 1 批：试点

先选少量 IT 人员、测试账户和一位邮箱具有代表性的普通用户。确认端口 993 上的 TLS、证书链与主机名，验证凭据，检查已发送、草稿、归档和自定义文件夹的映射。

第 2 批：预复制

在计划切换的周末前启动大批量传输。让历史邮件提前到位，避免 MX 已切换后才开始等待多年邮件的复制。

第 3 批：补同步与切换

切换前同步新数据和变化。按需要修改自有域名 MX 并验证新端收信，之后继续补同步迟到的旧日期邮件、移动和标记变化。保留旧 SMTP 接收、管理员同步和回退能力，以覆盖缓存及投递重试。用户应只在一个系统上工作；不能把它当成安全的双向同步。

这样可把限速、周末工作和用户问题纳入计划，而不是赌单次任务一定顺利。

使用 imapsync 手动迁移账户

需要直接控制时，可以考虑 imapsync 这类 IMAP 到 IMAP 工具。它依版本与配置支持重试、文件夹映射和邮件标记，但结果仍要核验。

Outlook 拖放、PST 导出和凭记忆输入命令可能难以审计。客户端操作应复制而非破坏性移动，并先备份本地数据。

可重复批量执行、每邮箱日志和计划好的补同步更便于检查。TrekMail 可以集中部分流程，无需管理员自行维护全部组件。深入操作见管理员 imapsync 指南。

下面保留原文的批处理示例，不能直接当作有效脚本运行。Shebang 不正确，需先修改自己的工作副本。核对已安装版本的密码、日志、快速模式和大小比较选项，以及最新应用设置中的目标 IMAP 主机。日志开关并非日志文件名参数，快速模式等选项也需确认。按逗号简单拆分不支持带引号、逗号或换行的完整 CSV。明文凭据文件需限制访问，避免密码暴露在进程列表和日志中：

#!$0

# users.csv format:
# source_user,source_pass,dest_user,dest_pass

while IFS=, read -r src_user src_pass dest_user dest_pass
do
  echo "[START] $src_user -> $dest_user"

  imapsync \
    --host1 imap.old-provider.com --user1 "$src_user" --pass1 "$src_pass" --ssl1 \
    --host2 mail.trekmail.net --user2 "$dest_user" --pass2 "$dest_pass" --ssl2 \
    --automap \
    --usecache \
    --fast \
    --skipsize \
    --subfolder2 "Imported_Mail" \
    --log "logs/${src_user}.log"

  echo "[DONE] Review logs/${src_user}.log"
done < users.csv

几项实用提醒：

有意识地使用缓存。受支持的缓存模式可能减少重复读取元数据，但它是可选的，要符合具体策略。UID 不是全局标识，缓存也不是内容完整性的证明。

必要时使用暂存文件夹。分开存放导入邮件可能方便核对，但不能解决两端同时使用的冲突。示例改变目标路径，不代替最终系统文件夹映射，也不保证正确处理移动或删除。

保留各邮箱日志。需要定位哪个邮箱、在哪一步、为何失败。无条件输出的 DONE 不证明成功；应检查退出状态、脱敏日志、数量、内容、附件、日期、映射和标记。限制文件权限并清除诊断中的秘密信息。将删除同步到另一端属于破坏性操作，需单独规划和核验。

DNS 切换需要独立检查

自有域名更换接收系统时，先降低 MX TTL 并考虑旧缓存的实际到期时间，目标就绪后再切换并按计划清理旧 MX。验证新端收信，同时保留旧端接收及补同步，处理缓存和重试带来的迟到邮件。

同步完成本身不会改变投递。自己的域名通过 DNS 指定接收；个人服务商地址仍需保留原账户或使用获准转发。

未协调的切换可能让邮件散在新旧主机，两边都看似部分正常，数据却逐步分离。需要补同步和明确的用户工作环境切换。

按最新 TrekMail 文档和账户面板检查记录。以下只是示例：保留所有合法发送服务的 SPF 授权，发布匹配 DKIM 密钥并验证实际签名。DMARC 需要成功且对齐的 SPF，或有效且对齐的 DKIM 签名；迁移时不要未经核验就收紧策略：

@                 MX   10 mail.trekmail.net.
@                 TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey   TXT  "<unique TrekMail DKIM value>"
_dmarc            TXT  "v=DMARC1; p=quarantine;"

切换时检查：

1. 不再需要的旧 MX 已按计划移除。
2. 正确的新 MX 已发布。
3. 每个名称的一项 SPF 策略保留全部必要发送服务，其他无关 TXT 可以共存。
4. DKIM 已发布，实际有效签名已验证。
5. DMARC 已发布，至少一个成功且与 From 对齐的验证途径已确认。
6. 测试邮件在新端收到，旧端迟到邮件仍被记录和复制。

切换后关注投递和退信。Gmail 流量重要时，Google Postmaster Tools 可以提供额外但不完整的信息。最后一封邮件复制完还不够，接收、发送和持续运行也要确认。

TrekMail 的账户迁移流程

TrekMail 文档中的服务器端工具可从合适的 IMAP 访问复制邮件，可能减少自建虚拟机和脚本维护。管理员仍要检查连接、错误、文件夹及补同步。

可能的方式差异如下：

核对最新步骤：

1. 添加域名并准备 DNS，MX 等预复制核验后才切换。
2. 创建目标邮箱并测试登录。
3. 在面板打开迁移。
4. 输入源 IMAP 主机、端口、用户名和合适密码。
5. 选择 TrekMail 目标邮箱。
6. 运行导入，观察状态并核对实际结果。

可查阅 IMAP 迁移概览、在面板启动迁移、创建邮箱以及必要 DNS 记录。文档中的直接导入使用 IMAP 用户名和密码，不支持交互式 OAuth。Gmail 应用专用密码取决于两步验证及账户策略；强制 OAuth 时要选择其他受支持途径。

原文介绍 Starter 每月 $3.50 起、Nano 为 $0，以及 Starter、Pro、Agency、Enterprise 付费方案。Nano 免费无需信用卡和付费方案免费试用 14 天需信用卡，是原文条件，需核实当前情况。共享存储可能更方便分配大邮箱，但总容量和功能仍有方案限制。

比较时直接看最新 TrekMail 价格。

运行中团队的切换检查清单

修改 MX 前的最后检查可以发现遗漏别名、旧 DNS、错误密码和未完成的大邮箱复制。它有助于降低风险，但不保证无损迁移。

切换前确认：

1. 所有目标邮箱已创建且登录成功。
2. 别名、转发和组已获准恢复并测试。
3. 源 IMAP 的 TLS 端口 993 可用，证书与主机名已验证。
4. 大邮箱提前预复制并核验。
5. TTL 提前降低，旧缓存有效期已考虑。
6. 旧 MX 和回退计划已记录。
7. 切换前后的补同步已安排。
8. 用户知道何时停止旧端修改，删除配置前已保护未同步本地数据。
9. 一个测试邮箱可验证接收和发送。
10. 切换后监控负责人已指定。

这些都是常规步骤，但很重要。受控迁移是提前发现意外，而不是等用户遇到问题才处理。

总结：用可核验流程迁移账户

不论一个域名还是五十个域名需要迁移邮箱账户，先登记账户功能、预复制数据，再有计划地修改必要 DNS，切换后验证收信。IMAP 能复制邮件，但不能补救不完整的设计，也不能代替完整性检查。

需要直接控制并愿意维护工具时，手动方式仍可行。频繁迁移时，TrekMail 的多域名方案计费、共享存储、IMAP 导入和管理面板可能提供帮助。是否更适合或更省钱，取决于当前限制与实际需求。可以考虑 Nano，或查看价格了解付费导入功能。