服务商可能接受你的月发送量，却在结账故障后限制突发流量。将发送合约与你的应用需要恢复的工作量进行对比。
什么是事务性邮件？
事务性邮件服务于收件人的交易或账户活动，例如收据或密码重置。邮件的目的决定其类别。收件人数量和自动触发并不能使促销内容变成事务性邮件。
你应该评估哪些方面？
对比你的应用所需的功能，然后在正式承诺之前测试故障路径。
- 送达能力与信誉工具。 你能否方便地使用 SPF、DKIM 和 DMARC 对域名进行身份验证？是否提供专用 IP，并有预热指导？
- API 和 SDK 质量。 API 文档是否完善，是否提供你所用编程语言的官方 SDK？
- SMTP 和 HTTP 两者皆有。 检查你的运行时支持哪种提交接口。已有的 SMTP 客户端可以使用中继；HTTP API 适合提交结构化请求的应用。
- 模板。 支持变量替换的服务端模板让你无需部署即可修改文案，并保持各邮件格式一致。
- Webhooks 与事件。 投递、打开、点击、退回和投诉的实时 webhook 事件能帮助你保持自身记录准确，并触发后续逻辑。
- 分析。 投递、退回和互动率的汇总视图，以及可搜索的日志，用于调查单条邮件。
- 退订处理。 服务商应自动抑制硬退回和投诉，使你的应用能停止被这些信号阻止的发送。了解退订列表的管理方式以及你是否可以查看它们。
- 可扩展性。 它能否在不需手动干预或意外限流的情况下处理你的峰值流量（产品发布、节假日高峰）？
- 定价。 了解计费模式（按条计费、阶梯计费、包含用量）以及超额费用的触发点。根据你的预期用量和高峰时段进行计算。
- 技术支持。 凌晨两点邮件停发时，你如何联系到真人，响应速度如何？检查你实际购买的方案所附带的支持级别。
- 合规性。 在正式签约前，确认服务商满足你的业务所受的数据处理和地区合规要求。
什么时候应该选择 SMTP 中继服务？
当你的应用已经能构建邮件消息并支持可配置的邮件服务器时，选择 SMTP 中继。当你需要结构化请求字段或存储模板时，选择 HTTP API。
对于 Bird，在选择接口之前先对比提交和恢复路径：
| 决策或故障场景 | SMTP 中继 | HTTP 邮件 API |
|---|---|---|
| 身份验证 | 用户名 bird，API 密钥作为密码，使用 emails 权限范围。在区域 SMTP 主机上使用 TLS。 | API 密钥放在 Authorization: Bearer 请求头中，使用 emails 权限范围。 |
| 提交回复 | 最终的 250 携带已入队的消息 ID。将其与应用事件一起保存。 | 202 携带已接受的消息 ID。将其与应用事件一起保存。 |
| 重试职责 | 你的应用或 SMTP 客户端负责提交重试。对同一逻辑消息复用 X-Bird-Idempotency-Key。 | 你的应用或 SDK 负责提交重试。对同一逻辑消息复用 Idempotency-Key。 |
| 过期处理 | 重试未发送的任务前，你的应用需检查其链接或验证码是否仍然有效。 | 在提交另一个请求前执行同样的检查。 |
| 吞吐量假设 | 并发连接限制与发送配额需分开检查。更多的连接并不意味着更高的发送速率。 | 使用响应中的速率限制请求头来控制 API 请求频率。请求速率和收件人数量是不同的指标。 |
| 事件证据 | 在入队回复之后跟踪收件人事件。Bird 会重试延迟投递。 | 在接受之后跟踪同样的收件人事件。Bird 会重试延迟投递。 |
| IP 池选择 | API 密钥的 SMTP 配置决定所用的 IP 池。未配置的密钥使用组织的默认池。 | 按次发送设置 ip_pool_id，或使用组织的默认池。 |
SMTP 中继指南提供连接设置和回复处理说明。HTTP 发送参考定义了 API 的请求和响应。两种接口使用相同的邮件管道，包括退订处理和签名。
传输接受意味着 Bird 已将消息入队。之后的 email.delivered 事件表示接收服务器已接受该消息。两者都不能证明邮件已进入收件箱或已被阅读。
在幂等性保留窗口之后仍需保留你自己的发送记录，因为后续重试可能会创建另一条消息。延迟投递已由 Bird 重试；再创建一次发送会重复仍在处理中的工作。
两种接口均可选用专用 IP。在通过专用池发送突发流量之前，请查看 IP 池与预热要求。
应该对比哪些已发布的功能？
检查每项功能背后的文档化接口。接收已解析的邮件、存储其内容以及暴露会话 API 是不同的功能。
| 服务商 | 提交方式 | 收件人证据 | 收发基础设施 |
|---|---|---|---|
| Bird | HTTP send 和 SMTP | 事件、消息日志和退订 | 邮箱与会话；专用 IP 池 |
| Amazon SES | SendEmail API 和 SMTP | 事件目标和账户退订列表 | 支持区域的接收规则；标准或托管专用 IP |
| SendGrid | Mail Send API 和 SMTP | Event Webhook 和 Email Activity | Inbound Parse webhook；IP pools |
| Mailgun | Messages API 和 SMTP | 投递事件和退回记录 | 转发或存储邮件的路由；IP pools |
| Postmark | Email API 和 SMTP | Webhooks 和流退订 | Inbound webhook；专用 IP 资格 |
| Resend | Email API 和 SMTP | Webhook 事件和 API 日志 | 接收内容和回复；托管专用 IP |
确认你要购买的方案的功能资格和数据保留期限。功能链接并不等同于吞吐量配额或恢复时间承诺。
对于存储内容，检查哪些正文、请求头、附件和事件记录仍可检索。对于数据驻留，获取已发布的存储和处理范围，包括例外情况。仅有区域端点并不能确立该合约。
月发送量达到一千万时有什么变化？
峰值流量和恢复能力决定所需的发送速率，仅凭月发送量无法确定。
以 30 天为一个月计算，一千万条单收件人消息平均约为每秒 3.86 条。10 分钟内突发 100,000 条消息则需要约每秒 167 条。需要将突发流量与月度配额分开评估。
在每秒 100 条新消息的速率下中断 10 分钟后，你的应用将积压 60,000 个未发送任务。如果新任务继续以每秒 100 条的速率产生，要在 20 分钟内清空积压，还需要额外每秒 50 条。因此恢复目标为每秒接受 150 条消息，且这还不包括重试或接收服务器延迟。
检查各服务商如何计算工作量。SES 配额按收件人计数，并按区域分别适用，包含滚动每日配额和接受速率。SES 还提醒实际接受速率可能低于账户的最大速率。
Resend 限制区分 API 请求速率和邮件发送量配额。Bird 的速率限制请求头报告有效的请求配额。在与场景中的收件人速率对比之前，先将你的批量大小换算为请求数。
如何测试故障恢复？
测试你的应用在提交失败或 webhook 处理器不可用后如何恢复。服务商的状态页提供故障上下文；你的消息记录确定哪些工作尚未完成。
| 服务商 | 已发布的限制或错误合约 | 官方状态 |
|---|---|---|
| Bird | 有效配额和重试请求头 | Bird status |
| Amazon SES | 发送配额 | AWS 服务健康状态 |
| SendGrid | API 速率限制 | SendGrid status |
| Mailgun | API 错误和速率限制合约 | Mailgun status |
| Postmark | API 响应和错误合约 | Postmark status |
| Resend | 用量限制 | Resend status |
暂停一个测试 worker，累积任务后在账户的有效限制内恢复发送。测量最早的合格任务等待了多长时间。已过期的重置任务需要走全新请求路径，而不是自动重放。
在恢复过程中保留每个业务事件标识符。在重试不确定的提交之前，验证服务商的去重发送合约。Postmark 没有幂等键功能的文档，因此其集成需要应用层保障。Bird 的已完成响应保留时间为三小时。超出该窗口的恢复需要你自己的事件记录。
将后续的收件人事件与已保存的消息 ID 进行匹配。接收服务器的接受并不能证明邮件已进入收件箱或已被阅读。事务性 API 生命周期解释了这些不同的结果。
价格对比应包含哪些内容？
对比你要购买的确切方案、计费周期和币种的已发布包含项。将发送量与其所需的基础设施和数据保留分开考虑。
| 服务商定价来源 | 需要根据你的工作负载检查的包含项 |
|---|---|
| Bird 定价 | 发送配额、超额费用、专用基础设施、内容保留和技术支持 |
| Amazon SES 定价 | 出站和入站用量、数据费用、专用 IP 和可选功能 |
| SendGrid 定价 | 方案用量、超额费用、专用 IP 资格、活动保留和技术支持 |
| Mailgun 定价 | 发送量、日志和消息保留、专用 IP 和技术支持 |
| Postmark 定价 | 发送配额、额外用量、保留选项和专用 IP 资格 |
| Resend 定价 | 发送和接收配额、超额费用、保留期限和专用 IP 资格 |
检查所报配额计数的是请求数、消息数还是收件人数。将排除的功能记录在方案旁，而不是假设它们已包含在内。Bird 的服务商对比提供了各产品的单独对比。
常见问题
事务性邮件和营销邮件有什么区别？
事务性邮件服务于交易或账户活动。营销邮件推广产品或投递订阅内容。邮件目的决定了两者的区别，即使两者都是自动发送的。
一个服务商能同时处理事务性邮件和营销邮件吗？
服务商可以同时支持两种工作流。需要分别检查类别策略、已验证的发送身份和 IP 池选择。共享基础设施仍可能使运营邮件受到营销流量的信誉问题影响。
我需要专用 IP 吗？
一开始不需要。在较低发送量下，共享 IP 池就足够了，还能省去 IP 预热的工作。当你的发送量足够大且稳定到能维持自身信誉时，专用 IP 才有意义。选择一个允许你从共享开始、在数据支持时迁移到专用的服务商。
Bird 的定位
你可以通过 SMTP 或 HTTP API 提交邮件。发布模板以实现内容复用。订阅收件人事件。在邮件日志中查看单条邮件。
将 IP 池的选择与消息类别分开。在更改发送量时遵循预热指南。使用运营检查清单测试去重处理和恢复。
如何做出最终选择？
- 将文档化的接口和收件人控制与你的应用需求进行匹配。
- 确认峰值流量和积压恢复场景下的有效配额。
- 根据已保存的消息记录和业务事件记录测试故障处理。
- 对比你要购买方案的已发布包含项、保留期限和技术支持。