Resend email 评测：接入、定价与上线前要想清楚的限制

Resend 适合希望快速把注册通知、收据和密码重置邮件接入应用的小型产品团队。选择 Resend email，主要看中的是开发流程省事；真正上线后，发送是否可靠仍由团队负责：免费方案每天最多发送 100 封，因配额不足而被拒绝的邮件也要由应用处理。方案要按高峰需求选，服务商则要结合数据要求来定。

本文于 2026 年 11 月 13 日对照 Resend 当时的定价、文档及安全页面核实。评估依据是文档中的工作流程、限制和费用计算，不代表已登录实测，也未测量邮件进入收件箱的比例。

Resend email 平台能做什么？

Resend 是应用通过 API（程序接口）或 SMTP（标准邮件发送协议）调用的邮件投递服务。它可以发送由事件触发的单封邮件和营销群发 Broadcasts，管理联系人与模板，报告投递事件，也能接收来信供应用处理。不过，谁该收到收据、密码重置请求是否有效、发送失败后怎么办，仍由产品本身决定。入门文档介绍了发送方式及支持的语言集成。

哪些团队适合用 Resend，哪些应该跳过？

如果创始人和开发者希望像管理其他应用服务一样管理邮件——为模板做版本控制、传入事件数据、发送邮件、处理结果——Resend 很合适。最典型的场景是小型 SaaS 产品，由同一批人负责应用和事务邮件。

选型应围绕接入成本、失败处理、营销负责人和数据约束展开，而不是依据未经证实的“某家服务商更容易进收件箱”之类说法。

如果现有服务商运行正常，又说不清 Resend 能解决什么问题，就不必迁移。 API 更清爽，本身不足以成为迁移成熟邮件业务的理由。需要独立发送基础设施时，应把 Postmark 列入候选；希望团队继续在 AWS 内掌握邮件系统时，则应考虑 Amazon SES。

如果日常用户引导流程由营销人员负责，可以对比以 SaaS 生命周期邮件为核心的 Loops。Resend 现在也有 Automations，因此应比较实际负责人需要维护的用户旅程，而不是沿用“Resend 只能通过 API 发邮件”的过时印象。

Resend 替代方案：各自适合什么情况？

**Twilio SendGrid：**如果现有 Email API、SMTP 和 Marketing Campaigns 已满足需求，可以优先保留。只有维护现状的成本高于某项明确的迁移收益，迁移才有意义。

**Postmark：**当事务邮件与群发邮件的流量隔离是决定性要求时，优先考虑它。Message Streams 文档介绍了独立的 IP 基础设施。这是具体的架构差异，不代表它承诺能让你的域名获得更好的投递结果。

**Mailgun：**如果需求除了发送，还包括邮箱地址验证和路由，值得列入候选。对这类买家来说，附加工具比发送调用的语法是否顺手更重要。

**Amazon SES：**如果工程团队已经负责 AWS 运维，并希望在这个环境中构建邮件能力，可以优先考虑。比较时要算上完整实施成本，包括监控和故障处理。

**Loops：**如果采购首先考虑的是由 SaaS 生命周期运营人员负责的新用户引导、激活和召回流程，可以优先考虑它。决定前，先在两个产品中演示同一条用户旅程。

如果要选择范围更广的营销活动平台，可以参考 GetResponse 评测。那与为应用挑选邮件传输服务，是不同的采购问题。

Resend 邮件 API：从产品事件到一封邮件

Resend 最突出的能力，是缩短应用事件到模板邮件之间的路径。Node.js SDK 接收发件人、收件人、主题和内容，返回包含数据或错误的结果。文档还提供 Python、PHP、Ruby、Go、Rust、Java 和 .NET 的快速入门；使用这项服务并不要求采用 React。

以支付成功后发送收据为例：应用先记录付款，准备收据数据，请求 Resend 发送，再把返回的邮件标识符关联到这笔付款。这样，客服调查收据问题时，就不必只靠客户姓名搜索。Node.js 快速入门展示了底层发送操作。

邮件模板怎么选？先确定谁负责文案

React Email 让开发者用 React 组件构建邮件内容。Resend 同时支持由代码管理的邮件和托管模板；其 React Email 集成指南介绍了本地预览、HTML 或纯文本输出，以及上传到托管 Templates 的方法。

对于收据，如果版式修改应经过应用的代码评审，就把版式留在代码里。如果非工程人员需要修改收据措辞，托管模板可能更适合划分职责：应用提供变量，内容负责人编辑邮件。Templates 文档介绍了编辑器、版本历史和通过已发布模板 ID 发送邮件的方式。

两种做法的价值，都在于让每项修改有明确负责人。但无论用哪一种，都不能仅凭预览就批准密码重置邮件上线。发布前，要在客户实际使用的邮件客户端中验证链接、过期行为和内容。

