Email

事务性邮件有哪些最佳实践?

从已认证的身份发送事务性邮件,确保每个业务事件只发送一次,强制链接过期,并监控每个收件人的投递结果。

密码重置邮件必须在链接仍然有效时送达。收据邮件必须描述正确的订单,且不会在重试后重复出现。

这些要求从你的应用程序开始,并在邮件服务接受消息之后继续。

事务性邮件应该包含什么?

向收件人提供触发该邮件的事件所需的信息或操作。收据用来确认订单,重置邮件提供恢复访问权限的途径。

使用可识别的发件人名称。撰写能标识事件的主题行。当工作流需要支持时,将回复地址设为你的团队可以监控的邮箱。

对于示例收据,使用类似 Receipt for order 8472 的主题。包含订单编号、购买的商品和支持联系方式。对于重置邮件,将重置操作放在最前面,并注明过期时间。

测试 HTML 和纯文本内容。检查主要操作在窄屏设备和图片禁用状态下是否仍然可理解。

将促销内容与必要的账户消息分开。事务性邮件与营销邮件的区别解释了消息用途如何影响收件人控制和发送策略。

如何认证和区分发件人?

在生产流量之前认证发送域。Gmail 的发件人要求要求所有向个人 Gmail 账户发送邮件的发件人使用 SPF 或 DKIM。每天发送超过 5,000 封邮件的发件人还需要 SPF、DKIM 和 DMARC。

为运营邮件和营销邮件使用不同的发送身份。Yahoo 的指南建议通过 IP 或 DKIM 签名域将批量营销流量与事务性流量分开。两者都携带信誉信号,因此仅使用不同的 From 地址并不能分离基础设施。

逐步增加发送量。Google 的指南警告不要突然激增。在增量过程中检查延迟投递和退信,以便在接收方难以处理流量时降低发送速率。

送达能力检查清单涵盖了更广泛的认证和发件人信誉工作。

如何处理屏蔽和偏好设置?

在决定是否再次发送之前,先检查收件人被屏蔽的原因。营销退订和不可达地址需要不同的处理方式。

Bird 的类别策略允许在仅营销退订后发送事务性邮件。硬退信、手动屏蔽以及覆盖所有消息的退订会同时阻止两个类别。

因此,事务性类别并不会覆盖所有收件人限制。当 Bird 报告 recipient_suppressed 时,检查屏蔽记录和收件人的偏好设置。重复相同的发送不会修复地址或改变该策略。

重置链接和验证码应如何过期?

在验证链接或验证码的应用程序中强制执行过期。邮件中的文字无法阻止过期凭据被接受。

OWASP,应用安全社区,建议使用随机生成的重置令牌或验证码,并设置合理的过期时间。它还建议一次性使用。在成功使用后使凭据失效,这样同一封邮件就无法再次授权重置。

为账户操作选择一个有效期,并在邮件中展示该有效期。将应用程序中的等待时间和投递时间纳入考量。在过期后收到的邮件需要提供请求新重置的途径。

在重试未发送的重置任务之前,检查其凭据是否仍然有效。不要仅因为发送尝试失败就延长凭据的过期时间。否则重试可能使凭据的可用时间超出你设定的有效期。

对于重置 URL,OWASP 建议使用 HTTPS 和可信的目标域名。它还建议限制每个账户的重置请求次数,以防止收件箱被淹没。

重试如何避免重复发送?

保留业务事件及其发送操作的持久化记录。重复的订单事件应找到已有的收据任务,而不是创建新的。

在不确定的响应后重试同一个 API 请求时,使用相同的幂等键。Bird 的幂等性约定会保留已完成的响应三小时。超过该时间窗口后,使用相同键的另一个请求可能会创建另一条消息。

这个时间限制使你自己的事件记录在处理较早的重试时不可或缺。在将提交视为完成之前,将返回的消息 ID 保存到事件记录中。

投递延迟与不确定的 API 响应不同。Bird 会自动重试延迟投递。为每次延迟创建新的发送可能会在原始消息仍在处理中时产生重复消息。

应该监控什么并设置告警?

跟踪每条预期消息从提交到结果的全过程。记录每个收件人的投递结果。衡量用户是否完成了预期操作。

Bird 的投递事件区分接受、投递、延迟、退信和拒绝。投递表示接收服务器接受了消息,但不能确定是否进入了收件箱或已被阅读。

将业务事件时间与发送时间和收件人结果一起记录。对于重置邮件,将已过时间与凭据剩余有效期进行比较。在应用程序中衡量已完成的重置次数。打开追踪事件并不能证明收件人阅读了该消息。

围绕工作流的运行限制设置告警:

  • 未发送的任务即将过期。
  • 失败率超出正常范围。
  • Webhook 处理出现积压。

为每个告警指定一个能够采取行动的负责人。

故障需要检查的证据负责人和后续操作
订单事件后未发送应用程序任务和事件记录应用团队:恢复缺失的任务,避免重复已有的发送
收件人被屏蔽拒绝原因、屏蔽记录和偏好设置支持或发送团队:在再次尝试前调查屏蔽原因
投递延迟上升收件人事件和发送量发送团队:检查接收方响应并降低流量峰值
到达时重置已过期凭据过期时间和事件时间戳应用团队:调查延迟并提供重新请求的途径
重复的 webhook 投递Webhook 标识符和处理记录应用团队:跳过该事件已完成的工作

在接受事件之前验证 webhook 签名。Bird 的 webhook 指南使用 webhook-id 进行去重,这样重试的通知不会重复你的应用程序的工作。

通过 Bird 发送前应该检查什么?

在用于正式账户消息之前,测试从提交、收件人结果到应用恢复的完整工作流。

  1. 验证发送域。检查运营流量是否使用了预期的身份和发送池。
  2. 发布模板。使用有代表性的参数测试收据详情或重置操作。
  3. 为运营内容设置 category: "transactional"。应用文档中描述的屏蔽和偏好策略
  4. 保留业务事件记录和幂等键。保存发送端点返回的消息 ID。
  5. 使用邮件沙箱测试故障处理。其模拟的结果会通过正常的事件和 webhook 路径传递,不会到达真实的收件箱。
  6. 邮件日志中检查每个收件人的时间线。确认你的应用程序处理了相同的结果,并将告警路由到对应的负责人。

基于同一网络构建。

测试 API 密钥即刻获取。添加付款方式并验证发送者身份后,即可解锁生产环境。

从一个渠道开始。
准备好后,再添加其他渠道。

测试 API 密钥即刻可用。添加支付方式并验证发送者身份后,即可解锁生产环境。

正在使用 Claude Code、Cursor 或 Codex?复制一条设置提示,您的智能代理即可自动安装 Bird CLI 和相关技能。选择您的工具:

Cursor