如果需要一份电子邮件迁移检查清单，请先遵循这条规则：邮件迁移不是简单拖放文件夹。它是一个实时系统，包含不断变化的消息状态、别名、转发地址、限流、故障客户端，以及在你工作时仍持续发信的用户。草率切换因此很容易失败。如果还在决定迁移后把邮件放在哪里，请先阅读小型企业电子邮件。如果已经确定必须迁移，请使用本操作手册，让过程平稳而可预测。
问题很简单。多数团队复制邮件、更改MX，然后寄希望于运气。到了周一，遗漏项便会出现：创始人的归档、发票转发地址，以及实际上由五个人共用一个账户登录的共享邮箱。本检查清单把发现、预先同步、验证、重试和回退整合到一份运营文档中，从而避免这些问题。
| 方式 | 旧方法 | 新方法 |
|---|---|---|
| 规划 | 在一个周末内复制全部数据 | 审计、预先迁移、切换、验证并锁定源端 |
| 成功指标 | 邮箱容量看起来接近 | 项目数量、失败日志和测试发送结果相符 |
| 故障处理 | 不断重试，直到有人投诉 | 为每种错误规定退避策略、负责人和回退触发条件 |
| 后续处理 | 让旧邮件系统继续运行数日 | 阻止僵尸访问，并快速重建故障客户端 |
复制任何消息前的电子邮件迁移检查清单
电子邮件迁移检查清单从可见性开始。在移动一个字节之前，需要通过程序建立邮箱、别名、转发规则、邮箱大小和源端限制的清单。如果发现工作薄弱，后续每个步骤都会变得更慢、风险更高、成本更大。
不要相信人力资源导出结果，也不要依赖客户上个月发送的电子表格。应从源平台提取数据，并建立能够回答五个问题的清单：
- 存在哪些邮箱，哪些仍在接收邮件？
- 哪些别名和职能账户对应这些邮箱？
- 哪些用户的存储用量明显异常？
- 哪些收件箱、传输层或邮箱级转发规则处于启用状态？
- 哪些账户实际上是共享运营地址，而不是个人邮箱？
最后一点比人们愿意承认的更重要。invoices@、support@和hello@在切换当天之前常常看起来像普通邮箱。到了切换时，却没人知道谁负责这些邮箱、哪台设备仍在登录，以及回复去了哪里。
还应执行一次脏数据检查，查找格式错误的MIME、过大附件和异常的文件夹树。IMAP可以移动大量数据，但无法把损坏的源数据变成干净的目标数据。还要记住，IMAP对某些数据支持不佳，甚至完全不支持。TrekMail的迁移流程只处理邮件，因此日历和联系人需要单独规划。TrekMail的IMAP迁移概述清楚说明了这一范围。
示例：源邮箱中有14,200个项目，其中两条消息已损坏，一份80 MB附件超出目标端策略。如果操作手册只要求容量看起来正常，就会遗漏问题。如果要求检查项目数量和失败项目日志，就能在用户发现之前处理。
切换设计阶段的电子邮件迁移检查清单
在安排周末切换前，检查清单应先确定迁移架构。小邮箱可以承受一次性迁移，真实企业通常无法做到。应预先迁移历史邮件，把近期变化留给最终增量同步，并且只在最慢的邮箱也大致完成后再切换DNS。
常见方式有三种：
| 方式 | 最适合 | 主要风险 |
|---|---|---|
| 一次性迁移 | 邮箱较小的微型团队 | 切换当晚遇到限流或损坏时没有缓冲时间 |
| 预先迁移加增量同步 | 大多数中小企业和MSP迁移 | 需要严格的日志管理和第二轮同步 |
| 混合迁移 | 大型Exchange环境 | 多数小团队并不需要的复杂性 |
对大多数读者而言，预先迁移加增量同步是正确选择。实用的电子邮件迁移时间表如下：
- T-minus 14 days：先迁移旧邮件，并识别速度较慢的邮箱。
- T-minus 7 days：确认别名、转发规则和目标邮箱映射。
- T-minus 2 days：降低DNS TTL，测试身份验证，并审查失败项目日志。
- T-zero：切换MX，更新SPF和DKIM，执行增量同步，然后修复客户端。
- T-plus 1 day：验证数量，测试入站和出站邮件，然后禁用旧访问。
如果DNS设置错误，邮件流就会中断。至少提前48小时降低TTL，然后根据TrekMail的必需DNS记录核对目标记录。
example.com. 300 IN MX 10 mail.trekmail.net.
example.com. 300 IN TXT "v=spf1 include:spf.trekmail.net -all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
# DKIM value is generated per domain in the TrekMail dashboard.MX更改后的前24到48小时内，临时使用p=none DMARC策略可以在缓存稳定期间减少自身造成的拒绝。迁移稳定后，再将策略收紧到强制执行。如果向Gmail发送大量邮件，这一建议尤为重要。Google发件人指南目前要求批量发件人使用SPF、DKIM、对齐、TLS和DMARC。
预先迁移和增量同步检查清单
电子邮件迁移检查清单的中间部分讨论的是客观限制，而不是乐观预期。IMAP逐个文件夹复制消息，大型服务商会施加带宽和限流限制。你的任务是提前移动旧邮件、控制重试，并让最终增量同步足够小，从而在切换窗口内完成。
很多迁移在这里失败。IMAP依赖消息标识符和邮箱状态。RFC中有关UID以及RFC 3501中的UIDVALIDITY行为，解释了为何重新索引或损坏的文件夹可能触发棘手的重新同步。如果迁移工具支持跳过重复项或按内容匹配，应启用这些功能。TrekMail控制面板导入向导包含跳过重复项选项，具体步骤记录在从控制面板开始迁移中。
如果运维人员希望在生产环境操作前用命令行工具测试，建议同时打开这篇imapsync配套指南。
imapsync \
--host1 oldmail.example.com --user1 alice@example.com --password1 'SOURCE_PASS' \
--host2 imap.trekmail.net --user2 alice@example.com --password2 'DEST_PASS' \
--ssl1 --ssl2 \
--syncinternaldates \
--exclude 'Calendar|Contacts' \
--skipsize
承诺在周末完成之前，应先计算带宽。Google公布了Gmail IMAP带宽限制，包括每个账户每天2,500 MB的IMAP下载上限。Microsoft的机制不同，但并不宽松。Microsoft表示迁移性能会变化，并受服务限流影响。正因如此，如果太晚发现，一个超大邮箱就可能破坏整个时间表。
对目标端也应保持现实预期。TrekMail只提供IMAP，不是完整办公套件。这在邮件迁移中反而是优点，因为范围非常清晰：移动邮件、验证邮件，然后单独处理日历和联系人，不把多个故障领域混在一起。
DNS切换后的电子邮件迁移验证清单
完善的检查清单把验证视为独立阶段，而不是快速扫一眼邮箱大小。容量可能误导。编码会变化，各平台处理附件的方式不同，服务器端存储计算也不一致。项目数量、抽查、测试发送和失败项目审查才能说明邮件是否真正完成迁移。
为每类邮箱使用简单的验证矩阵：高管、共享账户、普通用户和超大邮箱用户。
| 检查项目 | 比较内容 | 通过条件 |
|---|---|---|
| 项目数量 | 源端与目标端的文件夹总数 | 完全匹配，或错误日志能够解释差异 |
| 邮件流 | 外部入站、外部出站、内部邮件 | 三者均成功，并到达预期邮箱 |
| 别名 | 每个别名的回复和接收测试 | 无退信，并送达正确邮箱 |
| 转发 | 已知的重要业务转发 | 规则已重建并记录 |
| 客户端访问 | Outlook、Apple Mail、移动客户端 | 新配置文件或重新添加后可用，不残留源端身份验证 |
这份电子邮件迁移清单还应包含僵尸邮箱处理步骤。增量同步完成后，应阻止用户访问旧平台。否则，旧手机或Outlook配置文件仍可能针对源端发送或接收，使这些消息滞留。
TrekMail的客户端设置很直接：IMAP主机为imap.trekmail.net，端口为993，用户名使用完整电子邮件地址。不支持POP3。准确参数可在TrekMail的IMAP和SMTP设置指南中找到。如果Outlook仍执着于旧服务器，应停止修补，直接创建新的配置文件。
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
重试、日志和回退检查清单
电子邮件迁移检查清单的最后三分之一规定计划变红时应采取的措施。在第一个邮箱启动前，就应确定重试规则、日志字段、升级负责人和回退阈值。如果在压力下临时决定，很容易作出错误判断。
日志应记录邮箱、文件夹、时间戳、源服务器、目标服务器、尝试项目数、复制项目数、复制字节数、重试次数、最终状态和易读的错误说明。然后快速划分故障：
| 故障 | 含义 | 运维措施 |
|---|---|---|
| 身份验证失败 | 密码错误、缺少应用专用密码或源端登录被阻止 | 修正凭据，在一个邮箱上重新测试，然后恢复批次 |
| 连接被拒绝 | 端口错误、SSL不匹配、防火墙阻止或源主机问题 | 验证主机和端口993，手动测试后再重试 |
| 限流或429式退避 | 服务商正在限制请求速度 | 降低并发，等待5到10分钟，再缓慢恢复 |
| 大量重复 | 文件夹重新索引或迁移状态发生偏移 | 停止批次，启用重复跳过，只重新运行受影响文件夹 |
| 近期邮件缺失 | 增量同步不完整，或旧客户端仍向源端写入 | 再次执行最终增量同步，并立即禁用源端访问 |
回退并不意味着因为一个用户投诉就把所有内容放回原处。严谨的电子邮件迁移清单应提前定义回退触发条件。合理条件包括MX更改后大范围入站失败、关键邮箱中出现无法解释的大量项目数量差异，或目标端身份验证故障阻止整个租户。不合理条件包括一台配置过期的移动设备，或一名从未更新密码的用户。
如果需要回退，应保持范围最小。先恢复邮件流，只发布一条状态信息，并保留所有日志。不要同时重启三个工具，否则可能制造比原故障更大的混乱。
这份检查清单在TrekMail上为何更容易执行
如果目标平台专注于邮件，而不是套装软件的席位经济，这份检查清单就更容易落实。旧方法是按用户支付一个几乎不用的套件，再把迁移当作附带任务。新方法是迁移到邮件优先的平台，获得可预测的存储、清晰的DNS，以及符合实际工作的IMAP迁移路径。
TrekMail非常适合这一模式。它支持自定义域名、IMAP邮箱、全域接收、邮箱转发、服务器端迁移、SPF/DKIM/DMARC向导、自带或包含的SMTP，以及API。Starter付费方案起价为每月$3.50，内置迁移工具可用于付费方案。如果要测试付费功能，可使用14-day免费试用，但需要信用卡。如果只想在不提供银行卡的情况下开始，Nano方案始终免费。
运营优势在于共享存储和固定价格的多域名管理。一个超大邮箱不会迫使整个公司承担按席位许可证费用。这对代理机构、MSP以及跨多个域名运营职能账户的团队非常重要。如果环境与此相符，请继续阅读TrekMail对多域名电子邮件托管的介绍。有关价格和方案匹配，请直接查看TrekMail价格。
从执行角度看，这也更简洁。添加域名、创建目标邮箱、运行服务器端IMAP迁移、验证DNS，然后切换客户端。无需绕道POP3，也没有不透明的专有连接器，只有参数明确的标准IMAP和SMTP。
结论：让电子邮件迁移检查清单保持平淡
最好的电子邮件迁移检查清单，是一个月后没人会记得的清单。盘点源端、预先迁移旧邮件、有计划地切换DNS、执行增量同步、按数量验证、阻止僵尸访问，并把回退限制在最小范围。这样，迁移就不再是赌博，而会成为普通运营工作，生产邮件本就应该如此。