重试请求要有稳定标识

Resend 支持幂等键：重复发送请求使用同一标识符时，会返回原来的结果，而不是再发一封。文档规定的保护期为 24 小时。在收据流程中，应从收据事件生成幂等键，并在重试时保持请求内容一致。幂等指南说明了有效期，以及同一键搭配不同请求内容时会出现的错误。

应用必须尊重这段有效期。任务在保护期结束后重新执行时，需要靠自己的持久记录判断是否已请求过发送收据。服务商去重能保护重试过程，但不能代替永久的业务事件历史。

用 SMTP 迁移现有应用更省事

Resend 也适合已经通过 SMTP 发邮件的应用。SMTP 设置规定服务器为 smtp.resend.com，用户名为 resend，密码使用 API 密钥。端口 465 使用隐式 TLS，587 使用 STARTTLS。邮件客户端或框架中的加密选项必须与之对应。

这样可以保留现有邮件生成代码，只替换传输服务。但诊断能力有明确取舍：Resend 表示不提供 SMTP 服务器日志，虽然通过 SMTP 发出的邮件会出现在 Emails 列表里。如果经常需要排查连接层问题，迁移前就要考虑这一点。

域名配置：把身份验证纳入上线流程

Resend 要求验证发件域名，这项配置应和 API 接入一起列入上线清单。域名记录发布在 DNS 中，也是在那里授权 Resend 代表你发信。

SPF 用于声明获准发送邮件的基础设施；DKIM 为邮件添加加密签名；DMARC 则告诉收件系统，邮件未通过域名身份验证策略时该如何处理。三者职责不同，域名验证显示通过，并不意味着可以省略有针对性的 DMARC 配置。

新 SaaS 产品可以按以下流程配置：

1. 1

   选择发件地址和发送区域

   在 Resend 的 Domains 页面添加域名。新发件人可使用用途明确的子域名，例如 account.example.com，并根据收件人选择合适的发送区域。

2. 2

   发布系统生成的记录

   把 Resend 提供的 DKIM 和 SPF 配置原样复制到 DNS 服务商处。接入面向客户的发送流程前，先完成域名验证，不要拿教程里的通用记录替代。

3. 3

   添加 DMARC，并区分发送用途

   验证后配置 DMARC。可考虑为营销邮件使用独立子域名，以便分别管理新闻简报和事务邮件的设置。

4. 4

   迁移时保留已有信誉

   如果已有长期使用的发件地址，迁移计划应考虑它积累的历史。Resend 建议保留已有稳定历史的地址，不要一律替换成新子域名。

域名配置指南给出了操作顺序；已验证域名说明解释了迁移时的例外和独立的跟踪设置。密码重置邮件应优先使用简洁的直达链接，不必因为有点击跟踪开关，就跟踪每次点击。

投递事件与收件：让邮件流程形成闭环

发送请求之后，Resend 还会继续向应用提供信息，客户说没收到收据时，这些信息尤其有用。Webhook 是事件发生时发给应用的 HTTPS 通知。Webhook 指南介绍了投递、退信、打开和点击事件，以及请求验证、重放和把事件数据存入自有数据库的方法。

在收据流程中，要验证 Webhook 请求，把每个事件关联到已保存的邮件标识符，并确保重复处理事件不会出问题。退信应转化为客服可以跟进的状态，而不是淹没在无人查看的日志里。如果历史记录需要保留得比服务商的保留期更久，就存到自己的系统中。

“已投递”不等于用户在收件箱里看到了邮件。 Resend 将此状态定义为邮件已送达收件人的邮件服务器。邮件管理文档区分了已投递、退信、延迟、失败和被抑制等状态。向客户解释故障时，应使用这些准确区分。

送达率工具能辅助诊断，不能证明进箱比例

Resend 的 Deliverability Insights会检查链接域名不匹配、缺少 DMARC、缺少纯文本内容等问题。这些检查有助于改进可控的邮件内容，但不能据此得出收件箱到达率。

抑制列表还会阻止向硬退信或投诉过的地址继续发送邮件。关键在于，抑制在团队范围内生效：地址一旦进入列表，该团队各域名和子域名的事务邮件、Broadcast 邮件都会跳过它。抑制机制文档还指出，Gmail/Google Workspace 不会返回投诉事件。

如果营销邮件和事务邮件共用这套系统，实际影响是：把被抑制的收件人换到另一个发送子域名，也不能恢复向其发送密码重置邮件。应调查抑制原因，并提供账号恢复路径，不要直接移除抑制后盲目重发。

Resend 也支持接收邮件

Resend 支持通过已验证域名或其托管的 resend.app 子域名接收邮件。收件指南介绍了 Webhook 通知、获取邮件正文与附件、转发和串联对话回复。

