步骤一：先确定为什么要换
这个案例是一个出海工具站，日均发送约 2 万封邮件，主要是登录验证码、任务完成提醒、订阅到期通知，少量运营邮件。原来用的是一站式邮件平台，好处是省心，问题是量起来后费用明显变高。
做 ses对比时，我们没有一上来就喊“SES 更便宜”。先拆邮件类型：事务邮件占 85% 左右，营销邮件占比低，模板复杂度也不高。这种结构就很适合把底层发送切到 Amazon SES。
ses对比：一次迁移案例复盘
ses对比不能只看官方功能表，最好看真实迁移过程。下面复盘一个出海工具站从第三方邮件平台切到 Amazon SES 的全过程：为什么换、怎么测、哪里翻车、最终省了什么成本。
步骤二：搭一套并行测试环境
第一周没有替换生产流量，而是并行跑。老平台继续负责真实用户邮件，SES 只发内部测试、种子邮箱和少量低风险通知。测试重点不是能不能收到，而是 Gmail、Outlook、Yahoo 等邮箱表现是否稳定。
同时补齐 SPF、DKIM、DMARC，发件域名用子域名隔离，比如 mail.example.com。这样即使测试阶段表现一般，也不会直接拖累主域名信誉。
步骤三：按邮件类型灰度切流
第二周开始切 10% 的验证码邮件，因为这类邮件用户预期强，打开快，投诉低。观察两天后提升到 30%，再到 50%。期间硬退信地址立即停发，投诉用户直接加入抑制名单。
这里和原平台的对比很明显：一站式平台后台好看，事件流也直观；SES 更像发动机，日志、事件、统计要自己接。我们用消息队列加数据库记录每封邮件状态，才把可观测性补回来。
步骤四：保留营销邮件在老平台
这一步很关键。团队最开始想全量迁走，但复盘后发现营销邮件需要模板编辑、分组、A/B 测试和退订页，老平台做得更顺手。于是最后方案是：事务邮件走 SES，营销活动继续留在原平台。
这就是 ses对比里容易被忽略的点：不是二选一。底层通道适合 SES，运营玩法适合营销平台。混合架构反而最稳，既省钱，也不牺牲运营效率。
步骤五：复盘结果和经验
迁移完成后，验证码和通知邮件的单位发送成本明显下降，开发侧多维护了一套事件处理和告警。真正的收益不是“全部换成 SES”，而是把高频、标准化、低营销属性的邮件迁出去。
如果你的业务邮件结构类似，这个 ses对比案例可以直接抄作业：先分类，再并行测试，再灰度切流，最后保留适合原平台的部分。别为了技术洁癖全量迁移，省钱不是把自己省进坑里。
推荐阅读
常见问题
- ses对比第三方平台，最大差别是什么？
- SES 更偏发送基础设施，便宜但要自己开发管理能力；第三方平台更偏运营工具，上手快但成本通常更高。
- 迁移到 SES 要一次性全切吗？
- 不建议。先用低风险邮件灰度，比如验证码、通知类邮件，稳定后再扩大比例。
- SES 适合替代营销邮件平台吗？
- 不一定。如果你依赖模板、分组、自动化和 A/B 测试，营销平台仍然更省心。