邮件发送方案对比
SaaS 产品几乎一定会用到邮件：注册验证、登录验证码、找回密码、订单通知、发票、订阅提醒、系统告警、产品更新、营销活动。
很多人一开始只关心“怎么把邮件发出去”，但真正上线后，更重要的问题是：能不能送达，能不能追踪，能不能区分交易邮件和营销邮件，能不能处理退信和投诉。
邮件发送方案不是随便接一个 SMTP 就结束。它关系到用户登录、支付通知、账号安全和产品留存。
本文参考了几类常见邮件服务官方资料：
- Resend Email API
- Postmark Developer Documentation
- Amazon SES Documentation
- Amazon SES email authentication methods
- SendGrid Email API
- Mailgun Webhooks
先区分交易邮件和营销邮件
邮件大致可以分成两类：交易邮件和营销邮件。
交易邮件是由用户动作触发的必要邮件，比如注册验证、找回密码、订单收据、发票、支付失败、团队邀请、系统告警。
营销邮件是主动触达，比如产品更新、活动通知、促销、newsletter、用户召回。
这两类邮件最好分开发送。原因很简单：交易邮件必须尽快送达，不能被营销邮件的退订、投诉、低打开率拖累。
Postmark 的 Message Streams 就强调把不同类型邮件流量分开管理。即使你不用 Postmark，也应该采用类似思路：交易和营销分域名、分通道、分模板、分监控。
SMTP 还是 API
邮件服务通常支持 SMTP 和 API 两种方式。
SMTP 更通用，几乎所有语言和框架都能接；API 更现代，通常更容易传模板变量、元数据、标签、幂等键和追踪字段。
如果你只是给旧系统接一个发送通道，SMTP 很方便。如果你在做新的 SaaS，优先考虑 API。
API 的好处是：错误结构更清楚，日志更完整，模板能力更好，Webhook 和事件追踪更容易关联到业务对象。
对独立开发者来说，API 通常更省心。
Resend：适合开发者快速接入
Resend 的定位很清晰：面向开发者的现代 Email API。
它的优势是接入体验简单，API 文档友好，适合 Next.js、React Email、现代全栈项目。对独立开发者来说，如果你想快速把验证码、邀请邮件、通知邮件跑起来，Resend 是很顺手的选择。
Resend 官方资料也提到可以用幂等键避免重复请求导致重复发送，这对重试逻辑很有价值。
适合场景：
独立开发者
现代 Web SaaS
交易邮件为主
希望开发体验简单
希望快速上线
需要注意的是：不要只看 API 简单，还要配置好发信域名、DKIM、SPF、DMARC 和退信处理。
Postmark：适合重视交易邮件送达
Postmark 长期以交易邮件稳定性和送达表现著称。
它的官方文档把 Transactional Message Streams 定义为由用户动作触发的一对一邮件，例如欢迎邮件、找回密码、订单确认。这非常符合 SaaS 的核心邮件需求。
如果你的产品非常依赖注册验证、登录验证码、支付收据、重要通知，Postmark 是很稳的选择。
适合场景：
交易邮件非常关键
希望交易和营销流量分开
重视单封邮件状态追踪
需要清楚的投递日志
它不一定是最低成本方案，但对“关键邮件不能丢”的产品很有价值。
Amazon SES：适合低成本和规模化
Amazon SES 的优势是成本低、可扩展、适合已经在 AWS 生态里的团队。
官方文档说明，Amazon SES 可以用于发送营销、通知和交易邮件，也支持 SPF、DKIM 等邮件认证方式。
如果你发送量很大，或者已经使用 AWS，SES 是很有吸引力的方案。
适合场景：
发送量较大
团队熟悉 AWS
希望控制成本
愿意自己处理更多配置和监控
需要和 AWS 生态集成
它的缺点是接入和运维相对更工程化。域名认证、生产权限、退信投诉处理、发送信誉、监控告警，都需要认真配置。
独立开发者如果想省事，SES 未必是最省心的第一选择。
SendGrid：适合综合型邮件能力
SendGrid 是老牌邮件平台，支持 Email API、模板、发送统计、联系人和营销相关能力。
官方资料强调它的 Email API、动态模板、实时验证和送达洞察等能力。
如果你的产品既有交易邮件，又有营销邮件、模板管理、运营邮件需求，SendGrid 属于综合型方案。
适合场景：
既要交易邮件又要营销邮件
需要模板和运营协作
希望使用成熟平台
需要较完整的统计和工具
需要注意的是，交易邮件和营销邮件仍然要分开管理，不要把所有邮件都混在一个发送流里。
Mailgun：适合 API、Webhook 和技术团队
Mailgun 也是面向开发者的邮件 API 平台，支持 API、SMTP、日志、路由和 Webhook。
Mailgun 官方 Webhooks 文档说明，应用可以通过 Webhook 在接近实时的方式接收账户事件，例如投递、失败、投诉等。
如果你希望邮件系统和自己的业务系统深度集成，尤其重视事件回传和自动化处理，Mailgun 是一个成熟选择。
适合场景：
技术团队接入
需要 API 和 Webhook
需要处理投递、退信、投诉事件
需要较强的邮件基础设施能力
同样，配置域名认证和监控非常重要。
不建议自己搭邮件服务器
早期 SaaS 不建议自己搭邮件服务器。
邮件送达不是把 SMTP 服务跑起来就行。你要处理 IP 信誉、域名信誉、黑名单、退信、投诉、SPF、DKIM、DMARC、TLS、队列、重试、退订、合规。
这不是独立开发者早期应该投入大量时间的方向。
除非你有非常特殊的合规或基础设施需求，否则优先使用成熟邮件服务。
选择时看这几个维度
你可以用下面维度评估邮件服务：
交易邮件送达是否可靠
API 是否好用
是否支持模板
是否支持 Webhook
是否能追踪投递、打开、退信、投诉
域名认证是否清楚
是否支持交易和营销分离
成本是否适合你的发送量
是否容易迁移
是否有足够好的日志和排查能力
不要只看价格。找回密码邮件进垃圾箱，可能比多花一点服务费更贵。
一个独立开发默认建议
如果你不知道怎么选，可以按下面方式：
想最快接入：Resend
最重视交易邮件稳定：Postmark
发送量大、成本敏感、熟悉 AWS：Amazon SES
需要综合营销和模板能力：SendGrid
需要成熟 API 和 Webhook：Mailgun
不建议：早期自建邮件服务器
这不是绝对答案，但足够应对大多数早期 SaaS。
写在最后
邮件系统不是边角功能。它关系到登录、安全、支付、通知和用户信任。
早期选择邮件方案时，优先考虑交易邮件送达、域名认证、日志追踪、Webhook 和后续迁移，而不是只看“谁最便宜”。
下一篇，我们继续聊文件能力：文件上传系统。
正文到此结束
热门推荐
相关文章
Loading...
![[HBLOG]公众号](https://www.harries.blog/img/qrcode_gzh.jpg)