例如，客户回复订单收据后，可以把来信关联到订单，获取正文，再创建客服任务。收件基础设施让你不必自己运营邮件接收系统，但附件如何处理、如何判断发件人可信度、来信可以触发哪些产品变更，仍由你负责。

Broadcasts 与联系人：明确营销邮件的发送意图

Resend 能满足小团队发送新闻简报和产品公告的需求，无须开发者从头搭建营销发送工具。Broadcasts 提供编辑器、定时发送、联系人定向和效果跟踪。Broadcasts 指南介绍了控制台与 API 两种操作流程。

发送功能公告时，先导入或添加已同意接收的联系人，把目标收件人放入 Segment，选择合适的 Topic，准备邮件，检查退订行为，再安排 Broadcast 发送。Segment 是内部的联系人分组；Topic 是收件人可以自行控制的订阅偏好。

如果旧集成还在使用 Audiences，需要更新原有理解。Resend 现在使用全局 Contacts 和 Segments：同一个邮箱地址可属于多个分组，但只计为一个 Contact。Audiences 迁移指南表示 Audiences API 已弃用。如果旧代码把退订视为仅对某个受众列表生效，这项变化就很重要。

Resend 还提供 Automations，支持自定义触发器、条件、延迟和等待事件步骤。因此，欢迎邮件序列可以放在 Resend 中运行，不必全部写进应用代码。不过，在迁移生命周期营销流程之前，应梳理真实的触发和退出条件：能画出一条序列，并不能决定谁来维护它。

Resend 定价：正式上线通常从 Pro 起步

Resend 入门级 Pro 方案为每月 $20，包含 50,000 封邮件，无每日邮件上限，可使用 10 个域名。Free 提供每月 3,000 封、每天最多 100 封，以及 3 个域名。每日限制往往比月额度更早成为问题：假设上线当天有 60 人注册，每人发送两封邮件，当天就需要发送 120 封。定价页面还列出 Scale 方案，起价为每月 $90、包含 100,000 封邮件，以及定制定价的 Enterprise 方案。

邮件 API 费用：先比较额度档位，再考虑超额计费

如果用满包含的额度，入门级 Pro 相当于每 1,000 封 $0.40，计算方式为 $20 除以 50,000，再乘以 1,000。如果实际只用了 5,000 封，同样的订阅费就相当于每 1,000 封 $4。这是在计算额度使用成本，不是每封成功进入收件箱的价格。

服务商的机器可读定价表还列出了 $35、包含 100,000 封邮件的 Pro 档位。达到这一发送量时，如果继续使用入门级 Pro 并开启超额计费，费用将是 $20 + 50 × $0.90 = $65。不要直接认定下一步该购买超额用量或 Scale，先比较更高额度的 Pro。

营销邮件另行计费：Free 包含 1,000 名联系人；Pro 营销方案起价为每月 $40，包含 5,000 名联系人；Enterprise 按需定制。在联系人额度范围内，Broadcast 发送量不限，也不消耗事务邮件配额。如果通过 /emails 发送新闻简报，则会占用事务邮件配额，退订处理也要自行实现。

对本文面向的团队来说，如果生产环境的突发量可能超出 Free，就从付费事务邮件 Pro 开始；联系人列表需要时，再增加营销容量。评估 Scale 应看专用 IP 选项等运营功能，而不是凭名称就认定它是增加发送量最便宜的选择。

哪些限制可能改变选型结论？

Resend 的主要约束涉及投递责任、数据保留、共享限额和存储位置。这些问题比第一次 API 调用写起来是否优雅更重要。

配额不足导致的拒绝，需要应用自己处理

发送和接收的邮件都会计入 Resend 事务邮件配额，多个收件人也会分别计数。Free 的每日额度在 UTC 午夜重置。付费方案默认关闭超额计费，需管理员手动启用；发送因配额被拒绝时会返回错误，Resend 不会为这封邮件排队或重试。账号配额与限制文档明确说明了这些规则。

可重试任务应进入自己的队列，并对配额失败设置告警。密码重置任务在重试前，要检查令牌是否仍有效。等额度重置后才发出去的邮件，可能已经没有用了。

升级付费方案，不会自动提高每秒请求数

所有账号初始限制都是每团队每秒 10 次请求，由 API 密钥和域名共同分享。新建密钥不会获得新的独立额度池。批量发送每次请求最多可包含 100 封邮件，但队列仍需遵守请求速率限制。Resend 表示，升级方案不会自动提高这个上限，更高吞吐量需要另行与支持团队沟通。

容量与吞吐量是两回事：容量决定一个月可以容纳多少封邮件，吞吐量决定应用在突发高峰能发出多少次请求。预算和工程设计都要兼顾。

服务商的数据保留期，不能代替永久审计记录

Free、Pro 和 Scale 的邮件及日志数据保留 30 天；Enterprise 提供灵活的保留期限。如果收据争议或客服调查可能更晚发生，就应保存自己的事件历史。业务事件也要独立于服务商的 24 小时幂等保护期留存。

