企业邮箱上线自查清单：配置、安全、备份一次过

上线不是「记录加完了」，而是「每一项都验过了」。 这份清单不教你怎么填记录——那属于配置环节；它给的是配完之后逐条核对的方法和判定标准。

一、先过两个前置确认

这两项排在最前面，是因为它们不通过时，后面的记录加了也不会生效——而且现象是「每一条记录看着都对，就是收不到信」，最容易白花几个小时。

1.1 域名是否已完成实名认证

按工信部 2017 年全面域名实名认证的要求，所有存量域名与新注册域名均需完成实名认证；未通过实名审核的域名，注册局会暂停解析（域名状态置为 serverHold），域名无法正常访问 [4]。

怎么查	判定标准
域名注册商控制台看域名状态；或用 WHOIS 查询工具 [4]	状态不是「未实名认证」，也不处于 serverHold / clientHold

如果已经实名但状态仍显示 serverHold，通常是状态同步延迟，约 1 个工作日后重新查询即可 [4]。

1.2 域名是否在有效期内

这一条容易被完全忽略：如果域名是在阿里云（万网）购买的，域名过期未及时续费也会影响邮箱使用 [3]。邮箱本身的到期规则同样要留意——阿里邮箱到期 30 天内可以正常续费，超出后业务将做删除处理、数据无法找回 [3]。

上线前把域名与邮箱两个到期日都记下来，比事后补救便宜得多。

二、配置检查：五项逐条验收

这一节只给核对方法。具体记录值以你所用邮箱服务商的官方文档为准——不同服务商的服务器地址不同，照抄别家的值会直接导致配置失效。

2.1 MX 记录能否查到，且与服务商文档一致

怎么查	判定标准
nslookup -type=mx 你的域名（Windows）或 dig mx 你的域名 +short（Mac／Linux）[1]	返回的服务器地址与服务商文档给的完全一致；条数不少于文档要求

两个细节值得单独核一遍：

优先级的数值本身不需要纠结：它只决定尝试顺序，数值越小越优先 [5]，照服务商文档给的那一组填即可。

2.2 所有权验证的 TXT 记录是否已通过

邮箱服务商通常要求加一条 TXT 记录来验证域名归属。

怎么查	判定标准
nslookup -type=txt 你的域名 或 dig txt 你的域名 +short [1]	能查到服务商给的验证字符串；且邮箱管理后台的域名状态显示已验证

后台状态与 DNS 查询结果要两边都对上。只有 DNS 能查到、后台还没变成已验证，说明服务商侧还没完成校验，此时不要往下走。

2.3 客户端能否真的连上

这一项要实际操作，不能只看配置。用一台电脑或手机，按服务商文档给的服务器地址与端口配一个客户端，收发各试一次。

怎么查	判定标准
用服务商文档提供的 IMAP／POP／SMTP 地址与端口配置客户端	收信、发信各成功一次；不要只测其中一个方向

这里有个常见的误解要说清：客户端填的是服务商的服务器地址，不需要你在自己域名下另配别名。 阿里邮箱的 IMAP／POP／SMTP 服务地址在官方文档里有完整列表，直接填即可 [8]。

2.4 原域名的旧邮箱解析记录是否已清理

这一项在自检清单里最容易被漏掉，而它是官方明确要求的动作：如果用于开通邮箱的域名之前在使用其他品牌的邮箱，需要先删除或暂停原邮箱的解析记录，再添加新的解析记录 [2]。

怎么查	判定标准
在解析控制台通览全部记录，找出指向旧邮箱服务商的 MX 与 TXT	旧的 MX 已删除或暂停；旧的 SPF 已合并或清理（SPF 的处理见 3.1）

新旧 MX 并存时，邮件可能被投递到旧服务器——而旧邮箱可能已经不再有人查看。

2.5 生效时间怎么判断

不要按「多少小时」来等，按 TTL 来判断。

