邮件归档最容易被忽略的三件事

邮件归档不是把邮件继续留在收件箱，而是按规则形成可集中管理、调取和处置的副本；上线前最容易漏掉的是采集范围、调取与复验、保留与处置这三项边界。 三项都有官方规则可以对照，而其中几条与直觉相反——例如用户自己删掉的邮件依然会被归档，而被监控的邮件不进入归档[1]。

三条口径先记住：

第一件事：采集范围要写清账号、方向、起始时间和历史邮件

归档功能已经开启，不等于应该进入归档的邮件都被采集。企业先要回答「从哪些对象、哪个时点开始收集什么」。

《中华人民共和国档案法实施条例》要求为应当归档的材料建立责任制并明确范围，单位内设机构还应收集齐全，再交由档案机构或工作人员集中管理[2]。这不意味着每一封企业邮件都会自动成为档案——是否归档，应先看邮件承载的记录类别和企业确认的管理要求。

一份可执行的范围清单至少要写明：

官方归档细则里有几条与直觉相反

写范围清单之前，先把产品层面的既有规则看一遍，否则清单会和实际采集结果不一致。阿里邮箱公布的归档细则里有几条值得特别注意[1]：

场景	官方规则	对范围清单的影响
用户自己删除邮件	用户删除的邮件依然被归档	不能靠「让员工删掉」来控制归档范围
账号被删除或禁用	删除或被禁用的邮箱账户中的邮件依然被归档	离职账号的邮件仍在归档内，需纳入权限与处置规划
被监控的邮件	监控的邮件不归档	同时启用邮件监控与归档时，会出现范围缺口
同时给多人发送	只归档一封	按收件人数量核对归档条数会算错
分别给多人发送	归档多封	同上，两种群发方式的归档结果不同
自动转发、自动回复、垃圾邮件	进行归档	归档量估算要把这三类算进去
系统通知邮件	进行归档	同上
外发受限用户发信	发送成功的进行归档	未发出的不在归档内
外域发给收信受限账户	未接收成功的不归档	退回的邮件查不到，排查时不要当成漏采

「被监控的邮件不归档」这一条最容易造成事后争议：企业往往对重点岗位同时启用监控与归档，结果恰恰是这部分邮件在归档里查不到。启用监控的账号范围，应当和归档范围一起画在同一张图上。

「全员归档」也不是足够精确的范围。共享邮箱是否算一个账号、别名邮件归到哪个主体，都会改变结果。验收时应从清单中抽取已知邮件，确认每类对象都有对应记录；发现漏采后，先修正范围或配置，再重新验证。

需要先区分归档、备份与灾备，可查看邮件归档、备份与灾备到底什么关系。

第二件事：调取与复验要变成可执行的验收项

「邮件已经存下来了」只是开始。企业还要验证邮件能否定位和完整导出，并确认谁做过操作。另一名复验人员也应能依据同一组记录重做结论。

《档案法实施条例》对电子档案提出可靠来源、规范程序、准确记录和全过程可追溯等要求，并要求在接收时检测真实性、完整性、可用性和安全性[2]。对应到邮件归档项目，验收可覆盖四类结果：

三处配额会直接影响验收怎么做

调取环节最常见的落差不是「查不到」，而是「查得到但拿不全」。三处官方配额要提前算进方案[1]：

这三条合起来意味着一件事：「一次性把全员全周期归档导出来」不是一个按钮能完成的动作，需要拆批执行并在任务过期前把文件取走。如果定期向监管报送是常态需求，这一点应当在选型阶段就评估，而不是等到第一次报送才发现。

每项验收都应保存输入、操作路径、预期结果、实际结果和证据位置。「支持搜索」不是验收结果——用一封已知邮件实际搜索并导出，才能说明当前配置可用。

这些记录有助于说明邮件从何而来、如何保管和由谁调取，但不能承诺某封邮件在具体争议中必然被采信。个案证明力仍取决于形成过程、完整性、取得方式和适用程序。

第三件事：保留与处置要按记录类别形成责任链

邮件归档没有适用于所有企业、所有邮件的统一年限。期限跟随记录类别、适用规则、合同要求和企业内部管理目的。员工人数或产品默认值不能替企业作出这个判断。

《档案法实施条例》规定保管期限届满的档案应当鉴定并形成报告；仍需保存的要重新划定期限，需要销毁的应按有关规定处理[2]。对应到企业邮件管理，保留策略还要写清：

产品默认值有三条硬边界，会反过来限制策略

写保留策略时，产品能做到什么是前置约束。阿里邮箱云端归档有三条边界[1]：

边界	官方规则	对策略的影响
默认年限	归档保留年限默认 5 年，超期自动删除，支持付费延长	要求超过 5 年时，必须在方案阶段就确认延长方式
追溯上限	从开启时点算起保留新邮件；往前只能追溯 5 年内的历史邮件，每 30 天最多 2 次追溯任务，不支持追溯已删除的历史邮件	开启越晚，可覆盖的历史越少，且这一步不可逆
实例依赖	邮箱实例到期未续费超过 30 天后释放，同时阿里侧不会保留归档邮件	归档副本的存续绑定在邮箱续费上