提前删除同样有限制。Resend 的公开数据处理说明表示，没有用于删除单封邮件的 API；已发送邮件要提前移除，需联系支持团队，而收到的邮件在保留期结束前无法删除。如果流程要求立即通过程序删除邮件，这项服务就不太适合。

从欧洲发信，不代表数据存储在欧洲

Resend 提供北弗吉尼亚、爱尔兰、圣保罗和东京发送区域。区域文档明确区分了发送位置与存储位置。

包括邮件内容、投递日志、Webhook 负载和账号记录在内的客户数据，都存储在美国。Resend 表示，没有可将这些存储数据迁移到欧盟的设置。GDPR 页面陈述了其合规立场、自我审查方式，以及标准 DPA 和数据传输条款。但这些声明并不意味着，使用爱尔兰发送区域的域名就能实现仅在欧盟存储数据。

Resend 还声明符合 SOC 2 Type II；公开页面列出了报告覆盖期，报告本身则需要登录查看。安全概览列出了加密保护，并将 HIPAA 标为“进行中”。本文评阅的是服务商的声明，并非独立合规审计。

如果采购硬性要求数据仅存储在欧盟，或要求已有可用的 HIPAA 安排，就不能只看发送区域菜单和安全徽章便批准采用 Resend。 应先解决具体要求，再开始集成。

结论：团队能负责各个边界环节，才适合用 Resend

对于小型产品团队，如果希望把模板、API 或 SMTP 发送、投递事件和偶尔开展的营销活动串成一套连贯流程，Resend 很有吸引力。它的价值是减少集成工作，同时让产品行为继续由你掌控。

但如果美国存储不符合要求、必须具备 SMTP 层诊断能力，或者应用无法稳妥处理配额失败和重试，结论就会改变。迁移没有具体收益时，继续使用运行正常的老服务商也是合理选择。

如果准备下周实施，先拿一条密码重置流程和一条收据流程，走完域名身份验证、配额拒绝、重复请求、退信处理和客服查询，并估算高峰日发送量。选择 Resend 的前提，是每个故障点都能说清谁负责、系统应如何响应，而不只是欢迎邮件渲染得好看。

常见问题

产品名 Resend 与英语中“重新发送邮件”的普通说法重合。以下回答会区分平台功能和邮箱操作。

有哪些好用的免费邮件发送服务？

对于应用，如果 Resend Free 的每日和每月限制符合需求，它可以作为起点。但上线高峰可能耗尽额度时，仅有免费额度不足以支撑生产环境，应按最繁忙一天的需求选择服务。

新版 Outlook 怎么重新发送邮件？

在新版 Outlook 中打开“已发送邮件”，选中邮件，再通过更多选项菜单进入“高级操作 → 重新发送邮件”。发送前检查草稿。Microsoft 的重新发送说明介绍了这项邮箱功能，它与 Resend API 无关。

resent 和 Resend 有什么区别？

英语“resend”表示重新发送，“resent”是它的过去式。首字母大写的 Resend，也是本文评测的邮件平台品牌名。

已经发出的邮件怎么撤回？

不要把 Resend 平台当作邮箱撤回工具。Outlook 有独立的撤回功能，但受账号和组织条件限制。Microsoft 的撤回说明指出，无法撤回发往外部账号或个人账号的邮件。

如何重新发送已经发过的邮件？

在 Outlook 中，使用上文介绍的已发送邮件操作。在应用中，则要先判断这是原事件的重试，还是有意发起的新发送；在保护期内复用 Resend 幂等键，会阻止重复发送。

能找回已经发出的邮件吗？

如果是想查看 Resend 中的某封邮件，可在保留期内进入 Emails 页面查看详情。如果是想删除收件人手里的副本，查看或删除自己的记录，与邮箱撤回并不是同一种操作。

在哪里查看已发送邮件？

Resend 的 Emails 控制台会列出已发送和已安排发送的邮件，包括通过 SMTP 发出的邮件。打开邮件后，可以查看元数据、预览、HTML、纯文本和投递事件。

为什么看不到发出去的邮件？

使用 Resend 时，先确认发送请求是否被接受，以及数据是否仍在保留期内。使用 Outlook 时，检查是否打开了正确的“已发送邮件”文件夹，并核对保存设置。Microsoft 的已发送邮件指南解释了副本缺失的可能原因。

怎样恢复已发送的消息？

先分清是邮箱副本丢失，还是服务商日志已经过期。调查超出 Resend 保留期的邮件时，要使用自己保存的事件历史；不要让客服流程依赖“服务商控制台会永久保存记录”这个假设。

使用 AI 业务工作流程审计清单，为每个邮件触发、失败和恢复步骤指定负责人；订阅新闻简报获取清单。