术语 · Amazon SES

Amazon SES 是什么？它对应用邮件有什么影响？

Amazon Simple Email Service（即 Amazon SES）是 AWS 用于通过 API 或 SMTP 接口发送和接收入站邮件的基础设施。对于应用团队，选择 SES 意味着要负责的不止发送调用：已验证身份、区域配置、IAM 权限、配额处理、邮件构建、事件接入、退信和投诉响应、抑制及运营监控。SES 受理意味着 AWS 将尝试投递；它不证明进入收件箱。应将 SES 视为更大应用邮件系统中的传输和反馈层。

了解服务的边界

SES 可通过 AWS API 或 SMTP 端点受理应用邮件，并可从结构化字段组装 MIME 邮件，或接受发件人组装的邮件。这使其成为基础设施，而非完整的产品工作流。您的应用仍需决定谁可以发送、哪个租户拥有域名、如何处理模板和收件人数据、何时可以安全重试，以及请求成功后用户看到什么。有用的架构会区分三种状态：应用受理任务、SES 受理邮件，以及收件服务器受理或拒绝邮件。这些状态发生在不同时间，需要不同标识符。请将自己的不可变任务 ID 与 SES 邮件标识符一同存储，以便协调 Webhook 重试和支持调查，而无需根据主题行或收件人数据猜测。

发信前先验证身份

AWS 将已验证身份定义为与 SES 配合使用的域名或邮箱地址。发信前，From、Source、Sender 或 Return-Path 身份必须满足 SES 的验证规则。对应用来说，域名验证通常是更持久的选择，因为它可以授权该域名下的地址，并支持域名级别的身份验证。验证并不是一个可以在每次部署间照搬的一次性勾选项。身份状态和 Easy DKIM 设置都是区域级的，因此在一个 AWS 区域已验证的域名，在另一个区域并不会自动就绪。请把接入流程设计为状态机：申请身份、展示确切的 DNS 记录、轮询权威的服务商状态，只有在所选区域报告成功后才允许生产发信。当 DNS 与其他发件方共用时，请保留现有的 SPF 和 DMARC 策略，切勿为了方便创建第二条 SPF 记录。

把区域纳入邮件配置

SES 的资源和运营限制都是区域级的。已验证身份、沙盒状态、每日配额、最大发送速率、Easy DKIM 设置、抑制配置和反馈目标在不同区域之间都可能不同。一个在 AWS 中有效的凭据，并不能让身份迁移到另一个 SES 端点。请在配置中把区域与服务商账户和身份放在一起，而不是隐藏在通用的环境默认值里。对于故障切换，请在事故发生前准备好备用区域：验证身份、发布 DKIM 记录、获取生产访问权限和合适的配额、配置事件目标、测试邮件标识符和 Webhook 处理，并确认了解抑制行为。否则，在故障期间只切换端点，可能会把一次事故变成验证失败、限流或反馈缺失。

审慎选择 API 还是 SMTP

AWS 支持通过 SES API 和 SMTP 接口进行生产发信。API 适合已经使用 AWS 身份验证和 SDK 的应用，并提供结构化邮件和原始邮件两类操作。SMTP 适合本来就使用 SMTP 的软件，但 SES SMTP 凭据与普通的 AWS 访问密钥不同，并且同样是区域级的。无论选择哪种方式，都仍然需要队列、幂等、超时处理和安全的重试规则。如果连接在应用收到响应之前失败，服务商仍可能已经受理了该邮件。避免用新的应用标识符盲目重试面向用户的请求。只入队一次，在可用时保留服务商响应，并让工作进程重试一个稳定的任务。只有在需要精确控制 MIME 时才使用原始邮件操作，并在将邮件交给 SES 之前校验邮件头和行长度。

把沙盒和配额视为运行时约束

新的 SES 账户与区域组合可能处于沙盒模式。AWS 当前记录的沙盒限制为每 24 小时 200 次收件人投递和每秒一封邮件；除邮箱模拟器外，只能向已验证收件人发送。生产配额因账户、区域和获批使用情形而异。配额按收件人而非 API 请求计算，因此一次向十位收件人发出的请求会消耗十个单位。请读取每个活动区域的实际配额，并围绕滚动每日额度和发送速率设计背压。服务商限流应延迟排队任务，而不是产生重复发送或显示为无法解释的成功。上线前申请生产访问权限和实际所需的限额，然后使用受控收件人进行负载测试。不要将沙盒描述为免费层级，也不要假设一个区域的批准适用于另一个区域。

基于事件构建投递状态

SES 发送操作成功，表示请求已被受理，SES 将尝试投递。这并不表示收件人打开了邮件、在收件箱中看到了邮件，甚至不表示收件服务器已接收邮件。SES 事件发布可以通过已配置的 AWS 目标报告发送、投递、退信、投诉、拒绝、渲染失败、延迟、订阅、打开和点击事件。在运维上最重要的区别是：投递事件代表收件人的邮件服务器已接收邮件，而退信和投诉事件则需要按策略做出响应。请以幂等方式接收事件，因为投递系统可能会重试通知。保留服务商邮件标识符和事件时间，拒绝格式错误的 Webhook 负载，并尽可能让状态转换保持单调。打开和点击数据是可选的互动信号，受隐私和客户端限制；它们不应改变对传输层投递是否发生的判断。

