企业邮箱交付验收清单：配置对了没

企业邮箱验收不是看后台显示「成功」，而是核对项目范围、外部查询、真实收发与权限交接四类证据。 服务方实施负责人提交证据，域名管理员、IT、业务与采购或合同负责人分别确认；公共 DNS 返回值、约定的身份认证结果和真实业务路径，都必须与签约范围一致[1][2]。

签收结论按两条线判断：

签收前先锁定验收范围和确认角色

企业邮箱是否「配置完成」，首先取决于双方约定了什么。验收前应冻结一份范围确认单，至少写清企业域名、账号数量与类型、纳入项目的发信系统、需要验证的客户端或管理功能、项目版本，以及不一致时以哪份书面文件为准。没有这份基线，同一个测试结果可能被一方理解为完成，被另一方理解为漏项。

确认角色也要在测试前写进项目记录：

大成云开通服务包括账号创建、域名解析、邮件身份认证配置和逐项收发验证，并列出账号清单、管理员后台说明与操作培训等交付内容[3]。这些是大成云当前公开的服务形态；单个项目实际采用哪些项目、由谁确认，仍以双方书面范围为准。

企业邮箱交付验收矩阵

下面这张表从甲方签收视角组织证据。每一行都要能回答四件事：验什么、拿什么证明、谁确认、什么情况不能签。

验收对象	必须提交的证据	确认角色	阻断条件
项目范围与版本	双方确认的域名、账号、发信系统、功能与版本清单；对应订单或项目文件编号	IT 负责人；采购或合同负责人	实际开通内容与确认清单不一致，或无法确定当前验收的是哪个版本
DNS 邮件路由	变更后的记录清单；带查询时间与查询点的公共 DNS 结果；预期值与返回值对照[1][2]	域名管理员；IT 负责人	公共查询与预期不一致，存在未解释的旧记录或冲突记录
发信身份认证	每条约定发信路径的接收方原始邮件头或可导出的认证结果；记录 SPF、DKIM、DMARC 结果及对应域名[1]	IT 负责人	应通过的认证失败、域名不匹配，或仍有约定发信路径未取证
外部发入	外部邮箱发往代表性企业账号的测试记录，包含发件人、收件人、时间、结果及失败时的错误信息	IT 负责人；业务验收人	核心账号无法收信，或失败原因与处理责任未明确
对外发出与回复	代表性业务账号向外部地址发信并完成回复；保留双方邮件、到达时间与接收方邮件头	业务验收人；IT 负责人	核心业务路径无法完成发信或回复，或结果无法复现
账号与客户端	最终账号清单；抽样登录记录；约定客户端或移动端的收发与同步结果	IT 负责人；业务验收人	账号数量、角色或约定访问方式与范围不符，且无书面变更
管理员权限交接	企业可控制的管理员账号、角色清单、恢复联系人及现场登录验证记录	IT 负责人；采购或合同负责人	企业无法独立进入管理后台，或关键恢复路径只由服务方控制
文档与培训	项目约定的账号清单、管理员说明、操作材料和培训确认记录	IT 负责人；采购或合同负责人	合同或范围确认单列明的交付材料缺失
异常与复验	异常清单、影响范围、临时措施、责任人、关闭条件和复验结果	对应技术或业务负责人；最终签字人	核心异常未关闭，或遗留项没有责任人、关闭条件与复验方法

阿里邮箱的域名解析指南把 MX 列为收信必选项，把 SPF、DKIM、DMARC 放在安全增强场景，并注明部分收信方会要求这些认证[1]。因此，验收矩阵应根据本项目的域名和发信路径确定适用项，而不是把一份固定记录清单机械套给所有企业。

公共 DNS 证据也不能只截取控制台的绿色状态。阿里云 DNS 的判断方法是：查询返回值与设置一致，代表该查询点已经生效；两者不一致时，应结合缓存是否到期继续等待或排查[2]。签收包需要同时保留查询对象、时间、查询点和返回值，复验人员才能重做同一检查。

