企业邮箱交付后如何验收配置

验收不是看后台显示「成功」，而是按约定逐项实测、失败复验、再确认交付。 本篇讲的是每一类配置具体怎么测、样本怎么选、失败了怎么定位、证据留什么。技术配置以阿里邮箱为例，使用其他产品时应换用对应原厂文档。

三条口径先记住：

谁签字、要哪几类交付材料、三态结论怎么判，由企业邮箱交付验收清单：配置对了没承担，本篇不重复；两篇配合使用——那一篇定签收框架，这一篇定实测动作。

测试设计：先定样本与适用状态，再动手

服务商通知「已经开通」后，先把测试范围定下来，否则结果无法判定。约定覆盖哪些账号、路径和客户端，以及预期结果、可接受的投递时限和异常处理人。

样本按业务风险选，不按比例选。 关键业务地址、邮件组、共享地址和特殊发信路径应明确列入——不能仅凭少数账号正常推断全员通过。

每个项目先标明适用状态，这一步决定后面的记录有没有歧义：

状态	什么情况下用	能不能勾选为已完成
适用	属于交付范围，有明确通过标准	达标后可以
不适用	双方确认不属于交付范围，并写明原因	不参与判定
范围未明确	范围或通过标准尚不清楚	不能，补齐约定后再测试
未通过	已纳入范围但没有达到标准	不能，进入整改
未测试	用例存在但本轮未执行	不能，需约定补测人与时间

「范围未明确」被直接勾成已完成，是验收记录最常见的失真方式。开始前还要确认域名解析的授权操作人，并登记企业管理员、恢复联系人和服务商临时权限的用途、有效期及撤销责任人。

解析核对：比对目标值，再用真实邮件验证发信身份

域名解析检查要同时看「配置写了什么」和「查询返回什么」。阿里邮箱把邮件路由（MX）列为收信必选配置，并将发信授权（SPF）、邮件签名（DKIM）与域名认证策略（DMARC）列入安全增强场景，部分收信方会要求这些认证[1]。

请实施人员从当前产品版本的控制台或原厂文档导出目标记录，逐项比对：

检查对象	怎么验证	发现差异后怎么处理
MX 邮件路由	查询域名的 MX 记录，核对主机名、优先级及全部目标值[1][2]	核查是否改在实际生效的解析平台，是否残留未解释的旧记录；不自行重排优先级
SPF 发信授权	检查同一名称下以 v=spf1 开头的记录，并覆盖项目内全部合法发信来源[1]	多个来源整理到同一条有效 SPF 策略，不追加第二条、也不删除仍在使用的来源
DKIM 邮件签名	按该域当前的选择器及公钥查询记录，再查看接收端保存的测试邮件认证结果[1]	核对选择器、公钥及发送系统配置；保留失败邮件供实施人员定位
DMARC 认证策略	核对策略与报告接收地址是否符合项目方案，记录测试邮件的实际认证结果[3]	先查合法代发路径与报告设置，再决定是否调整策略；不按固定观察天数自动收紧
多域与子域	多域、子域与域别名需分别核对相应记录[1]	只配主域时，子域发信会留下缺口

验收人员应记录查询域名、时间、查询点、返回值与目标值。 返回不一致时，结合缓存时间继续查询或排查——阿里云的判断方法是查询返回值与设置一致才代表该查询点已生效[2]。不能因为本地查询正确，就写成所有地区都已生效。

发信身份的证据只能来自接收端。每条约定发信路径都应保留接收端的原始邮件头及认证结果，并关联到同一条测试记录。业务系统代发要单独验证，不能用员工网页登录的一次成功代替——这也是最容易在上线后才暴露的缺口。

权限与登录保护：分网页端和第三方客户端两条路测

这一节是交付后第一天最容易出问题的地方，原因是网页端和第三方客户端走的不是同一套凭据与策略。

新购邮箱默认拦第三方客户端，这是安全默认值不是故障

先知道这条默认值，可以省掉一轮返工。 新购买的阿里企业邮箱默认带有一条已开启的、名为「三方客户端访问策略」的黑名单策略，该策略不允许登录第三方客户端；需要使用 Outlook、Foxmail 等客户端的账号，要到邮箱管理后台的「安全管理－账号安全－访问策略」把该账号添加为例外，或关闭此策略，5 分钟后生效[7]。

同一份文档还有三条会影响验收设计的规则：

三类登录保护分开验证

验证对象	怎么测	容易误判的地方
网页端与身份验证器	在项目启用相关保护后，用非可信设备进行登录验证[5]	已授信设备可免于重复验证，不能用可信设备「没弹验证码」就判定功能失效[5]
第三方客户端	核对账号是否允许使用该客户端、相关协议是否开放，以及是否要求独立安全密码[6][7]	不要把网页登录的验证流程直接套到第三方软件；客户端类型可按自有端、网页端、钉钉、Outlook 插件等分别控制[7]
操作记录	完成一次授权的配置变更或测试登录后，在管理后台查询对应日志[8]	日志不包含完整邮件正文，因此应同时保存获授权的测试邮件[8]

