密码重设、登录验证码、收据、退款确认，不能和 newsletter 用同一套判断标准。SaaS 事务邮件服务的核心不是「能发出去」，而是失败时你能不能在 5 分钟内知道：是模板渲染错、DNS 没对齐、收件人硬退信，还是邮箱服务商临时延迟。
我在 2026-05-24 比对了 Resend、Postmark、Amazon SES 的官方 pricing、域名认证和 webhook / event docs。下面的建议只覆盖出海 SaaS 的事务邮件，不覆盖 EDM 增长、冷邮件、营销自动化，也不把第三方 deliverability 测试里的百分比当成官方承诺。
先给结论：三家该怎么选？
| 场景 | 默认选择 | 为什么 |
|---|---|---|
| 密码重设、magic link、退款确认、发票收据 | Postmark | 起步价低，事务邮件定位清楚，45 天活动历史和事件 webhook 对客服排障更友好 |
| 早期 SaaS、Next.js、React Email 模板、开发体验优先 | Resend | API 和模板体验顺，Pro 档包含 50,000 封/月，适合工程侧快速上线 |
| 月发量几十万封以上、有 AWS 经验、愿意自己搭监控 | Amazon SES | $0.10 / 1,000 封的基础发信价很低，但运维面明显更重 |
| 多产品、多租户、多品牌发信 | SES 或 Resend Scale | SES 每 Region 可做大量 identities；Resend Scale 给到 1,000 个自定义域名 |
| 一个人维护、客服也要看日志 | Postmark | Postmark 的日志、活动历史、bounce / complaint 视图更接近客服工作台 |
这张表的底层逻辑很简单：关键邮件先买可观测性，量大以后再压单价。独立开发者最容易踩的坑，是在月发 3,000 封时为了省十几美元上 SES，然后忘了接 SNS、CloudWatch 和告警。
价格怎么算才不误判？
2026-05-24 官方价格里，三家的价格模型完全不同。
| 服务 | 免费/起步 | 常见付费档 | 超额或按量 | 价格判断 |
|---|---|---|---|---|
| Resend | Free 3,000 封/月，100 封/天 | Pro $20/月，50,000 封/月 | Pro 超额 $0.90 / 1,000 封 | 10k-50k 区间很舒服，但免费档有日发送限制 |
| Postmark | Free 100 封/月 | Basic $15/月，10,000 封/月 | Basic 超额 $1.80 / 1,000 封 | 起步账单低，适合关键邮件先上生产 |
| Amazon SES | 新 AWS 客户有 SES free tier 条件 | 无固定月费 | Outbound email $0.10 / 1,000 封，附件数据另计 | 单封最低，但 CloudWatch、SNS、专用 IP、VDM 都可能另算 |
如果你每月只发 2,000 封密码邮件，SES 的账单很好看，但这不是完整成本。你还要算生产权限申请、DNS 调试、bounce / complaint 处理、邮件事件落库、报警、客服查询页面。
如果你每月发 30,000 封，Resend Pro 的 50,000 封包含量会比 Postmark Basic + 超额更顺。反过来，如果你刚上线，只想给密码重设和退款确认找一个稳妥主通道，Postmark $15 起步比 Resend Pro 更轻。
SES 的优势通常在 100,000 封/月之后才明显。前提是团队已经用 AWS，不怕 IAM、SNS、CloudWatch、Region identity 这些组件。否则省下来的发信费，会被一次客户收不到退款邮件的人工处理吃掉。
域名认证和多域名怎么设计？
事务邮件建议从第一天就用子域，而不是直接拿根域名发所有邮件。常见拆法是：
| 子域 | 用途 | 是否推荐共用 |
|---|---|---|
auth.example.com | 登录验证码、magic link、密码重设 | 不和营销邮件共用 |
billing.example.com | 订阅、发票、退款确认 | 不和 newsletter 共用 |
notify.example.com | 产品通知、评论、团队邀请 | 可和低风险事务通知共用 |
news.example.com | newsletter、产品更新、活动 | 不和 auth / billing 共用 |
Resend 官方建议用 subdomain 隔离发送声誉，并要求验证 SPF、DKIM；DMARC 可作为额外信任层。Resend 免费档 1 个自定义域，Pro 10 个，Scale 1,000 个。
Postmark Basic 给 5 个 custom sending domains，Pro 给 10 个，Platform 不限。价格页同时列出 DKIM、SPF、DMARC authentication、automatic suppression、event webhooks 和 secure webhook endpoints。对一个小 SaaS 来说，5 个域名已经够把 auth、billing、notify、news 分开。
Amazon SES 的身份模型更灵活：验证 domain identity 后，子域和邮箱地址可以继承验证；同一域名如果要跨多个 AWS Region 发信，每个 Region 要单独创建和验证 identity。SES 的 Easy DKIM 会给 DNS 三条 CNAME，custom MAIL FROM 还涉及 MX 和 SPF 记录。
deliverability 看什么才有用？
不要只问「哪家送达率最高」。邮箱进入 inbox 还是 spam，受到域名历史、收件人互动、邮件内容、发信频率、退信率、投诉率、认证对齐和 IP 声誉共同影响。
更实用的检查表是这 6 项：
| 维度 | Resend | Postmark | Amazon SES |
|---|---|---|---|
| 发信身份隔离 | 支持多 custom domains，官方建议 subdomain | 支持多个 custom sending domains 和 Message Streams | identities、configuration sets、Region 级配置最灵活 |
| SPF / DKIM / DMARC | 定价页列出 DKIM、SPF、DMARC；域名页说明 SPF + DKIM，DMARC 可选增强 | 定价页列出 DKIM、SPF、DMARC authentication | DKIM、custom MAIL FROM SPF、DMARC alignment 都要自己配置清楚 |
| 退信/投诉处理 | webhook 有 bounced、complained、delivery_delayed、suppressed 等事件 | 有 bounce、delivery、spam complaint、open、click 等 webhook | 可用 SNS feedback notifications 或 event publishing |
| 日志保留 | 定价页显示 30 天 data retention | Basic / Pro 默认 45 天活动保留 | 取决于你把事件送到哪里，CloudWatch / Firehose / SNS 自己设计 |
| 事件重试 | webhook 非 200 会按官方重试节奏重试 | 不同 webhook 有不同重试节奏，403 会停止重试 | SNS / event publishing 由 AWS 组件承担，配置面更散 |
| 运维负担 | 低 | 低到中 | 中到高 |
Postmark 不是因为「一定比所有服务送达率高」才适合关键邮件，而是因为它把事务邮件、活动历史、bounce / complaint、webhook 和客服排障放在一个较完整的产品面里。密码重设失败时，你不想先问工程「CloudWatch metric 在哪个 namespace」。
Resend 的长处是工程体验。React Email、SDK、webhook、本地开发都更顺，适合前端工程主导的 SaaS。它的风险是别把开发体验等同于交付保障：上线后仍要接 bounced、complained、delivery_delayed、failed、suppressed 事件。
SES 的长处是低价和 AWS 生态。它的风险是可观测性默认不会替你变成产品后台：事件可以发到 CloudWatch、Data Firehose 或 SNS，但你要自己把这些数据变成告警、客服查询和用户状态处理。
密码重设和退款邮件有什么特别风险？
密码重设邮件失败，用户会重复点击，短时间内打出多封相同邮件。这里要做两件事：限制同一邮箱的发送频率，并把最新 token 失效逻辑写清楚。邮件服务只负责发送，你的应用要负责避免旧链接还能继续用。
退款通知邮件失败，问题更麻烦。支付系统可能已经完成 refund，用户却没收到确认；客服如果只能看到「已调用 send API」，无法判断邮件是否 delivered、bounced、complained 或 suppressed。
所以 billing 邮件要单独接事件。建议至少保存这些字段：
| 字段 | 用途 |
|---|---|
provider_message_id | 关联 Resend / Postmark / SES 的消息记录 |
category | 区分 password_reset、refund_notice、invoice_receipt |
sent_at / delivered_at | 判断是未发出、延迟还是已交给收件方服务器 |
bounce_type | 区分永久退信、临时失败、suppression |
complaint_at | 用户投诉后停止继续发同类邮件 |
payment_event_id | 把 Stripe / MoR 的退款事件和邮件事件串起来 |
如果你已经在用 Stripe、Paddle、Lemon Squeezy 或 Creem，退款状态以支付系统为准，邮件只做通知和凭证。不要把「邮件发送成功」当成「退款完成」。
webhook 和事件回调该怎么落库？
Resend webhook 文档明确要求你的 endpoint 返回 200，并提醒事件可能至少送达一次、顺序不保证。Postmark webhook 也会在非 200 时重试，且不同事件的重试节奏不同。SES 则通过 feedback notifications 或 event publishing 把 delivery、bounce、complaint、open、click 等事件送到 SNS、CloudWatch 或 Data Firehose。
生产落库不要用「收到一个事件就覆盖状态」。更稳的写法是追加事件表：
| 表 | 关键字段 | 说明 |
|---|---|---|
email_messages | provider、message_id、to、category、status | 每封业务邮件一行 |
email_events | message_id、event_type、event_at、raw_payload_hash | webhook / SNS 事件追加写入 |
email_suppressions | email、reason、source、created_at | 永久退信和投诉后停止发送 |
状态可以由事件表计算出来：sent < delivered < opened 不是严格顺序，因为 open 可能先于 delivered webhook 到达。对密码重设来说，真正重要的是 bounced、failed、suppressed、delivery_delayed。
谁该选哪个？
一个人做 SaaS，默认 Postmark。理由不是它最便宜，而是密码、退款、发票这类邮件出问题时，Postmark 更像一个事务邮件控制台。你能比较快看到活动历史、退信和投诉。
前端工程强、模板变化快、想用 React Email，默认 Resend。尤其是早期产品，welcome、trial ending、team invite、invoice reminder 都在代码仓库里管理时，Resend 的开发体验会省时间。
已经有 AWS 运维能力，月发量很高，默认 SES。这里的「有能力」不是会点控制台，而是知道怎么申请生产权限、拆 Region、接 SNS、做 CloudWatch alarm、处理 bounce / complaint，并且有人定期看声誉指标。
公司后台、DNS、支付系统、邮件服务和 GitHub Actions 常常一起出问题：不是服务坏了，而是你在异地办公时登录控制台、查 webhook、改 DNS 的链路不稳定。需要同时维护 Stripe、Cloudflare、Postmark / Resend / AWS 控制台时，可以把核心后台放在独立开发者出海稳定专线里，至少别让排障时的登录环境成为第二个变量。
三者对比不覆盖什么
没有测试三家在 Gmail、Outlook、Yahoo 的真实 inbox placement，因为这和你的域名历史、内容、发信节奏和收件人行为有关，不能用一组公开百分比替代自己的种子邮箱测试。
没有覆盖冷邮件、营销群发和 newsletter 自动化。事务邮件最关心的是账户、付款、权限和安全通知；营销邮件要看退订、分群、自动化和内容策略，是另一套选型。
没有承诺任何服务能保证密码邮件或退款邮件进 inbox。生产上只能降低风险：认证对齐、子域隔离、事件回调、退信处理、客服可查、告警可达。