亚马逊AWS官方博客
Amazon SES Mail Manager:构建企业级邮件网关解决方案
概述
大型企业的邮件网关往往需要维护数百条自定义规则,涵盖安全、运营、审计、合规等多个维度。传统邮件网关面临三大痛点:
- 规则配置复杂:数百条规则难以管理和维护
- 缺乏测试环境:规则变更直接上生产,风险极高
- 开发流程繁琐:从开发到上线缺乏标准化流程
真实案例:某大型企业邮件网关包含 300+ 条自定义规则,一次规则更新导致整个企业邮件入口故障 4 小时,影响数万员工。
Amazon SES Mail Manager 提供了从规则开发、测试验证到生产部署的端到端解决方案,配套开源项目 mailmanager-staging-solution 让你快速搭建完整的测试环境。
💡 前置阅读: – 从零到一搭建发送平台 – 大规模营销活动和邮件高可用
SES Mail Manager 核心能力
产品定位
SES Mail Manager 是 SES 的高级功能组件,专为企业级入站邮件管理设计。
![]() |
邮件网关整体架构
核心优势:
| 维度 | 传统邮件网关 | SES Mail Manager |
| 部署 | 自建服务器、配置网络 | 云原生、开箱即用 |
| 扩展 | 硬件限制、手动扩容 | 自动扩展、无上限 |
| 成本 | 固定成本(硬件+人力) | 按量付费 |
| 维护 | 需要专职运维团队 | AWS 托管 |
| 测试 | 缺乏测试环境 | 完整开发测试流程 |
📚 参考文档:Amazon SES Mail Manager
Mail Manager 架构与工作流程
Mail Manager 采用 三层防护架构,从邮件入口到最终处理,提供完整的安全和路由能力。
架构流程图
外部邮件
↓
┌────────────────────────────┐
│ Layer 1: Ingress Endpoint (邮件入口) │
│ – 接收外部邮件 │
│ – 关联 Traffic Policy 和 Rule Set │
└────────────────────────────┘
↓
┌──────────────────────────────┐
│ Layer 2: Traffic Policy (流量策略) │
│ – 决定哪些邮件允许进入 (Allow) │
│ – 决定哪些邮件直接拒绝 (Block) │
│ – 基于发件人、IP、域名等条件 │
└──────────────────────────────┘
↓ (仅允许的邮件)
┌─────────────────────────────┐
│ Layer 3: Rule Set (规则集) │
│ – 对允许的邮件执行具体动作 │
│ – 动作:转发、归档、标记、扫描、丢弃 │
│ – 支持多个规则按优先级执行 │
└─────────────────────────────┘
↓
内部邮件系统 / 归档存储 / SMTP Relay
![]() |
Ingress Endpoint 配置
核心组件详解
1.Ingress Endpoint – 邮件入口
![]() |
Traffic Policy 配置
- 功能:作为邮件系统的统一入口
- 配置:
- 标准 SMTP 接口(端口 25)
- 关联 Traffic Policy(必需)
- 关联 Rule Set(必需)
- 支持 Public 或 VPC Endpoint
- 特点:
- 自动负载均衡和高可用
- SSL/TLS 加密传输
- 可创建多个 Endpoint 用于不同场景
2.Traffic Policy – 流量策略(第一道防线)
Traffic Policy 是 安全防护的第一道防线,决定哪些邮件可以进入系统。
工作原理:
Policy Statement 1 (Block): 拒绝来自黑名单域名的邮件
↓ (不匹配,继续)
Policy Statement 2 (Block): 拒绝超过 10MB 的邮件
↓ (不匹配,继续)
Policy Statement 3 (Allow): 允许来自白名单域名的邮件
↓ (匹配,允许进入)
Default Action: 拒绝所有其他邮件
配置示例:
![]() |
反钓鱼条件配置
可用条件: – 发件人域名(SENDER_DOMAIN) – 发件人 IP(SENDER_IP) – 收件人域名(RECIPIENT_DOMAIN) – 邮件大小(MESSAGE_SIZE) – TLS 协议版本(TLS_PROTOCOL)3.Rule Set – 规则集(业务逻辑层)
Rule Set 对 通过 Traffic Policy 的邮件 执行具体的业务逻辑。
![]() |
Rule Set 配置
工作原理:
Rule 1 (优先级 1): 扫描病毒
↓
Rule 2 (优先级 2): 归档到 S3
↓
Rule 3 (优先级 3): 转发到内部邮件服务器
↓
Rule 4 (优先级 4): 发送通知
可用动作:
| 动作类型 | 说明 | 使用场景 |
| Archive | 归档到 S3 | 合规审计、备份 |
| Deliver | 转发到 SMTP Relay | 发送到内部邮件系统 |
| Drop | 丢弃邮件 | 垃圾邮件、测试邮件 |
| Add Header | 添加邮件头 | 标记、分类 |
| Send to SQS | 发送到 SQS 队列 | 异步处理、工作流 |
![]() |
反钓鱼动作配置
配置示例:
4.Security Add-ons – 安全增强
Mail Manager 提供托管的安全扫描能力:
![]() |
Security Add-ons
- 反垃圾邮件扫描:自动识别垃圾邮件
- 反病毒扫描:检测恶意附件
- 反钓鱼扫描:识别钓鱼邮件
- 内容过滤:基于关键词的内容过滤
📚 参考文档: – Ingress Endpoints – Traffic Policies – Rule Sets – SMTP Relay
实战配置示例
场景 1:企业邮件安全网关
需求: – 拒绝来自黑名单域名的邮件 – 拒绝超过 25MB 的邮件 – 扫描病毒和钓鱼邮件 – 归档所有邮件到 S3 – 转发到内部 Exchange 服务器
配置步骤:
Step 1: 创建 Traffic Policy
Step 2: 创建 Rule Set
Step 3: 创建 Ingress Endpoint
# 创建 Ingress Endpoint
aws sesv2 create-ingress-point \
--ingress-point-name enterprise-gateway \
--type OPEN \
--traffic-policy-id <traffic-policy-id> \
--rule-set-id <rule-set-id>
Step 4: 配置 DNS
example.com. IN MX 10 <ingress-endpoint>.mail-manager-smtp.amazonaws.com.
场景 2:合规审计与内容过滤
需求: – 检测包含敏感关键词的邮件 – 对高管邮件进行特殊归档 – 记录所有邮件元数据到 DynamoDB
Traffic Policy:
Rule Set:
场景 3:多环境邮件路由
需求: – 开发环境:所有邮件归档,不实际发送 – 测试环境:只发送到测试域名 – 生产环境:正常发送
开发环境配置:
测试环境配置:
典型使用场景总结
| 场景 | Traffic Policy | Rule Set | 价值 |
| 企业邮件安全网关 | 黑名单过滤 + 大小限制 | 病毒扫描 + 归档 + 转发 | 保护企业邮件安全 |
| 合规审计 | 允许内部域名 | 敏感内容检测 + 归档 | 满足合规要求 |
| 多环境路由 | 基于域名的允许/拒绝 | 环境特定的处理逻辑 | 避免测试影响生产 |
| 规则开发测试 | 宽松策略 | 测试规则验证 | 降低变更风险 |
端到端测试环境方案
为什么需要测试环境?
企业级规则的复杂性:
某大型企业邮件网关规则示例:
├─ 安全规则(150 条)
│ ├─ 特定域名威胁检测
│ ├─ 恶意附件拦截
│ └─ 钓鱼邮件识别
├─ 运营规则(80 条)
│ ├─ 销售邮件自动归档
│ ├─ 客服邮件优先级路由
│ └─ 营销邮件分类
├─ 审计规则(50 条)
│ ├─ 敏感关键词标记
│ ├─ 高管邮件备份
│ └─ 合规日志记录
└─ 合规规则(20 条)
├─ GDPR 数据处理
├─ 金融行业规范
└─ 医疗数据保护
没有测试环境的风险: – ❌ 规则变更直接上生产 – ❌ 一次失误影响全公司邮件 – ❌ 故障排查困难,恢复时间长 – ❌ 业务损失难以估量
有测试环境的价值: – ✅ 规则在测试环境充分验证 – ✅ 发现问题不影响生产 – ✅ 支持快速迭代和回滚 – ✅ 降低运维风险 90%+
整体架构
![]() |
测试环境架构图
两个环境,完整流程:
| 环境 | 用途 | 组件 |
| 开发环境 | 规则开发和单元测试 | SMTP 测试工具 + 规则测试用例库 |
| 预发布环境 | 生产前集成验证 | VPC + Internal Mail Server + 完整规则集 |
开源项目支持:mailmanager-staging-solution
提供: – ✅ SMTP 测试客户端 – ✅ 规则测试用例库 – ✅ CloudFormation 模板 – ✅ 自动化部署脚本 – ✅ 监控和故障排除指南
开发环境:快速验证规则
核心工具:SMTP 测试客户端
预定义测试场景: 1. 垃圾邮件检测 2. 钓鱼邮件检测 3. 恶意附件检测 4. 合法邮件验证 5. 大附件处理 6. 发件人域名验证
快速开始:
📚 完整文档:GitHub 项目 README
预发布环境:一键部署
基础设施即代码:使用 CloudFormation 模板
一键部署:
部署时间:约 15 分钟
📚 完整模板:CloudFormation 模板
完整开发流程
开发 → 测试 → 预发布 → 生产
↓ ↓ ↓ ↓
Dev Test Staging Prod
↓ ↓ ↓ ↓
规则 单元 集成 上线
编写 测试 验证 部署
环境隔离策略:
| 隔离维度 | 实现方式 | 价值 |
| 账户 | 不同 AWS 账户 | 权限完全隔离 |
| 网络 | 独立 VPC | 流量完全隔离 |
| 数据 | 独立数据库 | 测试不影响生产 |
| 权限 | IAM 角色 | 最小权限原则 |
规则版本控制:
监控和故障排除:
- CloudWatch Logs:/aws/ses/mail-manager/
- VPC Flow Logs:网络流量分析
- CloudTrail:API 调用审计
常见问题: 1. SMTP 连接失败 → 检查 Ingress Endpoint 和网络配置 2. 规则不生效 → 验证规则语法和优先级 3. VPC Endpoint 问题 → 检查安全组和路由表
总结与下一步
通过本文,你已经掌握了: – ✅ SES Mail Manager 的核心能力和使用场景 – ✅ 端到端测试环境的架构设计 – ✅ 开源项目的快速部署和使用 – ✅ 完整的开发到上线流程
关键收益
效率提升: – 规则开发周期从 2 周缩短到 2 天 – 测试验证时间从 1 天缩短到 1 小时 – 故障排查时间从 4 小时缩短到 30 分钟
风险降低: – 生产故障率降低 90%+ – 规则变更风险可控 – 支持快速回滚
成本优化: – 无需自建邮件服务器 – 按需付费,成本降低 70% – 减少运维人力投入
下一步行动
- 评估需求:确认是否需要企业级邮件网关
- 试用项目:克隆开源项目,搭建测试环境
- 规则迁移:将现有规则迁移到 Mail Manager
- 生产部署:经过充分测试后上线
系列文章
- 第一篇:从零到一搭建发送平台
- 第二篇:大规模营销活动和邮件高可用
- 当前:安全省心的双向邮件网关
相关资源
📚 官方文档: – Amazon SES Mail Manager
💻 开源项目: – mailmanager-staging-solution
🎓 学习资源: – AWS SES MailManager Workshop
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。
本篇作者
AWS 架构师中心: 云端创新的引领者探索 AWS 架构师中心,获取经实战验证的最佳实践与架构指南,助您高效构建安全、可靠的云上应用 |
![]() |