接收方原始邮件头用于保留身份认证结果，但单独截取某一项「通过」结果，无法说明它对应哪条发信路径，也不能证明其他路径已经完成验收。因此，邮件头应与接收账号、接收时间、发信路径和原始邮件一起归档。

把证据汇成一份可签字的交付包

验收矩阵跑完后，建议按同一项目编号汇总八类材料：

签收结论可以分为三类，但具体授权人与法律效果应以企业制度和双方合同为准：

结论	适用条件	必须留下的记录	下一步
通过	范围内项目均有可复验证据，阻断项全部关闭，约定交付物齐全	最终证据索引、确认人、日期与版本	归档当前版本；后续变更按触发条件复验
有条件通过	核心收发与管理能力可用，仅剩不影响当前使用的非核心事项	遗留项影响、责任人、关闭条件、计划时间与复验人	到期复验；未满足关闭条件时不得把遗留项改记为已完成
不通过	任一核心路径失败、范围不符、管理员权限未交接，或关键证据无法复验	失败证据、影响范围、责任归属与重新验收条件	修复后重新提交对应证据，不沿用旧结论

复验不需要套用统一的「观察几天」。DNS 或身份认证记录再次变更、增加域名或发信系统、管理员权限发生变化，或者遗留项申请关闭时，都应重新生成受影响部分的证据，并把新结果关联到原签收记录。

涉及邮箱迁移时单独走迁移验收

如果本次项目还包含历史邮件迁移，完成上面的配置矩阵只能证明新系统的入口、收发路径和管理权限达到当前验收条件，不能替代对历史数据、迁移异常和旧系统停用的确认。

迁移范围、试迁、切换和旧系统停用应作为独立项目分支放行。完整流程及迁移交付物可查看《找人做邮箱迁移，靠谱的流程应该长什么样》。配置验收记录与迁移验收记录可以归入同一个项目档案，但两者应保留各自的证据索引和签字结论。

常见问题（FAQ）

可以由同一名 IT 完成配置和技术说明，但不要让同一个人生成全部证据后再独自确认全部结果。域名管理员核对公共解析，业务使用人完成真实收发，采购或合同负责人核对范围与交付材料；每个人只确认自己能够复验的部分，并在签字页记录分工。

不宜只用一个域名或一条发信路径的结果代表全部范围。阿里邮箱指南要求每个域名独立配置 MX，相应身份认证记录也需要按域生成[1]。验收时先建立「域名 × 发信系统」清单，再按批次保存公共查询、邮件头和真实收发结果；共用的项目文件可以复用，路径证据不能互相替代。

不能。阿里邮箱域名解析指南将三者列为安全增强配置：SPF 用于授权合法发件服务器 IP，DKIM 用于签名邮件内容、防止篡改，DMARC 用于统一 SPF／DKIM 策略并处理代发或仿冒场景[1]。因此，验收可以确认约定的身份认证配置是否工作，不能据此承诺每封邮件一定进入收件箱。

保留期限应写进项目记录，并按合同和企业内部记录制度执行。至少在全部遗留项复验关闭前，原始邮件、邮件头、公共查询结果、权限交接和签字版本都应保持可访问；需要更长时间留存时，由企业的 IT、法务或档案责任人确定期限与存储位置。

准备好范围与角色后，如何申请交付验收支持？

首次沟通需要确认本次验收覆盖的域名与发信系统、账号与客户端范围、企业内部四类确认角色，以及约定交付物和阻断条件，并据此判断验收包应包含哪些证据。

申请前，请准备企业域名清单、当前邮箱平台与版本、账号数量与角色、所有使用企业域名发信的系统、DNS 解析平台与操作权限人，以及计划的验收窗口。企业邮箱服务入口与联系电话可在大成云首页核对[4]。

References