从Google Workspace迁移邮件且不丢失消息

如果以错误方式从Google Workspace迁移邮件，到周一早上就可能出现邮件分流、别名遗漏和用户投诉。这是一项正式切换工作，不是简单的拖放导出。如果想先了解更全面的选购背景，请阅读企业电子邮件。如果已经开始规划迁移，本操作手册将说明如何把Google Workspace邮件迁移到TrekMail等IMAP主机，同时确保入站邮件正常送达。

问题很简单：管理员专注于复制旧消息，却忘了路由层。即使迁移已完成92%，邮件系统也不会因此等待。MX一旦更改，新消息就必须有明确去向。如果别名、群组、DNS和客户端没有同时准备好，就会形成两套收件箱。用户继续发信，客户继续回复，其中一部分邮件却落到错误位置。

解决办法在于顺序。先盘点，再预先迁移数据。DNS只切换一次。重新正确配置客户端，然后按项目数量验证，而不是凭感觉判断。TrekMail适合这种模式，因为它提供共享存储空间、固定价格的多域名托管、内置IMAP迁移以及标准IMAP/SMTP客户端支持，无需按用户付费。

从Google Workspace迁移邮件意味着什么？

要从Google Workspace迁移邮件，需要先通过IMAP移动已存储的邮件，再把实时邮件路由从Google切换到新服务商。复制数据很重要，正式切换更重要。如果在身份、DNS和客户端准备就绪之前更改路由，邮件会开始进入错误的收件箱。

这一区别很重要，因为Google Workspace在同一个管理界面中隐藏了多种身份类型。登录账户并不等于为该用户接收邮件的所有地址。共享别名、群组地址、转发路径和全域接收规则都会影响切换。

修改DNS之前，应先正确搭建目标端。在TrekMail中，通常需要添加域名、确认DNS记录、创建每个邮箱，并决定哪些地址应保留为别名，哪些应成为独立邮箱。以下文档有助于准备工作：添加域名，检查必需的DNS记录，并了解TrekMail如何处理Gmail迁移。

阶段1：复制前建立完整的取证式清单

从Google Workspace迁移邮件时，第一项实质工作是找出每个可以接收邮件的地址。主要用户很明显，迁移失败往往源于遗漏别名、群组和旧路由规则。如果遗漏这些地址，DNS切换后它们可能直接退信，或者悄无声息地进入死路。

先整理四份清单：

1. 主要用户及其邮箱大小。
2. 与每个用户关联的所有别名。
3. 仍在接收真实入站邮件的Google群组。
4. 仍出现在发票、联系表单或签名中的转发地址、全域接收地址和已停用地址。

这就是简单的管理员导出不够用的原因。销售人员可能使用jane@company.com登录，但仍会通过sales@company.com、quotes@company.com以及一个无人记录的旧收购域名接收实际邮件。漏掉其中任何一个，即使DNS正确，切换也会显得有故障。要顺利迁移Google Workspace邮件，每个可路由地址都必须有明确的目标位置。

从Google提取数据时，运维人员通常使用GAM或Admin SDK建立完整的路由图。具体工具并非重点，结果才是关键：在迁移Google Workspace邮件之前，每个可路由地址都必须在目标系统中有明确归宿。

gam print users aliases > aliases.csv
gam print groups members > group_members.csv

整理这些地址时，还要确定每个身份在新主机上应采用什么形式：

如果需要快速判断身份映射方式，请阅读域名邮件别名与邮箱的区别。很多迁移错误都从这里开始。

阶段2：Google会限制IMAP，因此应提前迁移数据

如果要进行较大规模的Google Workspace邮件迁移，就必须安排预迁移。Google明确规定了IMAP带宽限制，对每个账户每天可下载和上传的数据量设有上限。无论项目计划多么乐观，大型邮箱都无法在一个周末内完成。

Google公布的Workspace账户Gmail带宽限制为：每天通过IMAP下载2,500 MB，上传500 MB。这是迁移过程中的实际限制，不是建议。如果通过IMAP拉取完整历史记录，一个50 GB的邮箱可能需要数周才能完成。

因此，正确的方式是：

1. 在用户仍使用Google工作时，提前迁移旧邮件。
2. 在切换前几天执行增量同步。
3. 在DNS切换后或最终同步窗口内移动最新邮件。

对于邮件量大的用户，如果工具支持，可按日期范围拆分任务。TrekMail的迁移流程可通过IMAP迁移工作流分阶段导入，因此按批次迁移Google Workspace邮件比盲目拉取全部历史记录更为可行。

示例：如果财务部门的邮箱有36 GB，但立即需要的只有最近90天，可先导入近期文件夹，切换邮件流，再在生产环境稳定后补充归档。

Google目前的登录指南同样需要考虑。旧式基本身份验证在大多数情况下已不可用，受支持配置中的应用专用密码是主要例外。对于以Gmail为源的迁移，当Google政策要求时，TrekMail的现行文档指定使用Gmail应用专用密码，而不是普通账户密码。请参阅Google应用专用密码帮助。

