邮件 API 完整指南：如何在应用中通过程序发送邮件（2026）

邮件 API 让应用程序可以通过 HTTP 请求发送邮件。表面上它只是一个接口，实际会影响产品可靠性、送达率、工程流程、分析、合规、客户体验和支持排障。

如果你要发送注册验证、密码重置、订单确认、试用引导、发票、弃购提醒或生命周期邮件，邮件 API 通常比直接配置 SMTP 更适合现代应用。

快速答案

当邮件由应用事件触发时，优先使用邮件 API：

• 注册验证
• 密码重置
• Magic link 登录
• 订单确认
• 发货通知
• 发票或收据
• 产品邀请
• 试用期引导
• 使用量提醒
• 付款失败通知
• 续费提醒
• 基于产品行为的生命周期自动化

当发送系统只支持 SMTP 凭据，或者你正在配置旧应用、WordPress 插件、服务器、CRM 插件或内部工具时，使用 SMTP。

邮件 API vs SMTP

API 和 SMTP 都能发邮件，区别在于你的应用如何把邮件交给发送平台。

SMTP 是长期存在的邮件传输协议。它兼容性强，适合只接受主机、端口、用户名和密码的系统。

邮件 API 是 HTTP 接口。应用把认证、收件人、内容、模板变量、元数据、批量发送信息或计划发送信息放进请求里，平台返回结构化结果。

实用规则很简单：如果你拥有应用代码，从 API 开始。如果你配置的是只支持 SMTP 的第三方系统，用 SMTP。

邮件 API 如何工作

一个基础发送流程通常包含 7 步：

1. 应用产生事件，例如 user_signed_up 或 order_paid。
2. 应用选择消息类型。
3. 应用加载收件人、发件人、模板和个性化数据。
4. 应用向邮件服务商发送带认证的 HTTP 请求。
5. 服务商验证请求并把邮件加入发送队列。
6. 服务商返回成功、失败或消息 ID。
7. Webhooks 把投递、退信、点击、投诉或退订事件回传到你的系统。

API 请求只是其中一块。可靠实现还需要幂等、重试、日志、抑制列表、告警和数据治理。

快速入门：通过 Brevo API 发送邮件

Brevo 的事务性邮件 API 使用 /v3/smtp/email 端点。具体 SDK 和字段名可能随时间调整，实施时应以服务商 API 文档为准。

curl --request POST \
  --url https://api.brevo.com/v3/smtp/email \
  --header 'api-key: YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --data '{
    "sender": {
      "name": "Your App",
      "email": "[email protected]"
    },
    "to": [
      {
        "email": "[email protected]",
        "name": "Customer"
      }
    ],
    "subject": "Welcome to your account",
    "htmlContent": "<h1>Welcome</h1><p>Your account is ready.</p>"
  }'

生产代码不要硬编码 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 对比

不要只按标题价格选择。邮件 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 分离不同邮件类型。
• 需要模板、入站邮件和投递事件。

注意价格层、消息和事件留存时间，以及大批量营销是否应放在单独平台中。

Tajo

Tajo 适用于邮件发送与电商、客户事件和 Brevo 自动化绑定的场景。

使用 Tajo 当：

• 产品和电商事件需要进入 Brevo。
• Shopify 数据要触发弃购、订单、复购和生命周期消息。
• 你需要一个统一层同步客户、订单、商品和事件数据。
• 你希望事务性路径与更大的客户数据模型保持一致。

Tajo 不替代服务商 API 文档，它减少的是把正确客户和事件数据送进消息系统的集成工作。

何时使用邮件 API

事务性邮件

• 账号验证
• Magic link 登录
• 密码重置
• 双因素认证
• 产品邀请
• 订单确认
• 付款收据
• 发货确认
• 退款通知
• 订阅续费
• 安全提醒

事务性邮件对可靠性要求很高。用户收不到登录链接、订单收据或密码重置时，会立刻感知到问题。

产品生命周期邮件

生命周期邮件介于事务性和营销之间：

• 试用期引导
• 功能激活
• 使用里程碑
• 升级提示
• 账号不活跃提醒
• 客户成功跟进
• 续费序列
• 赢回消息

这些邮件最好由产品数据触发，而不是只按日历群发。

电商邮件

电商团队通常同时需要事务性和营销触发邮件：

• 欢迎优惠
• 弃购挽回
• 浏览放弃提醒
• 到货提醒
• 降价提醒
• 商品推荐
• 补货提醒
• 忠诚度更新
• 评价请求
• VIP 早鸟权益

对于 Shopify 和 Brevo 团队，Tajo 可以连接订单、客户、同意、商品和购物车数据，让这些消息基于真实商业行为触发。

营销邮件（通过API）

• 事件驱动细分
• 个性化活动
• 触发式滴灌序列
• 产品驱动引导
• 基于账号的生命周期旅程
• 与客户行为绑定的自动化邮件

合规要求仍然适用。营销邮件需要合适的同意、退订处理和抑制规则。

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 分打分：

很多团队的正确答案不是”最便宜的邮件 API”，而是能降低运营风险的服务商。

常见错误

避免这些问题：

• 从分散的业务代码直接发邮件。
• 在日志中记录 API key 或完整隐私数据 payload。
• 把所有错误都当临时错误重试。
• 不存服务商 message ID。
• 等支持团队问”邮件到底到了没有”时才想到 Webhooks。
• 把密码重置和大促营销放在同一声誉路径上。
• 所有语言共用一个模板。
• 忽略模板变量默认值。
• 把打开率当作送达或成功证明。
• 没有明确策略就让营销退订逻辑压制必要账号安全邮件。
• 只比较免费层。
• 未预热就直接上高发送量。

入门步骤

新项目可以走一条最短但安全的路径：

1. 从一类事务性邮件开始，例如密码重置或订单确认。
2. 构建服务商适配器，不要让产品代码直接绑定某个供应商。
3. 添加域名认证。
4. 添加 Webhook 状态追踪。
5. 给支持团队提供可见性。
6. 加入模板和多语言支持。
7. 扩展到生命周期和电商自动化。

如果团队已经用 Brevo 做营销和 CRM，可以从 Brevo 事务性 API 开始，并梳理需要同步的事件数据。如果产品需要把电商数据写入 Brevo，可以用 Tajo 连接客户、同意、商品、购物车和订单事件，再扩展更多生命周期消息。

如需SMTP设置，请参阅我们的SMTP指南和免费SMTP服务器指南。

相关文章

• Transactional email service guide
• Transactional email examples
• SMTP complete guide
• SPF, DKIM, and DMARC
• Email automation guide
• Brevo Shopify integration