邮箱迁移的四个阶段：从盘点到校验

邮箱迁移的成败不取决于用哪个工具，而取决于四个阶段的动作有没有做全、验收标准有没有量化。 这四个阶段是盘点、备份、切换、校验，顺序不能调，任何一环留下缺口，后面的环节都补不回来。

盘点：把账号、邮件数据、域名别名与群组、第三方系统接口四类对象列成清单，逐项确认负责人。漏掉的对象在旧系统关闭后就无处可取。

备份：迁移前做一次全量、独立、可校验的备份。它是整个项目里唯一能踩的刹车。

切换：改 MX 记录把邮件流指向新服务商，同时保持新旧并行。这一步的难点不在技术，在时序。

校验：用可量化的结果证明数据无损，而不是凭感觉抽查几封。

一条贯穿全程的硬约束：原邮箱的 IMAP 服务在搬家完成前不能停止，原邮箱到期后就无法再搬家 [4]。

一、阶段一：盘点，把家底摸清

企业邮箱用上三五年，数据就像塞满杂物的抽屉——大概有什么心里有数，但真到清点的时候，总会漏掉几个角落。盘点阶段的产出物只有一样：一份逐项确认过负责人的清单。

这一步的特殊性在于不可补救。备份没做全可以重做，切换出问题可以回滚，但盘点漏掉的对象一旦在旧系统关闭后才被发现，数据就真的没有了。

1.1 要盘点的四类对象

对象	具体包含什么	漏掉的后果
账号与权限	在职员工账号、邮件组权限，以及离职员工账号	离职账号里的客户往来记录在旧系统关闭后无处可取
邮件数据本身	收件箱、已发送、草稿箱、归档，以及日历与通讯录	日历嵌着会议链接与参会人、通讯录存着外部联系方式，格式不兼容时会丢字段
域名别名与群组	support@example.com 这类公共邮箱，市场部、销售部等群组地址	历史悠久的别名往往绑定在多个外部平台的注册邮箱上，漏迁会导致密码找回与通知邮件断流
第三方系统接口	OA、CRM、ERP 的收发信接口账号	迁移完成后才发现审批流程的邮件通知停了，原因是接口账号没同步

其中日历与通讯录要单独说明：按协议，走 IMAP 的迁移只迁移收件箱或其他邮件文件夹中的项目，不迁移联系人、日历项和任务 [1]。这三类必须单独导出导入，不是把它们写进清单就会自动跟过去。

1.2 盘点清单模板

下面这张表可以直接复制去填。建议固定一个负责人，逐项核对并签字确认。

数据类型	所在位置	预估数据量	负责人	迁移优先级
在职与离职员工账号	管理员后台	待填（个）	IT 管理员	高
收件箱／已发送／草稿箱／归档	各账号内	待填（GB）	各员工	高
日历与通讯录	各账号内	待填（条／人）	各员工	高
域名别名、群组邮箱	管理员后台	待填（个）	IT 管理员	高
第三方系统收发信接口	应用后台	待填（个）	应用负责人	中
客户端本地 PST 文件	各员工电脑	待填（GB）	各员工	中

表里「日历与通讯录」的优先级定为高，而不是中——因为它是协议层面搬不走的那一类，需要单独安排工作量 [1]。

1.3 三个最容易漏的地方

已发送文件夹。 很多人默认只迁移收件箱，但员工在已发送里保存的沟通记录同等重要。实践中已发送的邮件量往往与收件箱相当，有的员工更多，因为发出去就当作已办归档了。

共享邮箱。 比如销售团队共用一个 sales@ 地址，各自在客户端里打开，盘点时容易被当成公共资源而无人认领。共享邮箱的权限结构比个人邮箱复杂，涉及多人读写与自动转发规则，这些配置在新系统里要逐一重建。

客户端本地 PST 文件。 不少员工习惯把旧邮件拖到本地存档，这些数据不在服务器上，不主动去问就永远不会进清单。这类文件还有一个隐患：单个 PST／OST 文件的默认大小上限是 51,200 MB（即 50 GB），可通过注册表项 MaxLargeFileSize 调整 [2]。达到上限后 Outlook 无法继续写入，且不会报「文件损坏」——很多人因此以为存档完好，实际数据已被截断。迁移前最好统一收集并做一次完整性检查。

