迁移企业邮箱，一封邮件都不丢

大多数出问题的邮件迁移，问题并不出在切换那一刻。它们要么早在一周前就埋下了隐患：没人记下 accounts@ 会转发给两个人；要么在一个月后爆发：有人取消了旧订阅，一个归档文件夹也随之消失。

切换本身只是几项 DNS 更改，几分钟就能完成。让它安全的工作都在切换前后。下面是我们帮助企业从一个邮件服务商迁移到另一个时所遵循的顺序，无论原来用的是 Microsoft 365、Google Workspace、网站主机自带的邮箱，还是机房柜里的一台旧服务器。本文写给自己动手迁移的小型企业，也写给想检查服务方工作的企业。

迁移时邮件为什么会丢失

邮件是通过查询您的域名来投递的。当有人发信到 you@yourbusiness.com.au 时，对方的邮件服务器会询问互联网的目录 DNS：这个域名的邮件应该送往哪里。答案就是您的 MX 记录（邮件交换记录）。更改 MX 记录后，新邮件就开始发往新服务商。

有三件事让这件事没有听起来那么简单：

• 服务器会记住旧答案。每条 DNS 记录都带有一个 TTL，即“记住多久”的时间。今天早上查询过您域名的发件方，可能会一直使用旧答案，直到这段时间结束。
• 旧邮件不会自己搬家。更改 MX 记录只会改变新邮件的去向。多年积累的邮件、文件夹、日历和联系人都会原地不动，直到有东西把它们复制过去。
• 其他系统也在以您的名义发信。网站的联系表单、开票软件、办公室扫描仪和电子通讯工具，发出的邮件都声称来自您的域名。如果新的设置没有为它们放行，它们的邮件就会开始进入垃圾邮件或被退回。

下面的每一步都针对其中一个问题。

第 1 步：列出现有的一切

在动手之前，先把现有的一切记录下来。用电子表格就行。这份清单既是您在新服务商那里的规划，也是之后的测试表。

• 邮箱。每一位需要登录的真实用户。包括已离职但其邮件仍需保留的人。离职员工的邮箱最常被遗忘。
• 别名。投递到某人邮箱的附加地址，例如 jane@ 同时接收 j.smith@ 的邮件。
• 共享地址和群组。sales@、accounts@、info@。记下每个地址由谁接收，以及大家是否以该地址回复。
• 转发规则和自动回复。转发到个人邮箱的规则、外出自动回复、把邮件归入文件夹的规则。这些都存在旧系统里，通常不会跟着迁移过来。
• 日历。个人日历、共享日历、会议室或车辆预订，以及代他人管理日程的人。
• 联系人。个人联系人以及任何共享通讯录。
• 邮箱大小。大邮箱复制所需时间更长。知道最大的那个有多大，就知道要提前多久开始。
• 本地归档。只保存在某台电脑上的邮件，存放在 Outlook PST 文件或本地文件夹中。服务器到服务器的复制看不到它们。
• 其他所有以您的域名发信的东西。网站表单、会计和开票软件、CRM、预订系统、电子通讯平台、打印机和扫描仪、报警面板。去问问使用它们的人。

第 2 步：弄清楚谁在管理您的 DNS

不更改 DNS 记录就无法迁移邮件，所以要尽早弄清楚谁能改。对于 .com.au 或 .au 域名，域名是通过认可的注册商注册的，但 DNS 记录可能完全由别处管理：您的网站主机、之前的 IT 服务商，或者多年前给您建网站的人。

在确定日期之前，先登录并确认您能查看和编辑这些记录。记下当前的 MX、SPF 以及任何 DKIM 或 DMARC 记录，并给整个区域截图。万一出了问题，这张截图就是您恢复原状的依据。

如果没人知道登录信息，先把这件事解决。恢复域名的访问权限可能需要好几天，这绝不是您想在切换当晚才发现的事。

第 3 步：提前几天调低 TTL