账号权限用受控测试账号演练

将最终账号清单与实际后台逐项对照，区分员工账号、别名和邮件组的数量及用途。建议用专门测试账号演练入职、角色变更和停用；存在组织同步时按本项目确定的同步规则核对结果，不对在用员工账号随意执行删除。

企业授权管理员应现场验证能否登录、查看约定配置，并确认恢复联系人由企业掌握。对受控测试账号，既要验证授权操作能完成，也要验证未授权的管理操作被限制。保留账号、操作前后状态、预期权限和实测结果，避免只用「登录成功」代替权限验收。

服务方需要操作权限时，不必交出主管理员——三个版本都支持分级管理员，可按职责范围授权[10]。另有两类权限容易漏登记：续费必须使用购买邮箱的那个阿里云账号，postmaster 无法操作续费；如果启用邮件归档，开启与查询归档的权限属于归档管理员，postmaster 默认不具备[10]。控制点归属怎么自查，见代理商模式和官方直购模式，本质区别在哪。

反垃圾规则调试要约定样本与预期动作

合同包含反垃圾规则调试时，建议由双方约定无害测试样本和预期动作，验证具体规则是否按约定执行。两条边界要先说清：

出现正常邮件被拦截时，先保留样本与日志定位，不把整个合作方域名加入白名单作为默认处理。 身份层策略怎么从观察推到生效档位，见企业邮箱安全加固的标准动作清单（进阶版）。

收发往返：按实际使用方式设计用例

测试应覆盖实际使用方式，而不是只发一封内部邮件。下面的矩阵是企业可采用的测试设计，不是厂家对时效或送达率的保证。

测试路径	建议操作	本次用例通过条件	证据重点
内部账号与业务地址	员工互发，并向约定别名、邮件组发信	目标账号按约定收到；邮件组实际接收范围与名单一致	发收地址、成员范围、实际结果
外部发入	用获授权的外部测试地址发往企业代表账号	目标账号在约定时限内收到，所在文件夹符合预期	双方时间、邮件位置；失败时保留退信或日志
对外发出并回复	发往主要往来邮箱类型并完成回复；有海外业务时纳入相应地址	发出与回复均按约定到达；应验证的认证结果符合项目标准	双向邮件、认证结果和测试路径
附件往返	使用业务常见大小的无敏感附件；大附件通道另测	附件可打开且内容完整；链接权限及下载结果符合方案	文件核对结果、链接访问结果
桌面与移动端	按约定客户端和协议收、发、回复及检查同步	所测功能符合约定，与网页端的对应操作结果可核对	软件版本、账号、网络、操作与结果

附件这一行要按官方参数设计样本，别用网盘容量当上限。 普通附件默认上限 50MB，域管理员可在 1–60MB 内调整；超出上限的文件走大附件通道，单个超大附件上限 4GB；大附件中转站的总空间是标准版 10GB、AI 尊享版 32GB[4]。10GB 是中转站总空间，不是单封邮件能发的附件大小——这一点在很多页面上被写反，设计用例时按 50MB 与 4GB 两个数字取样本。

建议给每条用例分配编号，并把「测试路径、预期结果、实际结果、证据位置、确认人」记在同一行。失败时再补上发件人、收件人、时间、主题或邮件标识、错误提示与复现步骤。管理员可用日志查询查看成功或失败状态等信息，但日志不包含完整邮件正文，因此应同时保存获授权的测试邮件[8]。

一次用例通过只证明本次条件下的结果。 后续发信来源、配置或客户端变化时，应复查受影响的路径——每接入一个新的营销平台或业务系统，用企业域名发信的路径就多一条[12]。

迁移数据：按日期范围与文件夹映射核对，再决定停旧

先拿出迁移前的范围清单，核对搬了哪些账号、日期范围和文件夹。

这一步最常见的误判是「数量不同就等于丢信」。 阿里邮箱搬家支持选择文件夹范围、邮件日期范围，并可选择把邮件单独存放或合并到系统文件夹[9]。验收时要去约定的位置找邮件——存放方式选了「单独存放」，原收件箱的数量自然和源端不同。

建议的核对顺序：

确需接受的差异应写明原因、影响和确认人，不能只记一个「已知问题」；抽样正常不能推出全部邮件零遗漏。

搬家完成前要按原厂要求保持源邮箱服务可用：保持原邮箱密码不变、IMAP 或 POP 服务正常启用、系统稳定且服务未到期；期间避免删除、移动邮件或修改文件夹名称[9]。凭据与安全策略的最终交接要与迁移负责人确认时点，避免为了交接改密而中断尚未完成的任务。