二、阶段二：备份，迁移前唯一能踩的刹车

不论迁移工具多自动化，一旦数据在传输中出现异常，全量备份是唯一能把一切恢复原状的手段。一个可靠的备份要满足三个条件：全量、独立、可校验。下面三节分别对应这三个条件怎么落地、怎么验。

2.1 导出格式与存放位置

主流邮箱系统支持导出为 EML 或 PST 两类格式。EML 通用性强、适合跨平台；PST 适合 Outlook 体系，但受上面提到的 50 GB 单文件上限约束 [2]。

导出时务必勾选所有文件夹，包括收件箱、已发送、草稿箱、归档以及自定义标签。只勾收件箱是这一步最常见的失误。

存放位置比格式更容易被做错。「独立」这个条件要落到三点上：

不存在源系统里。放进源邮箱的归档文件夹不算备份——迁移动作本身就可能影响到它。

不只存一份。至少一份离线副本，且与在用的办公终端物理分开。

能在没有源系统的情况下读取。这一条要实测：找一台没有配置过原邮箱账号的机器，把备份文件打开一遍。很多备份是到了要用的时候才发现依赖原账号才能解密或索引。

2.2 跨平台迁移的结构差异

不同邮箱系统对「文件夹」的定义不一样，这一点在跨平台迁移时会直接造成结构错乱：

标签体系：一封邮件可以同时打上多个标签，属多对多关系。

文件夹层级：一封邮件只能存在于一个文件夹里，属一对多关系。

从标签体系迁到文件夹体系时，多标签邮件必须选一个落点，其余标签信息会丢失。所以备份阶段要把原始结构记录下来（哪些邮件带多个标签、标签之间的层级关系），否则后续无法判断是迁丢了还是被合并了。

2.3 协议层面搬不走的三类数据

这一条要在备份阶段就单独立项，而不是等切换时才发现：微软官方文档明确，IMAP 类型的迁移只迁移邮件文件夹中的项目，不迁移联系人、日历项和任务 [1]。

对应的动作是给这三类数据各自安排一条独立的导出导入路径，并在盘点清单里单列负责人。

2.4 一次合格备份的三条硬标准

标准	怎么验	对不上时的常见原因
邮件总数与源端一致	源邮箱管理员后台的总数 vs 导出文件中的邮件数	导出范围设错（只导了最近一年）、网络中断导致部分未传完、某些文件夹因权限被跳过
附件完整可打开	从不同年份、不同文件夹随机取至少 10 个文件夹逐一打开	大附件与内嵌图片的 HTML 邮件最容易在传输中损坏，抽检要专门覆盖这两类
日期跨度与源端一致	最早与最晚一封邮件的发送时间是否吻合	导出范围设错的典型症状，且比总数对不上更难察觉

三条同时满足，备份才算通过校验，可以进入切换阶段。任何一条不满足都应当重做导出，而不是记录问题后继续往下走。

三、阶段三：切换，把邮件流指向新服务商

切换的本质是让全世界的邮件收发系统知道，你的域名现在由新服务商接管。核心动作只有一条——修改域名的 MX 记录，让它指向新服务商的邮件服务器。

难点不在这一条命令，在时序：什么时候搬、什么时候切、旧系统什么时候能关。

3.1 顺序与批次：先搬完，再切解析

阿里邮箱官方文档给出的顺序是通过 IMAP 等协议搬家，搬家完成后再切换域名解析；如果先切解析再陆续搬家，必须确保原邮箱的 IMAP 服务不停止，因为原邮箱到期后就无法再搬家 [4]。

这意味着旧系统的可用性本身是迁移的前置条件。旧邮箱的服务到期日必须晚于整个迁移窗口的结束——这一项要在项目启动时就确认，不是切换当天才查。

搬的时候要分批，不要一次全量切。微软官方给出的量级参照是：cutover 迁移方式最多支持 2,000 个邮箱、推荐不超过 150 个，超过推荐值后性能可能下降 [3]。

分批还有一个作用是控制影响范围：某一批出问题时，可以在下一批开始前完成修复和流程调整。批次划分的依据要写进方案——按部门、按数据量、还是按业务重要性，不同划法对应不同的回滚代价。

3.2 切换前的准备

