你可以安全地从 gmail 迁移邮件。当人们把 Gmail 当作普通 IMAP 服务器时，问题就开始了。Gmail 并非如此，它使用标签而不是真正的文件夹。正是这个细节让迁移占用过多空间、陷入停滞或把已发送邮件放到错误位置。如果因为按用户计算的费用持续上涨而离开 Workspace，请先选择正确的模式，以后就不必再进行复杂清理。
如果想先了解成本和平台的完整情况，请阅读企业电子邮件。本指南讲解执行层面：如何迁移邮件、避免重复、切换 DNS，并验证邮件没有丢失。
简要方法很简单。先同步旧邮件，准备就绪后切换 MX，再执行最后一次补充同步。按照邮件数量而不是邮箱容量验证。这是把邮件从 gmail 迁移到 TrekMail 等标准 IMAP 服务商最稳妥的方式。
Gmail 为什么会让普通 IMAP 迁移出现问题
从 gmail 迁移邮件时，主要风险是重复。Gmail 通过 IMAP 显示标签，因此同一封邮件可以出现在多个位置。如果迁移工具复制每个可见文件夹，同一封邮件就可能被多次导入，目标邮箱也会迅速膨胀。
在普通 IMAP 邮箱中，一封邮件位于一个文件夹。在 Gmail 中，一封邮件通常存放在 All Mail 中，再叠加多个标签。通过 IMAP 查看时，这些标签可能看起来像独立文件夹。
这就是陷阱。
如果一封邮件带有 Inbox、Project A 和 Urgent，基础迁移工具可能尝试复制三次。Microsoft 明确记录了 Gmail 向 IMAP 迁移中由标签导致的重复问题，尤其是在没有排除 [Gmail] 文件夹时。IMAP 只是 RFC 3501 定义的传输层。特殊之处在于 Gmail 呈现文件夹的方式，而不是协议本身。
如果只记住一条规则，请记住：从 gmail 迁移邮件时，应排除 [Gmail]/All Mail，除非有非常明确的理由需要它。这个选择能防止多数存储空间暴增和“为什么全部重复”的支持请求。
有关 TrekMail 的具体步骤，请参阅Gmail 迁移文档。如需了解更广泛的机制，IMAP 迁移概述说明了服务器端导入模式。
从 gmail 迁移邮件时会转移哪些内容
通过 IMAP 从 gmail 迁移时，只会转移邮件数据：正文、附件、文件夹位置，以及支持情况下的读取状态。整个 Google 账户不会随之移动。日历、联系人和 Google Drive 文件需要单独导出。
人们常常高估电子邮件迁移的范围。IMAP 只迁移邮件，仅此而已。
具体情况如下：
| 数据类型 | 是否通过 IMAP 转移？ | 说明 |
|---|---|---|
| 电子邮件 | 是 | 正文、附件、日期、文件夹，通常还有已读或未读状态 |
| 标签 | 部分 | 通常变成文件夹，这正是 Gmail 可能重复邮件的原因 |
| 联系人 | 否 | 从 Google 通讯录单独导出为 CSV 或 VCF |
| 日历 | 否 | 从 Google Calendar 单独导出为 ICS |
| Google 文档 | 否 | 它们属于 Drive 项目，不是邮箱内容 |
身份验证同样重要。使用第三方工具从 gmail 迁移邮件时，通常需要应用专用密码。Google 表示，应用专用密码是 16-digit 密码，只有启用 2-Step Verification 后才有效。部分工作或学校账户可能无法使用，这在 Google Workspace 环境中属于实际限制。安排切换前，请查看 Google 的应用专用密码帮助文档。
许多迁移指南忽略了这一点，只说“生成应用专用密码”，仿佛每个账户都能做到。实际并非如此。如果管理员限制了该选项，应采用支持 OAuth 的迁移方式，不要在无效凭据上浪费时间。
从 gmail 迁移邮件的最安全方式
最安全的方法是分阶段切换 IMAP：先同步旧邮件，再切换 MX，最后执行增量同步。这样能避免周末出现紧急状况，减少用户受到的影响，并遵守 Google 的速度限制，而不是假装限制不存在。
不要在周五晚上集中切换。用户仍在 Gmail 中工作时，先迁移邮箱的大部分内容，切换时只处理近期增量。这才是专业的操作方式。
- 盘点邮箱。检查邮箱容量、异常标签，以及应用专用密码或 OAuth 是否可用。确认每个文件夹确实需要迁移。垃圾邮件同样会消耗资源，迁移以后准备删除的内容只会拖慢工作。
- 先运行试点。选择一个低风险邮箱，用它确认文件夹映射、已发送邮件位置，以及工具是否正确处理 Gmail 特殊文件夹。试点若很混乱，50-user 的迁移只会更糟。
- 预先同步旧邮件。先迁移超过 30 天的邮件，大部分数据量都在这里。批量传输在后台进行时，用户仍可在 Gmail 中工作。
- 切换 DNS。提前降低 TTL，在目标邮箱准备就绪后把 MX 切换到新服务商。在 TrekMail 中可以添加域名、发布所需记录，并从控制面板验证状态。必需 DNS 记录文档涵盖完整的记录集合。
- 执行增量同步。邮件开始进入新服务器后，再同步一次近期时间段，收集最后到达的邮件和读取状态变化。
如果同时迁移多个品牌或客户域名，固定价格的基础设施会比按用户收费的套件更合理。TrekMail 正是为此模式设计。有关整体经济性，请参阅多域名电子邮件托管。
使用 imapsync 从 gmail 迁移邮件的手动命令
如果需要完全掌控，imapsync 是通过 IMAP 从 gmail 迁移邮件的标准命令行工具。关键在于排除 Gmail 归档文件夹，并正确映射特殊文件夹，让已发送邮件和草稿出现在用户预期的位置。
实用模板如下：
imapsync \
--host1 imap.gmail.com --port1 993 --ssl1 \
--user1 "user@source-domain.com" --passfile1 "/path/to/gmail_pass" \
--host2 imap.trekmail.net --port2 993 --ssl2 \
--user2 "user@dest-domain.com" --passfile2 "/path/to/dest_pass" \
--gmail1 \
--exclude "\\[Gmail\\]/All Mail" \
--exclude "\\[Gmail\\]/Trash" \
--exclude "\\[Gmail\\]/Spam" \
--regextrans2 "s/^\\[Gmail\\]\\/Sent Mail/Sent Items/" \
--regextrans2 "s/^\\[Gmail\\]\\/Drafts/Drafts/" \
--dry各参数的作用：
| 参数 | 重要原因 |
|---|---|
--gmail1 | 针对 Gmail 的行为调整源端 |
--exclude "\[Gmail\]/All Mail" | 避免最主要的重复导入来源 |
--exclude Trash/Spam | 不把垃圾邮件和已删除邮件带到目标端 |
--regextrans2 | 把 Gmail 文件夹名称映射为标准 IMAP 文件夹名称 |
--dry | 模拟执行，以便在复制数据前检查数量 |
务必先进行试运行。
如果 TrekMail 是目标端，标准客户端设置为 imap.trekmail.net，使用 993 端口和 SSL/TLS。TrekMail 仅支持 IMAP，不支持 POP3，这正适合需要同步的邮箱。如需客户端参考，请查阅 IMAP 和 SMTP 设置文档。
如需更深入的命令行操作指南，请阅读 imapsync。它与本流程相互补充。
Gmail 迁移中需要注意的故障
从 gmail 迁移时，最重要的三种故障是 Google 速度限制、身份验证中断，以及少量无法读取的邮件。它们都不必引起恐慌。应暂停、调整并仔细验证，而不是盲目重新运行。
第一种是速度限制。Gmail 会减慢或暂时阻止过于激进的 IMAP 拉取。此时正确的做法是等待，而不是不断重试。
第二种是身份验证循环。迁移可能运行一段时间后，因为 Google 标记登录而失败。检查账户安全活动，确认登录，然后按照相同的会话设计重试。如果问题只是账户信任，不要不断更改其他变量。
第三种是幽灵项目。一个包含数万项目的邮箱，报告中可能只有少量失败邮件。这通常表示数据块损坏、邀请异常或零字节项目。如果遗漏率极低，应将其视为可接受的杂项，而不是灾难性丢失。
错误的逻辑是：不断重新运行整个任务，直到报告完全没有问题。
正确的逻辑是：判断失败的是用户真正可见的邮件，还是原本就无法读取的损坏项目。
还有一个操作细节：不要用存储容量判断成功。Gmail 容量与 IMAP 目标端容量并不能直接比较，因为压缩、元数据和邮件表示方式不同。应根据项目数量，以及对收件箱、已发送和用户文件夹等关键位置的抽查来判断。
如何验证从 gmail 迁移邮件确实成功
应比较邮件数量和文件夹位置，而不只是存储容量。检查收件箱、已发送、草稿和几个用户创建的文件夹。MX 更改后再发送真实测试邮件，确认新邮件进入目标服务器。
使用以下清单：
- 比较 Gmail 与目标邮箱的总项目数。
- 检查收件箱项目数和未读数。
- 打开 Sent Items，确认已发送邮件没有进入随意的自定义文件夹。
- 打开 3 到 5 个名称不寻常或包含嵌套标签的文件夹。
- 搜索几封带附件的旧邮件，确认能够打开。
- MX 切换后发送真实的入站测试邮件。
- 从新邮箱回复，确认 SMTP 和 DNS 工作正常。
如果同时迁移域名，规范的 DNS 与邮箱复制同样重要。遗留的 Google MX 记录会让投递分流，使人误以为迁移失败，实际上是路由混合。切换前建议使用 TrekMail 的域名添加和 DNS 检查文档。如果仍在规划目标邮箱结构，使用域名创建电子邮件是合适的补充读物。
旧方式与新方式
旧方式是长期按席位向 Google Workspace 付费，却把迁移当成一夜完成的项目。新方式先准备数据、验证数量，再迁移到适合多域名运营的固定价格基础设施，不让增长受到惩罚。
旧方式：继续按用户向 Google Workspace 付费，因为感觉有风险而推迟迁移，最终又在一个周末仓促执行，只能期待邮箱数量恰好一致。
新方式：预先同步大部分邮箱，规范切换 DNS，执行最终增量，再进入专为自定义域名和共享存储空间设计的平台。TrekMail 每月 $3.50 起，支持自定义域名、IMAP 邮箱、邮件转发、catch-all 路由、根据套餐自带或自行提供 SMTP，以及从控制面板进行服务器端迁移。
如果需要没有按用户费用的多域名邮件服务，这是实用路径。你可以查看 TrekMail 定价，先用免费套餐测试流程，并在试点成功后进行正式迁移。
总之，从 gmail 迁移邮件不必过度复杂化。排除 All Mail，执行分阶段同步，在目标端准备就绪后切换 MX，并按邮件数量验证。这样就能避免重复混乱，也不必在周一早上陪着用户处理损坏的收件箱。