处理退信、投诉和抑制

抑制已知的无效收件人或不愿接收邮件的收件人，既保护用户，也保护发信账户。AWS 提供全局级、账户级、配置集级以及较新的租户级抑制机制，但具体作用范围取决于配置和区域。您的应用仍然需要明确的收件人策略。已永久退信的地址应停止接收常规重试，投诉应立即触发抑制，而移出抑制列表应以地址有效且收件人确实希望收到邮件为依据。在多租户产品中，请在接入客户之前决定抑制是账户级共享还是按租户隔离，因为共享抑制可能导致一个租户的结果影响另一个租户的发送。不要把原始地址写入通用的分析数据和日志。运营系统可能需要地址来执行抑制，但仪表板和实验应使用汇总或假名化的指标。

应用最小权限并隔离租户

IAM 策略可以限制某个主体能调用哪些 SES 操作，并可以约束发送操作中的 From、收件人或 Return-Path 地址。发送授权策略解决的是另一个问题：它让身份所有者可以委托他人使用已验证身份，并且可以独立撤销。对于单个应用，请优先使用只具备工作负载实际所需的发送和监控操作权限的主体。不要把 AWS 凭据交给 Web 浏览器。多租户邮件产品还需要应用层授权，因为一个共享的 SES 账户并不会自动理解您的工作区模型。在提交给 SES 之前，请检查经过身份验证的租户是否拥有已验证的 From 域名，将 API 密钥和邮件记录限定到该租户，并让跨租户的标识符查询不返回任何数据。服务商 IAM 与应用授权是互补的管控手段，不能互相替代。

使用生产就绪检查清单

上线前，请记录 AWS 账户、区域、身份 ARN、验证状态、DKIM 状态、沙盒状态、每日配额、最大发送速率、事件目标、抑制范围和凭据负责人。实际演练以下场景：一次正常投递、一次邮箱模拟器退信、一次投诉测试（如支持）、一次限流响应、一次事件重试，以及一次提交后的服务商超时。确认队列工作进程不会重复执行同一个稳定任务、投递事件会更新正确的邮件、永久退信会阻止后续的常规发送。为被拒绝的请求、限流、事件接收失败、退信和投诉变化以及配额余量设置告警。每当引入新的区域、域名、租户类型或邮件类别时，都要复查配置。这份检查清单能把 SES 从一个隐藏的依赖，变成一个有明确负责人、故障模式可观测的子系统。

SendHQ 适合放在哪里

如果团队希望获得 AWS 原生的控制能力，并准备好自行构建周边的应用层，可以直接集成 SES。SendHQ 提供范围更窄、以工作区为边界的邮件接口约定，包括已验证发信域名、限定作用域的 API 密钥、单封和批量发送、入站收件箱、投递事件访问以及抑制工作流。其公开 API 要求 From 域名属于该工作区且已通过验证，并会记录已受理的邮件以便日后查看。这一产品层并不能取代 SES 的身份、配额、信誉或收件方过滤规则。请分别评估这两层：服务商负责传输邮件并报告结果，而应用层负责执行租户归属、提供稳定的资源并呈现运营状态。无论是直接使用 SES 还是 SendHQ，都不能确保邮件进入收件箱，因此请从管控、可观测性、责任归属以及与您应用工作流的契合度来评估两者。

常见问题

Amazon SES 是邮件 API 还是 SMTP 服务器？

它同时提供 HTTPS API 和 SMTP 接口。请根据应用的身份验证方式和邮件组装需求进行选择，同时把队列、稳定的任务标识符、事件处理和抑制逻辑放在传输调用之外。

使用 Amazon SES 必须验证域名吗？

用作 From、Source、Sender 或 Return-Path 地址的每个身份都必须经过验证。邮箱地址身份可以用于有限的场景，而对于由应用控制的地址和 DKIM，域名验证通常更实用。

SES 返回成功响应，是否表示邮件已送达？

不是。它表示 SES 已受理该请求并将尝试投递。之后的投递事件表示收件人的邮件服务器已接收该邮件，但这两种状态都不能证明邮件进入了收件箱文件夹。

Amazon SES 的配额在各区域之间共享吗？

不共享。AWS 文档说明，发送配额、沙盒状态、已验证身份、DKIM 设置和抑制配置都是区域级的。请提前准备并测试每一个可能承接生产流量的区域，而不是在事故期间临时切换端点。

通过 SES 发信后，应用应该保存哪些信息？

保存稳定的应用任务 ID、受理后的 SES 邮件标识符、服务商和区域、当前状态、时间戳以及规范化后的投递事件。不要把邮件内容和收件人数据写入范围广泛的日志和分析系统。

什么时候应该使用 SendHQ，而不是直接使用 SES？

如果团队希望自己负责 AWS 集成和所有周边管控，请直接使用 SES。如果以工作区为边界的密钥、域名归属检查、入站收件箱、邮件资源、投递事件和抑制工作流对您来说是有用的应用基础能力，可以考虑 SendHQ。

参考来源

继续学习

Amazon SES 费用怎么算：产品团队的成本模型从收件人、数据量、价格套餐、独享 IP、事件基础设施、配额以及投递周边的工程投入等方面，为 Amazon SES 费用建立成本模型。