两个平台并行运行。
典型的邮件缺口，源于在复制尚未完成时就切换了 MX，或源于复印机、网站或 CRM 仍在使用旧的身份凭据发送邮件。
MX 是一条 DNS 记录：它告诉发件服务器应将您域名的邮件投递到哪里。更换邮件系统，首先就是更改这个投递地址。其余部分（账户、历史数据、设备）都围绕它来准备。
SMTP 协议能够很好地容忍短暂故障。收到临时错误的发件服务器会将邮件保留在队列中，稍后重试。因此，服务器暂时无法连接并不会导致邮件丢失。相反，永久错误（未知邮箱、邮件被拒）会将邮件退回给发件人，而这封邮件不会自行再次送达。切换的主要风险不是故障，而是新平台因某个别名或邮件列表未被重新创建而拒收某个收件人。
TTL（生存时间）规定了 DNS 解析器可以将应答在缓存中保留多长时间。在此期间，一部分发件方仍会向旧平台投递邮件。这很正常，也正因如此，旧平台在过渡期间必须仍能接收邮件。
提前两周。 盘点邮箱、别名、邮件列表、共享邮箱，以及所有发送邮件的应用。将 MX 的 DNS TTL 调低到一个较短的值（通常为 300 秒），以便切换当天能够快速生效。创建目标账户。第一次复制历史数据。
之所以要提早调低 TTL，是因为已读取旧值的解析器会将其保留到过期为止：较短的 TTL 只有在旧缓存失效之后才会生效。第一次复制耗时最长；尽早启动，可以留出时间发现有问题的邮箱。
提前几天。 抽样核查：邮件数量、文件夹或标签、日程、联系人。如果样本核查不通过，则修正方法。准备移动设备和 Outlook 的操作说明。从目标平台向 Gmail 和 Outlook.com 发送测试邮件，此时新平台上的 SPF、DKIM 和 DMARC 应已生效。这些记录可以在更改 MX 之前发布。
具体而言：在过渡期间只保留一条同时授权两个平台的 SPF 记录（两条独立的 SPF 记录会导致验证失败），在新平台自己的选择器下发布其 DKIM 密钥，与旧密钥并列，并重新审阅 DMARC 策略。DMARC 要求邮件以发件人域名的名义通过 SPF 或 DKIM 的身份验证；如果您的策略严格，而目标平台尚未获得授权，您的通信方就会拒收您的邮件。
前一天。 第二轮复制：只复制第一次复制之后到达的内容。冻结别名和邮件列表的变更。
切换当天。 切换 MX。立即进行外部核验：从外部个人邮箱发送的邮件，应在 TTL 时限内送达新平台。监控邮件队列。重新配置发送邮件的应用。确定内部支持热线，并赋予其在关键邮件流失败时将 MX 回退的权限。
如果存在 autodiscover 记录，请同时更改它：Outlook 正是通过查询这条记录来找到其服务器。还要删除仍可能指向旧平台的备用 MX：发件方无法连接主 MX 时，会尝试后续的 MX。
之后几天。 旧平台保持只读。收集反馈的差异（缺失的文件夹、某个共享邮箱）。如有需要，进行有针对性的第三轮复制。然后关闭旧平台的发送功能，使员工不再从两个地方回复邮件。
最后这一点有其技术原因。旧平台始终认为自己负责您的域名：从旧平台发给同事的邮件会在本地投递，而不会查询 MX。这位同事在新邮箱中永远看不到这封邮件。
| 风险 | 会发生什么 | 应对措施 |
|---|---|---|
| 过早切换 MX | 新邮件能够送达，但缺少历史数据 | 在样本核查和第二轮复制之后再切换 |
| 遗漏别名或邮件列表 | 目标平台永久拒收这些邮件 | 盘点、在前一天冻结别名、测试集体地址 |
| SPF、DKIM 或 DMARC 不完整 | 您的邮件被通信方拒收或归入垃圾邮件 | 在切换日之前发布，并用真实邮件核验 |
| 应用仍使用旧账户发送 | 发票、告警或扫描件无法发出 | 列出应用清单，在切换当天配置新的 SMTP 服务器 |
| 旧平台的发送功能仍处于开放状态 | 部分内部邮件滞留在旧系统中 | 样本一经确认，立即关闭发送功能 |
| 未准备回退方案 | MX 已回退，但期间收到的邮件仍留在目标平台上 | 制定书面计划，包括如何取回这些邮件 |
举例来说，一家 40 人的事务所。它选择在周四下班前进行切换，而不是周五：第二天团队在岗，可以处理差异，内部支持热线也还有一个完整的工作日。前台那台扫描到邮件的复印机在当晚完成重新配置。如果有两个共享邮箱反馈缺少某个文件夹，就通过一轮有针对性的复制补齐。在这一情境中，没有任何邮件丢失，但有几名员工需要在手机上重新设置账户：这是必须事先告知的、可被察觉的部分。
他们需要在 Outlook 或移动设备上更换服务器。大型邮箱的首次加载需要时间。如果没有规范地重建配置文件，手机上已缓存的邮件可能会出现重复。请准备“删除账户后重新创建”的操作流程，而不是临时拼凑服务器设置。
Outlook 的道理相同：配置文件会保留与旧服务器关联的本地缓存。新配置文件从干净的状态开始；修改过的旧配置文件则会把两套系统混在一起。在移动设备上，所使用的协议（视目标平台而定，Exchange ActiveSync 或 IMAP）有时会随平台而改变，这又是一个需要重新创建账户的理由。
服务器端规则、集中管理的签名和委派权限需要重新设置。请事先告知。这不是邮件中断。这是管理工作。
这种转发需要明确的设置：仍以为自己托管着这些邮箱的旧平台，必须配置为向新平台中继，而不是在本地投递。如果做不到，一轮有针对性的补充复制也能完成同样的工作。
不同迁出平台各自的特点，分别见从 Microsoft 365 迁移和从 Google Workspace 迁移。
需要的时间，是核实已没有任何邮件流仍在使用旧平台、且反馈的差异均已处理所需的时间。这取决于邮箱数量、发送邮件的应用以及终端重新配置的进度。关闭得太早，就无法纠正问题；关闭得太晚，员工就会在两套系统中工作。
只要准备充分，就不会。在 TTL 有效期内，一部分发件方仍向旧平台投递，另一部分则向新平台投递。两个平台都在接收，而下一轮复制会将两者合并。只有被拒收的邮件才会丢失，因此别名和邮件列表至关重要。
一般不需要：地址并没有改变。但请通知那些对您的邮件进行严格过滤或为您设置了特定规则的合作伙伴，以及在密钥发生变化时与您交换加密邮件的通信方。
可以，方法是恢复旧的 MX，前提是旧平台仍处于活动状态。在此期间新平台收到的邮件，必须重新复制回去，或保持可供查阅。回退计划应写明由谁决定、在多长时间内完成，以及如何取回这些邮件。
请询问运营方它保证的是什么：邮件送达、历史数据迁移，还是两者兼有。这是不同的承诺。还要索取书面的回退计划，并写明有权启动该计划的人员。
关于邮件送达的保证，涵盖的是切换当天及之后几天。关于历史数据的保证，涵盖的是复制及其核查。服务商可能只兑现其中之一；报价应写明它承担的是哪一项，以及如何核验。
在 Klytic，为筹备邮件迁移提供的咨询和建议是免费的，并且不会丢失任何邮件。由 Klytic 执行的迁移按报价确定。订阅价格见价格页面，另行计费。各项成本构成详见Microsoft 365 迁移需要多少成本，核查清单见检查清单。如需比较目标平台，请参阅选择欧洲企业邮箱。
本页描述的是一套方法。实际进程取决于您的邮件流、数据量以及您所迁出的平台。