先在新服务商完成全部账号创建与权限配置，确认每个账号都能正常收发内部邮件。这一步本身可能耗时数小时，因为要逐个核对账号、初始密码、邮件组关系与通讯录权限。

同时确认一件容易被跳过的事：如果打算用自有域名做邮箱登录页（例如 mail.example.com），在中国大陆需先对该域名完成网站备案并取得备案号，否则会被限制使用；通过客户端或服务商统一地址访问则不需要备案 [7]。备案有周期，临到切换才办会直接卡住整个窗口。

3.3 MX 记录怎么改

这几处是厂商官方文档明确点出、也是最容易配错的地方：

配置项	官方口径
主机记录	填 @ 时邮箱地址为 xxx@example.com；填 mail 会变成 xxx@mail.example.com [5]
线路类型	必须选「默认」，否则会导致部分用户无法解析、邮件收不到；MX 一般不需要做智能解析 [5]
记录值	若填的是域名，该域名必须存在 A 记录 [5]
优先级	数值越低优先级越高 [5]
TTL	缓存时间，数值越小修改后各地生效越快，腾讯云解析默认为 600 秒 [5]

切换前提前降低 TTL，目的是缩短全球 DNS 缓存的刷新时间。至于窗口期该留多长，没有厂商给出统一承诺——它取决于 TTL 设置与各地缓存状态，规划时要留余量。

顺带确认鉴权配置：SPF 记录只能有一条，多个发信来源必须合并到同一条、用多个 include: 串联；官方还专门提醒 ip4 不要写成 ipv4 [6]。新旧系统并行期间发信出口变了，SPF 要同时覆盖两端，否则并行期内会出现大批邮件进垃圾箱。

3.4 切换当日的时间线

用相对时序表示，T 为修改 MX 记录的时刻。具体钟点按各企业低峰时段自定，通常选在周五晚间或周末：

时点	动作
T-3h	完成最后一次全量备份，通知员工关闭邮件客户端
T-2h	在新服务商侧完成全部账号创建，内部互发测试通过
T	修改 MX 记录，TTL 已提前调低
T+1h	在不同网络环境（办公网、家宽、移动网络）下用测试账号验证收发
次日	检查并行期内的邮件流向，确认无遗漏

3.5 客户端重配置最容易被漏

员工电脑上的 Outlook、手机自带邮件 App 都需要重新配置收件（IMAP）与发件（SMTP）服务器参数，端口和加密方式也要按新服务商要求调整。

有一个症状值得预先知道：不同客户端对 IMAP 路径前缀的处理方式不同，配置不当会出现邮件已经在服务器上、客户端却显示空文件夹。遇到这种情况先查路径前缀设置，不要急着判断是迁移丢数据。

可行的做法是切换前一周下发图文配置指南，覆盖 Outlook 与主流手机客户端，并在切换当晚安排技术人员实时支持。

3.6 并行期与回滚预案

新 MX 记录生效后不要立刻关停旧服务，让两套系统同时在线进入并行观察期。

并行期该留多长，应当按业务周期定，而不是按固定天数定。 判据是让并行期覆盖一个完整的业务收发周期——如果企业有月结、对账、周期性客户往来，并行期至少要覆盖其中一轮，否则那类邮件的收发路径根本没被验证过。

回滚预案要提前写好，内容包括三项：

触发条件：用可量化的指标事先约定（例如收发失败的用户比例、邮件延迟的持续时长），并写明由谁判定。不量化就会在真出问题时陷入犹豫。

回滚动作：把 MX 记录改回原值，邮件流重新切回旧服务。

旧环境保留期：与并行期一致，期间旧环境不得关闭。

回滚窗口的意义在于把「万一」变成「可控」。

四、阶段四：校验，用可量化的结果收尾

迁移的终点不是 MX 记录切换完成，而是确认每一封邮件、每一个权限、每一个文件夹都准确落在新系统里。这一阶段的目标只有一个：用可量化的结果证明数据无损且业务可用，而不是凭感觉抽查几封。

4.1 四步校验法