DNS 变更的等待时间由各级 DNS 服务器的缓存决定，这个时长由 TTL 值控制，**数值越小改动后各地生效越快。各家运营商递归 DNS 的实际刷新节奏并不统一，也没有厂商就此给出承诺，所以上线时间表要给这一段留余量，而不是按某个固定小时数倒排。

怎么查	判定标准
先用命令行确认记录已能查到，再发测试邮件	命令行能返回正确值 = DNS 已生效；此时若仍收不到，问题不在解析

顺序不能反：先确认解析生效，再排查投递问题。反过来做会把两类问题混在一起。

三、安全检查：三项逐条验收

3.1 SPF：只能有一条

这是三项里最容易配错、后果也最直接的一项。

一个域名只能有一条 SPF 记录。 有多个发信来源时必须合并进同一条、用多个 include: 串联，而不是新增第二条 TXT [1]。协议层面对此有明确后果：查询到多条 SPF 记录时，结果是永久错误（permerror），整条 SPF 视为验证失败 [6]。

怎么查	判定标准
dig txt 你的域名 +short，数一数以 v=spf1 开头的记录有几条	有且只有一条；结尾策略与服务商文档一致

两个官方专门提醒过的细节：ip4 不要误写成 ipv4；include 引入的 IP 段范围不宜开得过大，否则存在被仿冒发信的风险 [1]。

还有一条上限值得知道：单次 SPF 验证过程中触发 DNS 查询的机制与修饰符总数不得超过 10 个，超出同样返回 permerror [6]。这一条容易被误读成「记录里写了几段就算几个」，实际上只有下面这几种计入：

是否计入	机制／修饰符
计入	include、a、mx、ptr、exists，以及 redirect 修饰符 [6]
不计入	ip4、ip6、all [6]

关键在于这份额度由整条链路共用：include 引入的那条记录里如果还有 include 或 a，它们也一起占用同一份额度 [6]。所以直接写 IP 段不消耗额度，而每接一个第三方发信平台就至少占掉一个、且它自己内部还可能再套几层——这是「记录看着不长却触顶」的常见成因。核对时用公开的 SPF 查询工具看展开后的实际计数，比数记录里的段数可靠。

3.2 DKIM：公钥能查到，且选择器一致

怎么查	判定标准
dig txt 你的选择器._domainkey.你的域名 +short [1]	能查到公钥；选择器名称与邮箱后台显示的完全一致

阿里邮箱官方文档给出了签名无效时的三个检查点，正好可以当作核对项 [1]：

第三条最容易漏：改过密钥长度却没回配置界面确认，签名不会生效，而邮件照样能发出去。

3.3 DMARC：报告接收地址不能空着

DMARC 建立在前两项之上，它要求 SPF 与 DKIM 至少一项通过且与用户看到的 From 域对齐，并声明验证失败时收件方该怎么处理 [6]。

怎么查	判定标准
dig txt _dmarc.你的域名 +short	能查到记录；rua 有一个可正常收件的邮箱地址

上线阶段建议从仅监控那一档起步，先靠报告确认所有合法发信源都通过了验证，再考虑收紧策略。rua 不填就等于白配观察期——没有报告，就无从判断能不能往上提。

阿里邮箱官方文档给出的 DMARC 示例值里同时包含 rua 与 ruf 两类报告接收地址，并建议使用同域邮箱接收 [1]。

四、备份检查：三项逐条验收

配置和安全都过了，邮箱能正常收发。上线的最后一步是确认数据不会丢——这一节最常被跳过。

4.1 协议搬不走的三类数据，是否单独安排了路径

这是备份检查里最实质的一项，因为它不是「有没有做备份」的问题，而是「以为做了、其实没做」。

微软官方文档明确：IMAP 类型的迁移只迁移邮件文件夹中的项目，不迁移联系人、日历项和任务 [7]。

怎么查	判定标准
在新邮箱里打开通讯录、日历、任务，各看一眼	三处都有内容；且分组／权限／重复规则与旧系统对得上

邮件搬完了、通讯录是空的——这不是工具故障，是协议本来就不搬它。这三类数据需要各自一条独立的导出导入路径。

4.2 本地留底的容量上限