第三条尤其需要写进责任链。归档的意义之一是「即使邮箱不在了，记录还在」，而这一条说明云端归档做不到。 邮箱到期日应当和归档保留期限一起进企业自己的提醒，而不是只依赖服务方通知。留存要求超过 5 年、或者需要副本独立于实例存续的企业，要单独评估本地副本方案——可参考大成云归档与扩容方案：合规留存 + 弹性空间。

延长年限的效果也有前提：按官方说明，把归档延长到 8 年，指的是从开启时点算起保留新产生的邮件 8 年，往前仍只能追溯 5 年内在阿里邮箱使用过的历史邮件；5 年前的旧邮件即便延长年限也无法追溯，除非这些历史邮件是通过邮箱搬家进来的[1]。这条把「先迁移再开归档」和「先开归档再迁移」的差别放大成了几年的可追溯范围差。

另一个方向也要写明：争议未结束时先暂停自动处置，是降低误删风险的内部控制动作，不是给所有邮件增加一个统一法定年限。个人信息的保存期限应当为实现处理目的所必要的最短时间[3]，所以一律设成最长年限并不等于更合规。具体法律适用和期限，应由企业法务、合规负责人或专业顾问确认。

需要定位不同行业和记录类别的期限，可查看哪些行业必须做邮件归档、要留多久。

三项边界写进同一张验收表后再上线

把三项内容放进一张表，能避免业务、法务、信息技术部门和服务方各自保留一套口径。

边界	要书面确认的字段	验收证据	主要责任方
采集范围	账号、方向、起点、历史数据、附件与排除项；同时启用监控的账号范围[1]	范围清单、已知样本及采集结果	业务、信息技术部门、服务方
调取与复验	检索字段、导出格式与跨度上限、归档管理员角色、日志动作[1]	搜索与导出样本、权限测试、日志记录	信息技术部门、档案／合规、服务方
保留与处置	记录类别、期限依据、延长方式、暂停条件、审批与删除[1][2]	留存清单、鉴定／审批记录、处置结果	业务、法务／合规、档案与信息技术部门

阿里邮箱中国区版本介绍列出三个版本均支持邮件归档，并另列日志查询功能[4]。也就是说「有没有这个功能」通常不是选型难点，前面三项边界才是。

沟通前准备哪些信息

邮件归档边界常见问题（FAQ）

可以先让明确起始时点后的新邮件进入归档，但要知道代价。按官方规则，开启归档后新邮件自动归档，往前追溯只能覆盖 5 年内的历史邮件，每 30 天最多提交 2 次追溯任务，且不支持追溯已删除的历史邮件[1]。所以拖延开启时点会永久性缩小可覆盖范围。项目文件要写明历史数据尚未覆盖、后续处理责任和单独验收方式；历史邮件完成补录与复验前，不能把范围写成「全部历史邮件已归档」。

不能只用总体比例掩盖范围内的漏采。应记录受影响账号、时间段和邮件类型，再确认是范围、配置还是采集异常。排查时先对照官方归档细则排除三类「本来就不归档」的情形：被监控的邮件不归档、外域发给收信受限账户且未接收成功的不归档、同时给多人发送的只归档一封[1]。确认属于真实漏采后再修正配置，重新抽取同类样本，复验结果与原异常编号形成闭环。

有。官方规则明确：归档开启后邮箱中删除的邮件也会在归档中保存，用户删除的邮件依然被归档；删除或被禁用的邮箱账户中的邮件也依然被归档[1]。这对取证是好事，但同时意味着两件事要提前规划：一是不能靠「让员工清理」来收缩归档范围；二是离职人员的邮件仍在归档内，其访问权限与到期处置要写进策略。需要注意的例外是追溯功能——追溯不支持已删除的历史邮件，也就是开启归档之前就删掉的邮件捞不回来[1]。

企业内部控制上应先暂停相关记录的自动处置，再由法务、合规或授权责任人确认后续动作。决定依据、批准人和恢复处置的条件都要保留。这是防止误删的风险控制，不等于为所有邮件设定统一法定期限——个人信息的保存期限仍应为实现处理目的所必要的最短时间[3]。还要注意产品侧的自动删除：云端归档默认 5 年、超期自动删除[1]，所以「暂停处置」这个动作要确认在产品层面是否真的能做到，做不到就要提前导出。

先确认可导出的账号与时间范围，以及文件格式、邮件头、正文、附件和元数据。这里有两条硬约束要一起算：导出为 eml 格式，单账号单次支持导出 365 天、多账号仅支持 30 天，任务列表只展示近 30 天内提交的任务[1]；以及邮箱实例到期未续费超过 30 天释放后，阿里侧不会保留归档邮件[1]。也就是说导出窗口既受单次配额限制，又受实例存续时间限制，必须倒排时间表。还要确认必要操作日志、复验方法和原系统最终处置方式，否则可能在服务结束时才发现数据可以查看却无法完整迁出。

References