Your account is ready.
" }' ``` 生产代码不要硬编码 API key。把密钥存放在 Secret Manager 或环境变量中，限制访问，定期轮换，并确保前端代码永远拿不到生产密钥。 ## 生产环境邮件 API 架构 生产集成不应该让每个 Controller 或 Route Handler 直接调用邮件服务商。 更可靠的做法是建立一个小型消息层： 1. 产品事件发生。 2. 应用把事件写入队列、任务或事件总线。 3. 邮件服务把事件映射到模板。 4. 邮件服务校验收件人同意、退订和抑制规则。 5. 邮件服务调用服务商 API。 6. 邮件服务记录服务商返回的 message ID。 7. Webhooks 稍后更新投递状态。 这样产品代码更干净，邮件失败也更容易隔离和排查。 建议记录这些内部字段： - `event_id` - `message_type` - `recipient_id` - `recipient_email` - `template_id` - `locale` - `provider` - `provider_message_id` - `idempotency_key` - `status` - `error_code` - `created_at` - `sent_at` - `delivered_at` 关键邮件要使用幂等键。一次网络超时不应该导致用户收到三封密码重置邮件。 ## 最佳邮件 API 对比 | 服务商 | 最适合 | 选择原因 | 提交前检查 | | --- | --- | --- | --- | | Brevo | 电商、CRM 和生命周期消息 | 事务性邮件能连接营销、CRM、SMS、WhatsApp、自动化和客户数据 | API 限制、模板模型、价格层、事件需求 | | SendGrid | 开发者主导的邮件项目 | 成熟 API 文档、SDK 生态和常见集成 | 支持层级、送达率服务、规模化价格 | | Mailgun | API 优先工程团队 | HTTP 发送、日志、路由、验证和送达率工具 | 各计划包含功能、日志留存和支持 | | Amazon SES | AWS 重度使用和高容量发送 | 按量计费基础设施模型和 AWS 集成 | 工程维护、送达率运营、监控和支持 | | Postmark | 事务性邮件优先团队 | Message streams、模板、入站处理和清晰工作流 | 价格层、事件留存、事务与营销分离 | 不要只按标题价格选择。邮件 API 成本还包括工程时间、送达率运营、数据建模、监控、支持和未来迁移风险。 ### Brevo Brevo 适合把事务性邮件放进更大的客户沟通系统中。 选择 Brevo 当你需要： - 事务性邮件加营销活动、CRM、自动化、SMS 或 WhatsApp。 - 电商数据触发生命周期消息。 - 营销和产品消息共享联系人档案。 - 非开发同事可以编辑模板和查看报告。 - 不想为每个渠道分别购买点状工具。 注意： - 区分营销邮件和事务性邮件配置。 - 明确模板由工程还是营销负责。 - 检查速率限制和计划约束。 - 设计联系人数据同步方式。 - 区分不同邮件类别的退订和抑制规则。 ### SendGrid SendGrid 适合希望使用成熟开发者邮件 API 的团队。 选择 SendGrid 当你需要： - 熟悉的邮件 API 和 SDK 生态。 - 事务性和营销邮件都来自同一服务商。 - 已经使用 Twilio 生态。 - 需要事件 Webhooks 和细粒度发送控制。 注意支持层级、模板环境管理，以及营销邮件和事务性邮件是否应共享账号结构。 ### Mailgun Mailgun 围绕开发者发送和 API 工作流设计。 选择 Mailgun 当： - 工程团队负责邮件基础设施。 - 需要 HTTP 发送、SMTP 回退、日志、入站路由和验证工具。 - 你希望服务商在送达率运营上提供明确能力。 注意验证、分析、送达率功能、数据留存和迁移支持是否包含在目标计划里。 ### Amazon SES Amazon SES 更像基础设施。 选择 SES 当： - 应用已经深度运行在 AWS 上。 - 团队有能力自己维护更多配置。 - 需要高容量、按量计费发送。 - 希望和 IAM、CloudWatch、SNS、Lambda 等 AWS 服务紧密结合。 SES 在规模化成本上很强，但并不总是最省心的选择。你需要自己处理沙盒解除、域名身份、退信与投诉、监控、告警、模板和支持流程。 ### Postmark Postmark 专注事务性邮件。 选择 Postmark 当： - 事务性可靠性和清晰度比一体化营销功能更重要。 - 你希望用 message streams 分离不同邮件类型。 - 需要模板、入站邮件和投递事件。 注意价格层、消息和事件留存时间，以及大批量营销是否应放在单独平台中。 ## 何时使用邮件 API ### 事务性邮件 - 账号验证 - Magic link 登录 - 密码重置 - 双因素认证 - 产品邀请 - [订单确认](https://tajo.io/zh-cn/blog/order-confirmation-email-guide/) - 付款收据 - 发货确认 - 退款通知 - 订阅续费 - 安全提醒 事务性邮件对可靠性要求很高。用户收不到登录链接、订单收据或密码重置时，会立刻感知到问题。 ### 产品生命周期邮件 生命周期邮件介于事务性和营销之间： - 试用期引导 - 功能激活 - 使用里程碑 - 升级提示 - 账号不活跃提醒 - 客户成功跟进 - 续费序列 - 赢回消息 这些邮件最好由产品数据触发，而不是只按日历群发。 ### 电商邮件 电商团队通常同时需要事务性和营销触发邮件： - 欢迎优惠 - 弃购挽回 - 浏览放弃提醒 - 到货提醒 - 降价提醒 - 商品推荐 - 补货提醒 - 忠诚度更新 - 评价请求 - VIP 早鸟权益 ### 营销邮件（通过API） - 事件驱动细分 - 个性化活动 - 触发式[滴灌序列](https://tajo.io/zh-cn/blog/drip-campaign-guide/) - 产品驱动引导 - 基于账号的生命周期旅程 - 与客户行为绑定的[自动化邮件](https://tajo.io/zh-cn/blog/automated-email-guide/) 合规要求仍然适用。营销邮件需要合适的同意、退订处理和抑制规则。 ## API的关键功能 ### 认证和密钥管理 严肃的邮件 API 必须支持安全 API key 和清晰认证文档。 运营要求： - 按环境分离密钥。 - 限制生产密钥访问。 - 定期轮换密钥。 - 密钥不进入代码仓库。 - 记录密钥使用，但不记录密钥值。 - 失败请求日志不得包含完整密钥。 ### 模板 模板让事务性邮件保持一致。 应重点查看： - 版本管理。 - 测试发送。 - 变量。 - 默认值。 - 多语言模板。 - 预览渲染。 - 审批流程。 - Staging 与 Production 模板隔离。 模板不只是设计资产。密码重置、订单确认和发票模板是产品契约的一部分，应像应用 UI 一样认真评审。 ### Webhooks Webhooks 把发送变成反馈闭环。 应追踪： - Accepted 或 queued。 - Deferred。 - Delivered。 - Opened，需谨慎解读。 - Clicked，需谨慎解读。 - Bounced。 - Dropped。 - Complained。 - Unsubscribed。 存储服务商 message ID，这样才能把 webhook 事件匹配回内部用户和业务事件。 ### 抑制管理 抑制处理保护送达率和合规。 系统应处理： - 硬退信。 - 投诉。 - 退订。 - 手动屏蔽。 - 无效联系人。 - 账号删除或隐私请求。 - 你的策略排除的角色邮箱。 不要因为产品代码只看到”发邮件任务”，就持续重试一个永久失败的地址。 ### 速率限制和吞吐量 检查服务商如何处理： - API 请求限制。 - 消息吞吐量。 - 批量端点。 - 峰值限制。 - 日或月计划上限。 - 新账号预热。 - 专用 IP 预热。 要为峰值做计划。产品发布、密码重置事故、黑五促销或安全通知，都可能让发送量远高于日常平均。 ### 分析和导出 最低报告应包含： - Sent。 - Delivered。 - Bounced。 - Deferred。 - Complaints。 - Unsubscribes。 - 模板表现。 - 服务商错误响应。 - 相关收入或转化事件。 谨慎解读打开率和点击率。隐私保护、图片屏蔽和安全机器人会扭曲互动指标。对事务性邮件来说，送达和用户完成动作通常比打开率更重要。 ### 入站解析 当用户会回复邮件或把内容发到产品中时，入站解析很重要。 常见场景： - 支持回复。 - Email-to-ticket。 - 回复评论。 - 审批流程。 - 转发财务票据。 - 入站线索捕获。 如果路线图里包含入站邮件，选服务商时要看文档、路由、安全控制和附件处理。 ## API的送达率 API 不会自动解决送达率。你仍然需要： - SPF。 - DKIM。 - DMARC。 - 已验证发信域名。 - 稳定的发件人身份。 - 干净名单。 - 退信处理。 - 投诉处理。 - 营销邮件清晰退订。 - 相关内容。 - 合理频率。 - 监控。 新域名或新 IP 要逐步预热。从低风险、高互动邮件开始，随着声誉稳定再提高发送量。 尽量分离邮件类型： - 认证和安全。 - 收据和订单更新。 - 产品生命周期。 - 营销。 - 大促群发。 不要让激进促销活动损害密码重置或订单收据的投递。 ## 错误处理和重试 邮件 API 失败要分类处理。 可以重试： - 超时。 - 临时服务商错误。 - 限速后延迟重试。 - 网络故障。 - 临时队列问题。 不要无限重试： - 无效收件人地址。 - API key 无权限。 - 模板 ID 无效。 - 缺少必填字段。 - 收件人已被抑制。 - 策略或合规拦截。 使用指数退避，并为多次失败的消息设置 dead-letter 队列。 每类关键邮件都应有运营路径： - 支持能否重新发送？ - 用户能否再次请求？ - 工程能否追踪事件？ - 是否能看到服务商响应？ - 是否能证明服务商已接受请求？ ## 邮件 API 实施清单 上线前检查： 1. 定义消息类型和负责人。 2. 选择 API 服务商和回退策略。 3. 验证发件域名。 4. 配置 SPF、DKIM 和 DMARC。 5. 创建 Staging 和 Production API key。 6. 安全存储密钥。 7. 构建消息服务或适配器。 8. 添加幂等键。 9. 添加结构化日志。 10. 构建重试和 dead-letter 行为。 11. 创建模板。 12. QA 个性化变量和默认值。 13. 配置 Webhooks。 14. 存储服务商 message ID。 15. 处理退信、投诉和退订。 16. 为支持团队提供重发和状态查询。 17. 监控错误率和送达率。 18. 记录速率限制和事故处理手册。 ## 服务商选择评分表 给每个服务商按 1 到 5 分打分： | 维度 | 权重 | 为什么重要 | | --- | --- | --- | | 送达率控制 | 5 | 邮件不到达，再便宜也昂贵 | | API 文档 | 5 | 开发者需要快速且正确实施 | | Webhooks | 5 | 产品团队需要投递和失败反馈 | | 抑制处理 | 5 | 保护合规和发件人声誉 | | 模板 | 4 | 减少产品与营销漂移 | | SDK | 3 | 加快在当前技术栈中集成 | | 价格模型 | 4 | 规模化成本可能变化很快 | | 支持 | 4 | 邮件事故直接影响客户 | | 数据留存 | 3 | 影响调试和支持 | | 入站解析 | 2 | 仅在回复型工作流中关键 | | 多渠道适配 | 3 | 当邮件连接 SMS、WhatsApp、CRM 或自动化时有用 | 很多团队的正确答案不是”最便宜的邮件 API”，而是能降低运营风险的服务商。 ## 常见错误 避免这些问题： - 从分散的业务代码直接发邮件。 - 在日志中记录 API key 或完整隐私数据 payload。 - 把所有错误都当临时错误重试。 - 不存服务商 message ID。 - 等支持团队问”邮件到底到了没有”时才想到 Webhooks。 - 把密码重置和大促营销放在同一声誉路径上。 - 所有语言共用一个模板。 - 忽略模板变量默认值。 - 把打开率当作送达或成功证明。 - 没有明确策略就让营销退订逻辑压制必要账号安全邮件。 - 只比较免费层。 - 未预热就直接上高发送量。 ## 入门步骤 新项目可以走一条最短但安全的路径： 1. 从一类事务性邮件开始，例如密码重置或订单确认。 2. 构建服务商适配器，不要让产品代码直接绑定某个供应商。 3. 添加域名认证。 4. 添加 Webhook 状态追踪。 5. 给支持团队提供可见性。 6. 加入模板和多语言支持。 7. 扩展到生命周期和电商自动化。 如果团队已经用 Brevo 做营销和 CRM，可以从 Brevo 事务性 API 开始，并梳理需要同步的事件数据。 如需SMTP设置，请参阅我们的[SMTP指南](https://tajo.io/zh-cn/blog/smtp-complete-guide/)和[免费SMTP服务器指南](https://tajo.io/zh-cn/blog/free-smtp-relay-guide/)。 ## Tajo 的定位 Tajo 是一款集成构建工具。构建集成，让智能体在其上运行，由它们来推动客户互动。Tajo 目前处于抢先体验阶段。 [申请抢先体验](https://tajo.io/zh-cn/#early-access) ## 常见问题 **什么是邮件 API？** 邮件 API 是一种 HTTP 接口，让应用程序可以从代码中发送和管理邮件。应用通过结构化请求传递收件人、模板、变量、元数据和认证信息，再由邮件平台负责排队、投递、事件回传和失败处理。 **我应该使用邮件 API 还是 SMTP？** 当你能控制应用代码，并且需要结构化错误、模板、元数据、Webhooks、重试或高容量事务性邮件时，优先使用邮件 API。当你在配置只支持 SMTP 的旧系统、WordPress 插件、服务器或第三方工具时，使用 SMTP。 **哪个邮件 API 最好？** 最佳选择取决于用例。Brevo 适合邮件连接 CRM、SMS、WhatsApp 和营销自动化的团队，SendGrid 与 Mailgun 适合开发者主导的发送团队，Amazon SES 适合 AWS 重度使用和高容量基础设施，Postmark 适合事务性邮件优先的团队。 ## 相关文章 ### [事务性邮件服务对比：API、SMTP、定价模式与服务商适配（2026）](https://tajo.io/zh-cn/blog/best-transactional-email-service/) 2026年3月26日 · 11 分钟阅读 9 个章节 ### [事务性邮件服务：如何选择合适的服务商](https://tajo.io/zh-cn/blog/transactional-email-service-guide/) 2026年3月26日 · 7 分钟阅读 8 个章节 ### [SMTP 完整指南：它是什么、如何工作与最佳实践](https://tajo.io/zh-cn/blog/smtp-complete-guide/) 2026年3月8日 · 12 分钟阅读 11 个章节