结论：Amazon SES 邮件模拟器不能完全替代测试收件箱。 如果目标是验证成功、退信或投诉等事件及自家系统的处理逻辑，优先用模拟器；如果还要断言正文、验证码、链接或真实外部收件体验，就必须补上可读取邮件的测试方式。
正在 Amazon SES sandbox 中验证自家产品发信流程的开发者，可用本文区分模拟事件与真实收件验收。
负责退信、投诉或投递事件回归的 QA 工程师，可据此划定模拟器覆盖范围。
上线前要检查邮件正文、验证码或链接的独立开发者，可按文中的步骤补齐收件测试。
按验收目标选择工具，而不是只看发送成功
Amazon SES mailbox simulator 是用于触发预设发送结果的模拟器，不是一个供你登录并读取邮件正文的通用收件箱。需要分清三个不同证据：SES 接受发送请求、SES 生成或发布事件、邮件进入真实收件服务商的收件位置。前两者不能自动证明第三者。
| 验收目标 | Amazon SES 邮件模拟器 | 可读取的测试收件箱 | 真实外部邮箱 |
|---|---|---|---|
| 检查成功、退信、投诉等预设事件 | ✅ 适合，事件由预设收件地址触发 | ❌ 不能代替模拟事件覆盖 | ⚠️ 只能观察真实发生的结果 |
| 断言正文、验证码和链接 | ❌ 不提供可读收件箱内容 | ✅ 可打开邮件并检查正文、链接 | ✅ 可人工或自动化检查 |
| 确认外部邮件服务器接收 | ❌ 模拟结果不是外部服务商的接收记录 | ⚠️ 取决于收件方式是否接入真实收件环境 | ✅ 能提供该收件环境中的实际证据 |
| sandbox 中测试发信 | ✅ 可向模拟器发送 | ⚠️ sandbox 下真实测试地址须符合验证限制 | ⚠️ 只能使用符合 sandbox 限制的地址 |
这张表回答的是测试覆盖能力，不是工具好坏。常见组合是：用模拟器回归事件处理，再用可读取的测试收件方式检查邮件内容；上线验收还需向实际外部邮箱发送测试邮件。
模拟器会提供可供检查的实际邮件正文吗？ 不会把事件通知当成邮件正文。模拟器让应用针对预设场景走不同结果；它不会因此提供可供检查的真实收件箱页面。要验证验证码是否正确、模板变量是否渲染、链接是否指向预期页面，需要一封可读取的邮件及相应断言。
模拟器能覆盖什么，不能覆盖什么
AWS 文档列出的模拟场景包括：成功接收、退信、自动回复、投诉，以及收件地址在抑制列表中的情况。调用时需通过 Amazon SES 发信，并将收件地址设置为对应场景；从 SES 之外直接向模拟器地址发信不会触发模拟结果。成功场景适合检查发送后的成功分支，退信和投诉则适合检查自家产品是否更新账号状态、记录事件并执行预期的后续处理。(AWS 的 Amazon SES 邮件模拟器说明)
这些是模拟出来的事件，不是某位真实用户退信或投诉的报告。例如，模拟投诉可验证应用有没有接到投诉通知并停止对相关测试账号继续发送；它不能证明真实服务商会把某封邮件判为垃圾邮件。模拟器也没有专用地址用于测试 Reject 事件；AWS 文档将该类测试与含安全测试文件的受控流程区分开来。不要误把模拟器的预设收件地址当成所有事件类型的覆盖入口。
另一个常被忽略的边界是，事件通知送达本身也需要单独验证。Amazon SES 可通过通知邮件、SNS 或事件发布等方式提供事件信息；应用需要确认所选通知链路已启用，并且能正确解析事件。若配置了多种通知方式，同一事件可能收到重复通知，因此回归测试还应检查幂等处理，避免同一退信被重复计数或反复触发后续动作。(AWS 的 SES 事件通知配置说明)
模拟事件能确认邮件进入了真实收件箱吗？ 不能。它能模拟 SES 对指定场景的处理，并不把邮件发送到 Gmail、企业邮箱等真实外部收件服务中。即使看到模拟成功事件，也只能证明对应模拟路径得到预期处理，不能当作真实收件人的收件箱、垃圾邮件夹或隔离区检查结果。
内容可见性与投递证据是两回事
想检查验证码、模板和跳转链接，测试必须能读取邮件。建议在测试用例中分别断言：主题与关键文案符合预期；验证码或动态字段已填充且没有模板占位符；链接目标域名和路径正确；纯文本与 HTML 版本都符合产品要求。最后一项是否需要，取决于产品实际发送的邮件格式。
如果自动化流程需要从邮件中提取验证码，测试收件方式还必须让测试程序能取到邮件内容，并把“等待邮件”“筛选目标邮件”“读取验证码”“提交验证码”作为独立断言。Amazon SES 返回的发送成功响应或 Send 事件，不包含“测试程序已读取并校验正文”这一证据。SES 的 Delivery 事件表示邮件已交给收件方邮件服务器；事件数据可包含该服务器的 SMTP 响应，但不等于测试人员已检查实际收件位置。(AWS 的 SES 事件数据字段说明)
⚠️ 不要把“事件里有 Delivery”改写成“邮件已进收件箱”。收件服务商接收邮件后，仍可能将其分类到垃圾邮件或其他文件夹；若产品验收关心用户最终看到什么，就要在实际收件环境中确认。
外部收件测试提供另一类证据：邮件是否到达所选服务商、显示在哪个文件夹、主题和发件人如何呈现，以及用户点击链接后是否抵达正确页面。SPF、DKIM、DMARC 配置、发件域名信誉、收件服务商的过滤与分类都会影响实际体验。模拟事件不能单独验证这些条件在某个外部收件环境中的结果；AWS 的投递问题排查建议也包含检查邮件是否被过滤为垃圾邮件等实际收件侧因素。(AWS 的 SES 投递问题排查说明)
所以，验收记录应写明证据对应的层级：SES 接受请求、事件通知抵达、测试收件箱读到正文，或真实外部邮箱观察到邮件。不要把不同层级合并成一句“邮件发送成功”，否则回归失败时很难判断问题究竟在应用、事件通知还是实际投递。
sandbox 下先做事件回归，再补真实收件
在 Amazon SES sandbox 中，怎样安排自家产品的邮件测试？ 先用模拟器地址验证预设事件及应用处理逻辑；需要看正文时，再选一个符合 sandbox 验证要求的可读取测试收件地址。AWS 文档说明，sandbox 账户可以向模拟器发送邮件；若发送到普通邮箱地址，该收件地址需要满足相应验证限制。sandbox 账户的限制还包括每天最多 200 封、发送速率最多 每秒 1 封。这些限制按 AWS 区域账户状态核对，不能把模拟器可用误解为所有真实邮箱都可收信。(AWS 的 SES sandbox 访问说明；AWS 的 SES 发送配额说明)
模拟器邮件不计入每日发送配额，也不影响退信率、投诉率或 Virtual Deliverability Manager 指标；但仍受账户最大发送速率限制，且按普通 SES 邮件计费。换句话说，它适合验证处理分支，却不能拿来测实际外部投递表现或据其事件推断真实发件信誉。(AWS 的 Amazon SES 邮件模拟器说明)
按下面的顺序搭建自家产品测试流程：
- 先列验收目标。 把“事件分支”“正文与链接”“外部收件表现”分成不同测试项，并为每项指定需要保存的证据。
- 接通事件通知链路。 选择应用实际使用的通知机制，确认测试环境能收到事件；检查处理器可解析事件类型和相关邮件标识。通知配置与身份、AWS 区域有关，测试时不要只检查控制台上是否出现过事件。
- 用模拟器覆盖事件处理。 分别发送到成功、退信、自动回复、投诉和抑制列表场景的模拟地址，核对应用日志、账号状态及后续动作。测试对象限定为自家产品及测试账号，不用于批量注册第三方平台。
- 单独验证正文。 把应用生成的邮件发到可读取的测试收件箱，断言主题、模板变量、验证码和链接。用唯一测试账号或关联标识匹配邮件，避免并行测试时误读其他用例的邮件。
- 再做外部收件验收。 在有权限使用的外部邮箱中检查实际到达、收件分类、发件人显示和链接跳转。至少记录收件服务商、收件位置和是否成功读取；不要仅凭 SES 的发送响应判定通过。
- 分开记录测试结果。 将模拟事件结果、正文断言和外部邮箱观察记录为不同项。若只测了前两项，就不要把报告标成“真实收件已验收”。
需要注意，模拟器虽可在 sandbox 中使用，但普通收件地址仍受 sandbox 验证限制。退出 sandbox 后，账户可以向未验证的收件地址发送邮件，但发件身份仍须验证。AWS 还说明 sandbox 状态按区域分别管理，因此切换区域后要重新核对账户状态和身份配置。
测试环境也应避免把同事或真实用户的个人邮箱、姓名和账号资料直接塞进演示数据。为自家产品创建独立测试账号，用虚构但格式有效的资料；如流程需要可读取邮件，再使用专门的测试收件方式。可先阅读 MXTemp 的隐私说明，了解服务相关的隐私信息，再决定测试数据如何隔离。
按证据缺口补测试，不要让一种工具包办
哪些验收目标需要再接入可读取的测试收件方式？ 只要验收要读取实际邮件内容、验证验证码、检查链接，或确认邮件在某个外部邮箱中的呈现，就需要可读取邮件的方式。模拟器事件覆盖的是事件路径；收件箱测试补的是内容与收件观察，两者不能互相替代。
测试收件箱也不是外部投递的万能证明。它可以让测试程序或人员读取邮件，但只有当邮件确实发送到目标外部服务商并能在该环境中观察时，才能支持该服务商收件体验的验收。若只是需要一次性查看邮件正文，可从 MXTemp 临时邮箱入口开始；如果要判断测试地址是否会暴露在页面或截图中，可参考 收件箱暴露检查。
上线前可用这份短清单收口：
- ✅ 要验证发送事件、退信、投诉或抑制处理：用 Amazon SES 邮件模拟器，并断言自家应用的处理结果。
- ✅ 要断言邮件正文、验证码、模板和链接：另用可读取的测试收件箱。
- ✅ 要确认外部邮箱是否接收、如何分类和展示：向真实目标收件环境发送测试邮件并检查结果。
- ❌ 不要用模拟成功事件代替真实收件验收，也不要用读到正文来证明所有外部服务商都会正常投递。
- ⚠️ 若测试涉及长期找回、需要回复或保存重要通信的账户，不要用临时邮箱代替正式邮箱。
若只是临时注册自家测试账号、试用功能或接收一次验证码，MXTemp 可作为补充收件方式：免注册、即开即用，也能避免把主邮箱地址交给临时测试流程。它不替代 Amazon SES 的事件模拟，也不适合银行、支付、政务或其他需要长期找回和持续收信的账户。