只要操作得当，从 Google Workspace 迁移到其他邮箱托管服务，整个过程大约需要一周，实际动手时间仅为 3-4 小时。关键在于并行收信：先在 Workspace 仍能接收邮件时配置新服务，再运行 IMAP 迁移工具，在后台复制历史邮件，最后在 DNS TTL 较低时切换 MX 记录。这样，正式切换只需几分钟，而不是几个小时。
多数关于从 Google Workspace 迁出的指南都采用直接切换方式，因此在 DNS 传播期间容易漏收邮件。根据收件量，这种方式通常会丢失 10-50 封邮件。下面的六步方案可以做到零丢失。整个准备过程只多花 30 分钟，却能避免刚切换完就到处追问“客户的那封邮件去哪了”。
本文通过具体的 DNS 记录示例，逐步说明完整的六步迁移流程。如需了解更全面的背景，请参阅从 Google Workspace 迁移邮件。
为什么从 Google Workspace 迁出并没有想象中困难
从 Google Workspace 迁出看起来很复杂，是因为 Workspace 将邮件、日历、Drive 和 Meet 都绑定在同一个身份体系下。真正令人顾虑的是这套捆绑服务。单看邮件，其实只有 IMAP 和 DNS 记录，可以顺利迁移到任何支持 IMAP 的服务商。
实际迁移工作可以清晰拆分。邮件：按下方六步流程操作，需要 1-2 天。日历：从 Workspace 日历导出，再导入新的日历服务，例如 Fastmail Calendar、Apple Calendar 或自建 CalDAV。Drive：以类似 rsync 的方式将文件复制到新的存储服务。Meet：注册 Zoom 或同类服务作为替代。各部分可以分别迁移，因此整个项目远没有“从 Google Workspace 迁出”听起来那么棘手。
六步迁移流程概览
按照六个步骤操作，即可在切换期间从 Google Workspace 迁出邮件，同时避免漏收来信。执行顺序非常重要：每一步的结果都是下一步的前提。遗漏其中任何一步，都可能在 DNS 传播过程中留下断点，导致正在传输的邮件丢失。
- 提前 48 小时降低 DNS TTL。这样可在正式切换时，将 MX 记录的传播时间从数小时缩短到几分钟。
- 配置新的邮箱托管服务。在新服务中添加域名，并创建对应的邮箱。
- 在后台运行 IMAP 迁移。让 Workspace 继续收信，同时将历史邮件复制到新服务。
- 切换 MX 记录。将 DNS 指向新的邮箱托管服务，传播期间由两个服务并行接收邮件。
- 验证并进行双向收发测试。确认发往三家不同服务商的邮件均通过身份验证。
- 停用 Workspace。切换 MX 后等待 48-72 小时，再停用 Workspace 邮箱。
整个流程按日历计算大约需要一周，实际操作时间分散在一周内，共计 3-4 小时。严格遵循这六个步骤，可以避免临时拼凑的 Google Workspace 迁移方案经常造成的邮件丢失。
第 1 步：提前 48 小时降低 DNS TTL
从 Google Workspace 迁出的第一步，是在计划切换前 48 小时降低 MX 记录的 DNS TTL。Workspace 的 MX 记录默认 TTL 通常为 3600，也就是一小时。将其降至 300，即五分钟，就能让第 4 步中的 MX 切换迅速传播。
; before - default TTL
yourcompany.com. 3600 IN MX 1 aspmx.l.google.com.
; after - low TTL for cutover window
yourcompany.com. 300 IN MX 1 aspmx.l.google.com.
在 DNS 托管服务中修改每条 MX 记录的 TTL。随着缓存到期，新设置会在接下来的 1-2 小时内逐步生效。等待 48 小时，确保较低的 TTL 已传播至全球。第 6 步完成迁移后，再将 TTL 恢复到 3600，以便正常运行。
第 2 步：配置新的邮箱托管服务
从 Google Workspace 迁出的第二步，是配置新的邮箱托管服务。注册 TrekMail 或你选择的其他服务，在控制面板中添加域名，通过验证用的 TXT 记录确认域名所有权。按照 Workspace 中的名称创建对应邮箱，例如 sarah.smith@、mike.davis@ 等。生成 SPF、DKIM 和 DMARC 的值，但先不要发布，这些记录将在第 4 步启用。
此时，新服务中的邮箱已经准备就绪，但 MX 仍指向 Workspace，因此新邮箱暂时不会收到真实邮件。这项准备工作可以确保第 4 步的并行收信切换顺利完成。有关替代服务商的整体选择思路，请参阅Google Workspace 替代方案。
第 3 步：在后台运行 IMAP 迁移
从 Google Workspace 迁出的第三步，是在后台运行 IMAP 迁移。TrekMail 提供服务器端 IMAP 迁移工具。为每个邮箱提供 Workspace IMAP 凭据后，工具会逐个文件夹复制邮件。整个过程持续数小时，同时 Workspace 仍能并行接收新邮件。
对于常见的邮箱容量，大多数迁移可在 24 小时内完成，通常每位用户的邮箱为 1-10GB。容量达到 50GB 以上的大型邮箱则需要更长时间。请在正式切换前运行迁移，确保第 4 步开始之前，所有历史邮件都已进入新服务。可以在控制面板中监控进度；如果某个邮箱存在需要处理的 IMAP 问题，工具会单独显示相应错误。
第 4 步：切换 MX 记录
从 Google Workspace 迁出的第四步，是更新 MX 记录，使其指向新服务。发布新的 MX 值，以及第 2 步生成的 SPF、DKIM 和 DMARC 记录。DNS 传播大约只需 5 分钟，因为第 1 步已降低 TTL。
; new MX pointing at TrekMail
yourcompany.com. 300 IN MX 10 mx1.trekmail.net.
yourcompany.com. 300 IN MX 20 mx2.trekmail.net.
; authentication records
yourcompany.com. 300 IN TXT "v=spf1 include:_spf.trekmail.net ~all"
trekmail._domainkey.yourcompany.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."
_dmarc.yourcompany.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com"
在传播窗口内，一些发件服务器仍会将邮件送至 Workspace，另一些则会使用新服务。两个服务并行收信，不会出现退信。切换 MX 后，至少将 Workspace 邮箱继续保持启用且可访问 48-72 小时，以便接收 DNS 缓存时间较长的服务器仍发往旧地址的在途邮件。
第 5 步：验证并进行双向收发测试
从 Google Workspace 迁出的第五步，是验证新服务外发邮件的身份认证。使用每个邮箱分别向 Gmail、Outlook.com 和 Yahoo 账户发送测试邮件。检查邮件头，确认三处的 SPF=PASS、DKIM=PASS 和 DMARC=PASS。只要出现任何 FAIL，就说明第 4 步发布的记录需要调整，解决后才能正式投入使用。
还要验证收件：从外部地址向一个新邮箱发送测试邮件，确认它在几分钟内抵达新服务。如果邮件仍进入 Workspace，说明 DNS 尚未完成传播。再等待 10-15 分钟，然后重新测试。验证是不可省略的环节，否则投递问题不会在切换时被发现，而会在业务全面运行后集中暴露。
第 6 步：停用 Workspace
从 Google Workspace 迁出的第六步，是在 MX 切换后的 48-72 小时停用 Workspace 邮箱。此时 DNS 已在全球完成传播。通过管理控制台停用邮箱，并在当前结算周期结束时取消订阅。将 DNS TTL 恢复到 3600。
最终取消前，请保留一份 Workspace 数据导出文件，包括邮件、日历和 Drive，以备日后查阅历史数据。可以使用 Google Takeout 完成导出，并在订阅终止前下载到本地存储。这样就能保留一份独立于新服务的 Workspace 历史状态备份。有关结构化操作清单，请参阅邮件迁移检查清单。
后续步骤
采用六步方案从 Google Workspace 迁移邮件，整个过程按日历计算大约需要一周，实际操作时间为 3-4 小时。只要正确配置并行收信，就能做到邮件零丢失。DNS 传播期间，新服务负责接收在途邮件，而 Workspace 则继续处理仍发往旧 MX 的少量邮件。
前往 trekmail.net/pricing 免费试用 TrekMail Nano，无需银行卡。Starter 套餐价格为 $4/month，包含从 Google Workspace 迁出时第 3 步所需的服务器端 IMAP 迁移工具。对于主要使用邮件、多数成员并不每天依赖 Docs 和 Sheets 的团队，$42/year 的固定价格通常可以将 Workspace 账单削减 90% 以上。有关 IMAP 迁移的完整说明，请参阅IMAP 迁移。
来看一个具体案例：赫尔辛基一家拥有 24 名员工的 SaaS 公司，在使用 Google Workspace 多年后决定迁出。迁移前，该公司每年为 Workspace Business Starter 支付 $1,728/year。整个迁移按日历计算用了 5 天，其中包括低 TTL 等待窗口、并行收信切换，以及通过 IMAP 迁出共计 180GB 的历史邮件，涉及 24 个邮箱。迁移后，同样的业务只需使用 $96/year 的 TrekMail Pro。每年可节省 $1,632，足以支付团队的 Notion 订阅，剩余资金还可用于当年的其他运营支出。
另一个案例是特拉维夫一家拥有 40 名员工的中型企业，他们准备从 Google Workspace Business Standard 迁出。迁移前，每年费用为 $5,520/year。内部审查发现，真正频繁使用 Docs 和 Sheets 的只有 8 个席位，主要是管理层和财务人员。迁移方案是：40 个邮箱使用 TrekMail Pro，费用为 $96/year；为重度文档用户保留 8 个 Workspace Business Starter 席位，费用为 $576/year。迁移后总支出为 $672/year，每年节省 $4,848。
两个案例都表明，从 Google Workspace 迁出并不一定要在全部保留与全部放弃之间二选一。团队可以先了解哪些席位真正需要办公套件，再采用拆分方案：多数成员迁到固定价格、仅提供邮件的服务，重度文档用户则继续留在 Workspace。这样通常可将 Workspace 费用降低 70-90%，同时为真正依赖办公套件的用户保留所需功能。