把邮件导出到本地留一份是最后一道防线，但导出文件本身有容量天花板：微软官方文档说明 PST／OST 文件的默认大小上限为 50GB，可通过注册表项调整 [9]。

怎么查	判定标准
对比邮箱实际占用与单个导出文件的大小	单个文件未接近上限；超过量级的按时间或部门分卷

导出完成后打开抽查几封带附件的邮件，确认附件能正常打开——文件大小对得上不等于内容完整。

4.3 原邮箱的访问权限留到什么时候

切换之后不要急着停掉原邮箱。

阿里邮箱官方文档提醒过两点直接相关的：搬家应当先搬完再切换域名解析；如果先切解析、再陆续搬家，必须确保原邮箱的 IMAP 服务不停止，而原邮箱一旦到期就无法再搬 [2]。

怎么查	判定标准
确认原邮箱的服务到期日与 IMAP 开关状态	到期日在切换后仍留有余量；IMAP 保持开启直到验收完成

五、一张总验收表

上线前把这 13 项过一遍。表里每一行对应前面的一个小节，每一项都有明确的判定标准，不需要凭感觉。

#	类别	检查项	怎么查	判定通过的标准
1	前置	域名实名认证（1.1）	注册商控制台或 WHOIS [4]	未处于 serverHold / clientHold
2	前置	域名与邮箱有效期（1.2）	控制台查两个到期日 [3]	切换后仍有余量
3	配置	MX 记录（2.1）	dig mx 你的域名 +short [1]	与服务商文档一致；主机记录为 @、线路为默认 [5]
4	配置	所有权 TXT（2.2）	dig txt 你的域名 +short [1]	DNS 可查到，且后台状态为已验证
5	配置	客户端连通性（2.3）	按服务商地址配一个客户端 [8]	收、发各成功一次
6	配置	旧邮箱解析已清理（2.4）	通览解析记录	旧 MX 已删除或暂停 [2]
7	配置	解析是否已生效（2.5）	先用命令行确认，再发测试邮件	命令行能返回正确值；等待时长按 TTL 判断 [5]
8	安全	SPF（3.1）	dig txt 你的域名 +short	有且只有一条；展开后触发 DNS 查询的机制不超过 10 个 [1][6]
9	安全	DKIM（3.2）	dig txt 选择器._domainkey.你的域名	公钥可查、无截断、选择器与后台一致 [1]
10	安全	DMARC（3.3）	dig txt _dmarc.你的域名	记录可查；rua 邮箱能正常收件 [6]
11	备份	协议搬不走的三类数据（4.1）	打开通讯录／日历／任务各看一眼	三处都有内容 [7]；分组／权限／重复规则对得上
12	备份	本地留底（4.2）	核对邮箱占用与单个导出文件大小	单个 PST 未接近 50GB [9]；抽查附件能打开
13	备份	原邮箱访问权限（4.3）	查原邮箱服务到期日与 IMAP 开关	到期日在切换后有余量；IMAP 保持开启至验收完成 [2]

六、四个最容易翻车的操作细节

这四条不涉及技术判断，但每一条都对应一类真实事故。

改之前先把现有解析记录截图存档。 这是操作纪律，不是可有可无的提醒。删错一条 A 记录导致官网打不开，是这一步最典型的事故形态——真正麻烦的不是删错，而是事后找不到原始值，只能靠缓存和记忆去拼。

只新增，不删除。 添加邮箱相关记录时，不要动那些已经存在、你又不认识的记录。网站解析、子域跳转、其他业务系统可能都依赖它们。唯一该动的旧记录是指向旧邮箱服务商的那几条（见 2.4），而那也要先确认清楚再删。

注意代理／加速开关。 部分 DNS 控制台提供代理或加速功能，作用对象是 A、AAAA、CNAME 这类记录。给邮件相关的主机名开启代理会影响客户端连接，添加邮箱记录前先确认相关主机名的代理状态是关闭的。