还有一条进度判读的常识：搬家会持续搬增量邮件，所以任务会持续显示「进行中」[9]——「进行中」不代表卡住，「不再变化」才需要排查。

配置验收通过后，旧系统是否停用仍要另行确认迁移结果、增量处理、保留资料及业务回退需要。先写清继续保留什么、由谁访问、何时停止服务，再执行停旧；不能把保留旧数据简单等同于同时保留两家 MX。 逐项对账的方法见迁移后怎么校验：数据比对的方法；开窗前的放行判断见迁移前风险评估该做哪些。

整改与复验：改了配置就要重测受影响路径

建议按「问题编号 → 处理措施 → 受影响用例 → 复验结果 → 确认人」记录整改过程，并注明影响范围、临时措施和约定完成时间。复验失败的项目继续保持未关闭状态。

改了解析或发信策略后，相关收发路径也要重测，不能只凭一张新的配置截图关闭问题——解析记录通常需要 10 分钟至 48 小时在全球范围内生效，改完立刻查可能还是旧值[2]。

交付结论的三种状态（通过／有条件通过／暂不通过）及其判定条件、以及该汇总哪几类签收材料，见企业邮箱交付验收清单：配置对了没。本篇只强调一条衔接规则：范围未明确项与未测试项都不能计入「通过」，它们要么补齐约定后测试，要么作为遗留项单独列明责任人与期限。

大成云提供域名解析、SPF/DKIM/DMARC 配置与验证、账号规划[12][13]，以及迁移中的数据盘点与逐项校验[14]。由大成云实施的项目可将上述测试记录交给项目联系人核对；具体陪验事项、交付物和响应标准应写入项目方案或合同——代运维页把响应时间、解决时间、违约责任列为写入合同的字段，页面本身未公布数值[15]。由服务商提交实施证据、企业授权人员确认业务结果，双方按约定完成交付。

沟通前准备哪些信息

交付验收实测常见问题（FAQ）

不要先动解析。最常见的原因是新购邮箱默认开启的「三方客户端访问策略」黑名单策略仍在生效，它不允许登录第三方客户端；解决方式是在「安全管理－账号安全－访问策略」把相关账号添加为例外或关闭该策略，5 分钟后生效[7]。其次要检查凭据类型——阿里邮箱可要求第三方客户端使用独立安全密码，开启后客户端原有凭据会失效[6]。把报错、客户端版本和网络环境交给管理员核查，按批准的范围调整后重测，不应先删除已验证的解析记录。

不一定，这是最常见的误判之一。已授信设备可以免于重复验证，所以用可信设备测试看不到验证提示是预期行为[5]。正确做法是用非可信设备进行登录验证。访问策略那一侧同样要实测——官方建议用目标账号从不同 IP 和客户端尝试登录，并查看系统日志确认策略触发情况；若策略开关未开启，测试会按未生效状态处理[7]。

先查存放方式和范围，再判断。搬家支持选择文件夹范围、邮件日期范围，并可选择把邮件单独存放或合并到系统文件夹[9]——如果选的是单独存放，原收件箱的数量自然和源端不同，邮件在约定的那个文件夹里。排查顺序是：先核对日期范围与排除文件夹，再核对文件夹映射与存放方式，最后才看是否需要补迁。确认属于真实缺失后，记录受影响账号、时间段和邮件类型，修正后重新抽取同类样本复验。

按官方参数取两个样本，不要按网盘容量取。普通附件默认上限 50MB，域管理员可在 1–60MB 内调整；超出上限走大附件通道，单个超大附件上限 4GB；大附件中转站总空间为标准版 10GB、AI 尊享版 32GB[4]。所以合理的用例是：一个接近 50MB 的普通附件验证常规路径，一个走大附件通道的大文件验证链接权限与下载结果。10GB 是中转站总空间而不是单封附件上限，用 10GB 文件做测试会直接失败并得出错误结论。

可以提出分阶段验收，但要由双方明确当前覆盖的部门、账号和路径，未参与部分保留为「未测试」，同时约定补测负责人和时间。若缺席部门涉及项目必须验证的核心路径，就不能用其他部门的结果代替它；阶段确认也不应写成全项目验收完成。「未测试」与「范围未明确」两类状态都不能计入通过，这是衔接签收结论时的硬规则。

不要。验收单只记录账号、权限归属、交接状态和保管责任人，敏感凭据通过企业批准的渠道单独交接。验收附件使用脱敏截图与测试邮件，避免把密码、验证码或身份验证器密钥放进多人共享文件。另外要注意权限分工：服务方需要操作权限时可用分级管理员授权，主管理员仍留在企业侧[10]；而迁移期间的改密时点要与迁移负责人确认，避免中断尚未完成的搬家任务[9]。

References