阶段3：只切换一次DNS，并遵循正确顺序

从Google Workspace迁移邮件时，DNS切换决定新邮件的送达位置。提前降低TTL，发布新的身份验证记录，并且只有在目标邮箱和别名已经存在后才修改MX。顺序相反会造成邮件分流。

可靠的流程有意保持简单。切换前两天，将MX、SPF和DMARC的TTL降至300秒。切换前一天，发布目标服务商的DKIM。正式切换时，用TrekMail的MX替换Google MX。然后从公共解析器验证传播情况，不要只相信本机缓存。

; Transitional SPF while some devices still send through Google
v=spf1 include:_spf.google.com include:spf.trekmail.net -all

dig @1.1.1.1 example.com MX +short

在并行运行期间，如果两个系统仍可能发送邮件，应在SPF中同时保留Google和TrekMail。这与RFC 7208一致。注意10次DNS查询上限。如果记录中已经包含太多供应商，应在迁移Google Workspace邮件之前进行扁平化处理。

如果要在多个客户域名上重复执行此流程，TrekMail的优势会在这里显现。旧方法是一边按用户付费，一边逐个域名修改DNS和邮箱设置。新方法是在一个固定价格平台中统一管理多个域名，使用共享存储、DNS向导和内置迁移。

阶段4：修复客户端配置，而不只是更换密码

迁移Google Workspace邮件后，很多支持请求看似是密码错误，实际原因却并非如此。为Google配置过的客户端通常会保留OAuth假设、缓存的自动发现数据或旧服务商预设。用户需要的是指向新主机的全新IMAP配置，而不是反复尝试密码。

移动设备和Outlook受影响最明显。用户在手机上设置账户时常会因为熟悉而点击Google标志，切换后这已经不是正确选项。即使MX已经指向其他位置，Outlook中的旧配置文件也可能继续尝试连接Google。

请直接使用TrekMail的IMAP设置：

Incoming server: imap.trekmail.net
Port: 993
Security: SSL/TLS
Username: full email address
Password: mailbox password

在iPhone和Android上，让用户删除旧Google账户条目，再选择其他或IMAP重新添加邮箱。在Outlook桌面版中，应创建新的邮件配置文件，而不是修复旧配置。TrekMail客户端指南提供了准确的IMAP/SMTP设置。如果需要更手动的迁移流程，也可以结合已发布的imapsync指南。

还有一点需要说明：TrekMail是以标准为先的IMAP托管服务，不提供POP3，也不会伪装成Exchange。如果设备或用户坚持使用Google或Microsoft的专有设置流程，就会把时间浪费在错误的协议上。

阶段5：按数量验证，并保持回退方案简单

要安全迁移Google Workspace邮件，应按文件夹中的消息数量和实时邮件流验证邮箱状态，而不是比较总容量。Google的存储视图包含压缩和非邮件因素，无法与IMAP目标端直接对应。统计消息，确认新的入站和出站邮件，再宣布切换完成。

最低限度的检查清单应包括：

1. 每个关键邮箱的文件夹消息数量足够接近。
2. MX传播后，入站测试消息只送达TrekMail。
3. 出站邮件通过SPF、DKIM和DMARC检查。
4. 别名和共享地址准确送达预期位置。
5. 用户可以使用新设置在桌面和移动设备上登录。

少量数量差异可能很正常。损坏的消息、异常邀请和特殊的空数据项不一定能通过IMAP迁移。但如果认为工作已经完成后，新入站邮件仍进入Google，就不正常。这说明Google Workspace邮件迁移尚未彻底完成。

回退方案应直接而快速。如果入站邮件普遍失败，应在TTL仍较低时把MX重新指向Google。然后导出故障期间落到新主机的所有消息，并在需要时重新注入。无法在五分钟内执行的回退方案不是真正的回退方案。

旧方法与新方法：运维团队为何选择TrekMail

如果经常迁移Google Workspace邮件，实际成本不只是许可证价格，还包括围绕域名、邮箱创建、客户端重置和迁移重试的重复管理工作。TrekMail通过面向运维团队而非按用户表格设计的固定价格多域名模式减少这些工作。

TrekMail提供自定义域名、IMAP邮箱、全域接收、邮箱转发、自带SMTP或按方案提供的SMTP，以及服务器端迁移。Nano方案始终免费，无需银行卡。付费方案包含14-day免费试用，该试用需要信用卡。如果现在管理一个品牌，下个季度要管理二十个客户域名，这种定价模式可能决定业务是保有利润还是陷入混乱。

对于同时管理大量邮箱的团队，其运维优势与多域名邮件托管很相似：一个控制面板、更少的活动环节，而且客户每增加一个收件箱时都不会陷入按用户收费的困境。

如果想迁移Google Workspace邮件，又不希望切换变成周末的紧急救火，请从TrekMail价格开始。先搭建目标端，预先迁移邮件，只切换一次DNS，然后以运维人员的严谨方式完成验证。