步骤	做什么	通过标准
一、账号与权限对账	逐一确认在职、离职、别名、群组邮箱及第三方接口账号均已创建	账号数与盘点清单一致，权限与旧系统一致
二、比对邮件数量	先核对全库总数，再逐个文件夹核对条数	全库总数完全吻合；逐文件夹的差异须能用结构差异解释（见 4.2）
三、抽样收发测试	覆盖大附件、带内嵌图片的 HTML 邮件、跨域邮件	三类均能正常收发，无退信
四、全文检索抽查	用关键词、时间范围、发件人组合条件搜索历史邮件	能检索到预期结果，说明索引已建立完成

第四步容易被跳过，但它测的是别的步骤测不到的东西：邮件搬过去了不等于索引建好了，索引没建完时用户会以为邮件丢了。

4.2 比对条数时的一个陷阱

第二步之所以要先比全库总数再比文件夹，是因为有一种情况会让人误判：逐文件夹的条数对不上，但数据其实没丢。

原因就是 2.2 节说的结构差异。从标签体系迁到文件夹体系时，一封带三个标签的邮件在源端会在三个视图里各出现一次，迁到文件夹体系后只有一份实体。逐文件夹比对时，那三个文件夹的条数都会少，总数却是对的。

所以比对要分两层做：

先比全库总数。这一层不受结构差异影响，是判断有没有真丢的唯一可靠依据。

再比逐个文件夹。这一层出现差异时，先对照备份阶段记录的原始标签结构，确认是不是多标签邮件造成的归并，再判断是否真的缺失。

这也是为什么备份阶段要把原始结构记录下来——没有那份记录，校验阶段就无法区分「归并」和「丢失」，只能靠猜。

4.3 量化验收指标

抽检比例：随机抽检的邮箱数不低于总邮箱数的 5%。

文件夹层级错误率：必须为 0。

邮件丢失率：必须为 0，按全库总数核算。

后两项是零容忍指标——不存在「丢了千分之一可以接受」的说法，因为丢掉的那一封很可能正是关键往来。抽检比例可以按企业规模上调，但不应低于 5%。

这里要把两件事分开：层级错误指的是父子结构被搞乱（本该在「客户／华东」下的邮件跑到了「客户」根目录），它必须为 0；而 4.2 说的标签归并造成的逐文件夹条数变化，只要全库总数吻合、且能对上备份阶段记录的原始结构，就不计入错误。混淆这两者会让验收在本来正常的情况下卡住。

4.4 发现差异怎么办

第一时间记录差异类型：是条数不符、附件缺失、还是权限错配。三类的处理路径不同：

条数不符：在并行期内从旧系统重新导出该文件夹并补充同步。

附件缺失：检查是否触及单封邮件大小上限，新旧系统的容量与附件上限要在迁移前就对比确认。

权限错配：属配置问题而非数据问题，在新系统后台重建即可，但要连带检查自动转发规则。

如果差异涉及文件夹结构，要回查迁移工具的映射规则，修正后重新同步。务必在关闭旧服务前确认所有差异归零——旧环境是纠正任何偏差的最后依靠。

另外，阿里邮箱的账号回收站默认保存 30 天内已删除的邮箱账号 [4]。这是运维容错窗口，可以在误删账号时救急，但它不能替代并行期与旧环境保留期，两者解决的是不同问题。

五、四个阶段的验收动作一览

这张表可以直接当作项目的阶段闸门：上一阶段的验收动作没做完，不进入下一阶段。

阶段	核心动作	验收标准	依据
盘点	四类对象列清单，逐项确认负责人	清单已签字确认；联系人／日历／任务已单列	[1]
备份	全量、独立、可校验的导出	总数一致、附件可打开、日期跨度一致，三条全满足	[2]
切换	先搬完再切解析，改 MX 并保持并行	内部互发通过；多网络环境验证通过；回滚预案含量化触发条件	[4] [5]
校验	四步校验法	抽检 ≥5%；层级错误率 0；丢失率 0；差异全部归零后才关旧服务	[4]

贯穿全程的一项前置条件：原邮箱的 IMAP 服务在搬家完成前不能停止 [4]。方案里不提这一条的，要追问原因。

六、常见问题（FAQ）

Q: 通讯录和日历会跟邮件一起迁过去吗？

不会自动跟过去。微软官方文档明确，IMAP 类型的迁移只迁移收件箱或其他邮件文件夹中的项目，不迁移联系人、日历项和任务 [1]。这三类必须单独导出导入，属于要在盘点阶段就单列负责人和工作量的部分。把它们写进迁移清单不等于工具会处理它们。

