邮件系统去测评之前，自己应该先做哪些准备？

GB/T 28449-2018《信息安全技术 网络安全等级保护测评过程指南》 描述了测评的完整过程，其中测评准备阶段需要提交的材料清单，恰好可以反过来当作自查提纲。邮件系统应提前备齐：

• 定级与备案材料。定级报告、专家评审意见、公安机关备案证明。
• 安全建设方案与设计文档。GB/T 25070-2019《信息安全技术 网络安全等级保护安全设计技术要求》 对应的设计材料，要能和定级对象一致。
• 资产清单。邮件系统涉及的服务器、网络设备、安全设备、账号目录、存储与归档。
• 策略与制度。安全管理制度、操作规程、应急预案。

核心原则：三份图必须一致——定级报告里的边界图、建设方案里的拓扑图、资产清单里的实际资产。三图不一致是测评中最常见的「当场停摆」原因。

正式测评前，应主动用 GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》 的五个层面（安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心）对照邮件系统现状，找出差距。

邮件系统的高频差距集中在：内部链路明文、反垃圾无升级记录、日志留存不足、管理员权限未分离、边界访问控制过宽、本域未发布发件人策略。提前把这些找出来整改，比等测评机构开不符合项清单再返工省时得多。

邮件系统最容易在边界上出问题（前面定级篇已详述）。测评前必须有一张唯一的数据流边界图，覆盖：外部 MTA、提交入口、反垃圾/反病毒、存储、归档、Web/IMAP 访问、认证目录，以及任何云上或外包环节。

关键：这张图要在定级、设计、整改、测评四个环节共用同一份。每次架构变更都要回改它，并记录变更时间与原因——它本身就是最有说服力的证据之一。

测评前的整改顺序很重要。最忌「一次性把策略调到最严」，常导致合法邮件被拒、业务中断。推荐顺序：

1. 先让状态可观测。接收 DMARC 汇总与 TLS 报告，看清真实发送源与加密失败情况。
2. 补齐可见缺口。把合法发送源纳入 SPF/DKIM、内部链路启用加密、把日志留存期调整到能覆盖发现延迟。
3. 再收紧。本域 DMARC 从仅监控过渡到隔离/拒绝，MTA-STS 从测试模式切强制模式。

架构上，无论信创版还是标准版，建议把鉴伪、策略执行与日志留存集中到统一一层，让所有证据出自同一处、口径一致。

测评包含访谈环节，相关角色要能说清自己的职责与操作：

• 系统管理员能演示管理操作并说明审计留痕。
• 安全管理员能说明策略配置与变更流程。
• 审计管理员能独立读取日志（且与系统管理员非同一人）。

提示：「这三个人其实是一个人」在访谈时极易暴露，且属于明确的不符合。角色分离必须真实存在，而非只在制度文档里写写。

在落地上述技术建议时，可结合 MAEF 盾 等邮件安全防护能力，按邮件系统的信创版与标准版分别适配，将鉴伪、策略执行、日志留存与密钥管理统一收口，形成可举证、可审计的控制闭环。具体能力边界以实际部署版本为准。