MX 记录上的 TTL 决定了在您更改之后，互联网的其他部分还会把邮件发往旧服务商多久。许多记录设置为一小时，有些甚至是整整一天。

在切换前几天，把 MX 记录（以及 SPF 和其他您要更改的邮件相关记录）的 TTL 调低到约 300 秒，也就是五分钟。关键在于时机：新的、更短的 TTL 只有在旧 TTL 在各处都过期之后才会生效。如果旧 TTL 是一天，就至少在切换前一天调低。提前两三天是比较宽裕的余量。

迁移稳定后，再把 TTL 调回一小时或更长。

第 4 步：切换前先复制邮件

按照您的清单建立新邮箱、别名和共享地址，然后在旧系统仍在运行时开始把现有邮件复制过去。没人会察觉，因为他们的邮件仍照常送达原来的地方。

复制方式取决于您从哪里迁出：

• 服务商到服务商。大多数迁移使用一种工具，同时登录新旧邮箱，使用所有邮件系统都支持的标准协议（IMAP）逐个文件夹复制。它可以多次运行，每次只复制新增内容，这正是您需要的。
• 从 Microsoft 365 或 Google Workspace 迁出。两者都可以用这种方式复制，但通常需要先更改一项设置，或由管理员操作允许复制工具登录，尤其是在启用了多重身份验证登录的情况下。先用一个邮箱验证，再规划其余的。
• 日历和联系人。它们不是邮件，通常需要单独复制：要么由迁移工具完成，要么导出日历（.ics 文件）和联系人（.vcf 文件），再在另一端导入。
• 本地归档。把它们上传到新邮箱，通常的做法是在连接了新账户的邮件应用中打开归档，然后把文件夹移过去。

对于体量大的内容，请提前几天开始。一个积累了十五年附件的邮箱可能需要很多小时，而且有些服务商会故意限制批量复制的速度。

第 5 步：正式切换

选择一个清闲的时段，并确保第二天早上有人在场。工作日的下午或晚上比较合适。避开月底最后几天、BAS（商业活动报表）申报周，或重要投标截止的前一天。

切换时：

1. 把 MX 记录改为新服务商提供的值，并删除旧记录。保留旧 MX 记录意味着部分邮件会继续发往旧系统。
2. 更新 SPF 记录，允许新服务商发信（下文详述）。
3. 添加新服务商的 DKIM 记录以及他们要求的其他设置记录，例如让手机和 Outlook 自动找到新服务器的记录。删除旧服务商的对应记录，否则 Outlook 可能会一直找到旧账户。
4. 从外部账户（例如个人手机）向每个地址发送测试邮件，确认它们到达新邮箱。再回复这些邮件，检查回复也能送达。

在 TTL 为五分钟的情况下，大多数发件方会在几分钟内跟上变更。少数会坚持得更久。这没关系，因为旧邮箱仍然开着。

第 6 步：切换后再复制一次

切换后的一段时间里，仍会有一些邮件落在旧邮箱：缓存顽固的发件方、已经在队列中的邮件，或者有人用仍设置着旧账户的手机发了信。

第二天再运行一次复制，几天后再运行一次。由于每次只复制新增内容，每一轮都很快，并能把迟到的邮件一并收走。正是这第二轮复制，把“我们觉得都迁过来了”变成了确定都迁过来了。

第 7 步：设置手机和电脑

每部装有旧账户的手机、平板和电脑都需要换成新账户。请提前规划，因为这是员工最能感受到的部分。

• 先添加新账户，再删除旧账户。这样就不会有人一整个下午收不到邮件。
• 然后删除旧账户。一部手机上有两个地址相同的账户，会让人搞不清回复是从哪个账户发出的，还会让旧日历一直显示。
• Windows 上的 Outlook 通常最好新建一个配置文件，而不是修改现有的。旧的缓存设置是 Outlook 一直连接旧服务商的常见原因。
• 检查每部手机上的日历和联系人，而不仅仅是邮件。它们是独立的设置，在某些手机上，新账户默认是关闭这两项的。
• 重新创建签名、规则和外出自动回复。它们很少会随邮件一起迁移过来。