Q: 迁移期间，员工还能正常收发邮件吗？

可以。做法是设置并行期，新旧两套系统同时在线，员工在任一端操作都不会遗漏消息。并行期该留多长应按业务周期定，让它覆盖一个完整的收发周期（比如包含一次月结或对账），而不是按固定天数拍一个值。期间 DNS 解析逐步生效，邮件流向自然切换，确认功能全部正常后再关闭旧服务。

Q: 整个迁移大概要多久？

没有通用的天数，因为它由四件事决定，而这四件事各家差异很大：账号数量与分批规模（微软对 cutover 方式给出的量级参照是最多 2,000 个邮箱、推荐不超过 150 个 [3]）、历史数据总量、并行期需要覆盖的业务周期长度、以及是否要办 ICP 备案（若打算用自有域名做邮箱登录页，备案有独立周期 [7]）。

规划顺序建议倒过来做：先确定并行期要覆盖哪一轮业务周期，再往前倒推整个窗口，而不是先定一个天数再往里塞动作。先定天数的项目，最后被压缩的通常是校验环节。

Q: 我们数据量很大，用 PST 导出再导入行不行？

有明确的容量天花板。微软官方文档写明，Outlook 的 PST／OST 文件默认大小上限为 51,200 MB（即 50 GB），可通过注册表项 MaxLargeFileSize 调整 [2]。达到上限后 Outlook 无法继续写入，且不会报「文件损坏」——很多人因此以为备份完成，实际数据已被截断。大邮箱搬迁不宜依赖 PST 路径。

Q: 迁移要分几批？一次全切行不行？

建议分批。微软官方对 cutover 迁移方式给出的量级参照是最多支持 2,000 个邮箱、推荐不超过 150 个，超过推荐值后性能可能下降 [3]。分批还有一个作用是控制影响范围：某一批出问题时，可以在下一批开始前完成修复和流程调整。

Q: 历史邮件导入后，会不会出现乱码或附件损坏？

规范导出格式加导入后抽样验证可以有效规避。导出时使用标准格式并勾选所有文件夹，能最大限度保留原始编码与附件完整性。导入完成后随机抽取不低于 5% 的邮箱，逐封检查附件能否打开、正文是否乱码；大附件和带内嵌图片的 HTML 邮件要专门覆盖，这两类在传输中最容易损坏。

Q: 盘点时最容易漏掉哪些数据？

三类：已发送文件夹（邮件量常与收件箱相当，却因为「只迁收件箱」的惯性被跳过）、共享邮箱（多人共用、无人认领，且权限结构比个人邮箱复杂）、客户端本地 PST 文件（不在服务器上，不主动问就不会进清单）。另外离职员工账号也是高频漏项，它在旧系统关闭后就无处可取。

Q: 共享邮箱（比如 sales@）该怎么迁？

共享邮箱要单独立项，因为它的复杂点不在邮件本体而在权限。三件事要单独处理：一是明确认领人，否则盘点时它会被当成公共资源而无人负责；二是把权限矩阵与自动转发规则记录下来，这些配置不会随邮件一起过去，要在新系统逐条重建；三是清点它作为对外身份的使用范围——如果它被用作某些外部平台的注册邮箱或对外公布的联系地址，这部分要一并纳入清单。

Q: 迁移完成后，原服务商上的邮件还能找到吗？

在并行期与旧环境保留期内可以随时登录核对，这也是发现差异后唯一的补救通道，所以差异未归零之前不要关闭旧服务。另有一层容错：阿里邮箱的账号回收站默认保存 30 天内已删除的邮箱账号 [4]——但它针对的是误删账号，与「旧环境保留」不是一回事，不能互相替代。

Q: 海外往来的邮件，在切换期会不会丢失？

规范做法下不会丢，但可能有短暂延迟。原因是 MX 记录变更要等各地 DNS 缓存刷新，而窗口长短没有厂商给出统一承诺，它取决于 TTL 设置与各地缓存状态 [5]。延迟期间发往旧服务器的邮件仍会被正常接收，所以并行期内必须保持双侧可收——这正是不立刻关停旧服务的原因。