改完不要反复改。 各级 DNS 会按旧记录的 TTL 缓存一段时间 [5]，反复改动只会让不同地区的缓存状态更乱。改完就等，用命令行确认新值已返回再做测试。已经排期的变更，可以在动手前先把 TTL 值调低，验收通过后再改回原值。

七、常见问题（FAQ）

先用命令行确认解析本身。跑 nslookup -type=mx 你的域名 或 dig mx 你的域名 +short，如果返回的值已经正确，说明解析已生效，只是你所在网络的缓存还没刷新——这时不要再改记录。如果本地也查不到，回头核对三件事：主机记录是不是 @、线路类型是不是「默认」[5]、记录值有没有拼写错误。等待时间由 TTL 决定，跨运营商完全生效没有统一承诺。

按这个顺序，不要跳步。第一，确认 MX 已能查到且与服务商文档一致；第二，确认主机记录为 @、线路类型为默认 [5]；第三，检查原域名有没有残留的旧邮箱 MX——官方要求先删除或暂停原解析记录 [2]；第四，查 SPF 是否存在多条（多条会导致 permerror，整条验证失败）[1][6]；第五，登录网页版看垃圾邮件文件夹。解析层没确认之前不要排查投递层，否则两类问题会混在一起。

不可以，而且后果比想象的严重。协议规定查询到多条 SPF 记录时直接返回 permerror，整条 SPF 视为验证失败 [6]；阿里邮箱官方文档也明确一个域名只能有一条，多个发信来源必须合并到同一条、用多个 include: 串联 [1]。另外还有一条上限：单次验证中触发 DNS 查询的机制与修饰符总数不能超过 10 个 [6]。计入的是 include、a、mx、ptr、exists 与 redirect，ip4、ip6、all 不计入；而 include 引入的那条记录里的项也算进同一个额度，所以接入的第三方平台一多就容易触顶。

因为搬家协议不负责搬它们。微软官方文档明确，IMAP 类型的迁移只迁移邮件文件夹中的项目，不迁移联系人、日历项和任务 [7]。这三类数据需要各自一条独立的导出导入路径。看到它们是空的，不必按故障排查，应当检查上线方案里有没有给这三类单独安排通道。

不要在切换后立刻停。官方提醒了两点：搬家应先搬完再切换域名解析；如果先切解析再陆续搬家，必须确保原邮箱的 IMAP 服务不停止，而原邮箱一旦到期就无法再搬 [2]。稳妥做法是让原邮箱的服务到期日在切换后仍留有余量，并把 IMAP 保持开启，直到新邮箱的配置、安全、备份三类检查全部验收通过。

先确认 SPF、DKIM、DMARC 三项都能查到且配置正确——缺任何一项都会让收件方少一份判断依据 [1][6]。重点查两处高频问题：SPF 是不是有且只有一条、展开后触发 DNS 查询的机制有没有超过 10 个；DKIM 公钥是否在复制时被换行或空格截断 [1]。如果三项都通过仍被误判，问题就不在身份验证层了，需要看发信 IP 信誉与邮件内容本身——那是另一个话题。

取决于解析生效的等待时间，而不是核对本身。命令行核对 DNS 记录、试收发、翻通讯录日历，实际操作时间不长；真正占时间的是等 DNS 缓存刷新——这段由 TTL 决定 [5]。建议的做法是把 13 项分成两段：不依赖解析的先做完（前置确认、旧记录清理、备份核对），依赖解析的等生效后集中验。

结语

这份清单解决的不是「能不能配通」，而是「上线之后会不会返工」。

十三项里最容易被跳过的是三项：原域名的旧邮箱解析有没有清理（2.4）、通讯录与日历有没有单独安排路径（4.1）、原邮箱的 IMAP 什么时候才能关（4.3）。前两项漏掉会在上线当天暴露，第三项漏掉往往是几周之后才发现，而那时已经补不回来了。

对缺少专职运维的企业，解析配置、迁移实施与上线前的逐项核对也可以交由本地授权服务商承接。以官方授权的阿里邮箱西南服务中心-大成云为例，其服务范围包含邮箱开通配置与相关的验收支持 [10]。

References