为员工写一页带截图的指南，涵盖 iPhone、Android 和 Outlook。这能在第一天早上省去大量打扰。

第 8 步：旧账户再保留一段时间

不要在切换后的第二天就取消旧服务。至少保留两到四周。在此期间：

• 运行最后一轮复制，
• 在新邮箱中抽查旧邮件、文件夹和附件，
• 确认日历仍能正确显示定期会议，以及
• 确保没有人出于习惯仍在登录旧账户。

这之后再取消。对于大多数云邮件服务，取消即开始删除账户中所有内容的倒计时，事后往往无法恢复。

有一个日历细节值得了解：您在迁移前组织的定期会议，可能会与参会者失去关联。参会者的日历里仍有这个会议，但您从新账户所做的更改可能无法传达给他们。对于重要的定期会议，最简单的做法通常是从新账户重新发送邀请。

确保您的邮件进入收件箱

收到邮件只是工作的一半。另一半是确保您发出的邮件受到信任。大型邮箱服务商，包括 Gmail、Yahoo 和 Outlook.com，现在都要求企业邮件证明它确实来自其声称的域名。有三条 DNS 记录负责这件事。

有几条规则常常让人栽跟头：

• 只能有一条 SPF 记录。一个域名如果有两条 SPF 记录，SPF 会彻底失败。请把新服务商添加到现有记录中，而不是新建第二条。
• SPF 有查询次数限制。SPF 记录中的每个“include”都可能触发更多查询，收件方在十次之后就会停止检查。一条收录了您用过的每一个工具的记录，可能会悄无声息地失效。请清理不再使用的服务。
• 每个发信工具都需要获得放行。这时第 1 步的清单就派上用场了。每个以您的域名发信的系统，要么列入 SPF，要么设置自己的 DKIM，要么改为通过您的新邮箱发送。
• DMARC 要循序渐进。策略为 p=none 的 DMARC 只收集报告。阅读几周报告，修复所有失败的项目，然后收紧为 quarantine（隔离），最终改为 reject（拒收）。在迁移期间直接设为 reject，很容易把您自己的发票挡在门外。

这些都设置好之后，向一个 Gmail 或 Outlook.com 地址发送测试邮件，并查看邮件详情。您希望看到 SPF、DKIM 和 DMARC 全部显示为通过。

我们最常见到的错误

过早取消旧账户。代价最高的错误，因为无法挽回。请等到最后一轮复制完成并检查之后再取消。

遗忘共享地址。accounts@ 和 sales@ 是多年前设置的，没人记得它们的存在，结果在迁移当天就失效了。客户的汇款通知石沉大海。

保留旧的 MX 记录。只要它还在，部分邮件就会继续发往旧系统，有时持续数月而无人察觉。

没有调低 TTL，或调低得太晚。迁移就需要一天而不是几分钟才能稳定，而在这一整天里，邮件分散在两个系统中。

弄坏了网站联系表单。表单原本通过旧服务商以您的域名发信。迁移之后它悄无声息地失效，没人注意到咨询已经停了。

两条 SPF 记录。有人新建了一条记录，而不是修改旧的，结果您发出的每一封邮件都无法通过校验。

遗漏本地归档。把十年客户往来邮件存在笔记本电脑 PST 文件里的那位同事，在换了电脑之后才发现这些邮件从来不在服务器上。

检查清单

这些步骤单独来看都不难。让迁移顺利进行的关键，是按这个顺序完成，并且不跳过开头那些枯燥的步骤。如果您宁愿把整件事交给别人，NGN 现在提供澳大利亚本地托管的企业邮箱，并在开通时为您迁移邮箱、日历和联系人。或者联系我们，我们可以先看看您目前的设置。