30 秒看懂
Resend 联合创始人 Zeno Rocha 说,让开发者轻松发送邮件,需要在幕后处理投递、滥用和 DNS 等难题。他介绍如何把 API 优先的产品扩展到 MCP 和命令行,以及模型误读交互式价格计算器后,他如何用文本重写价格信息。Rocha 还讲述设计和家庭如何影响他的创业决定。
- 1大量邮件需要控制发送节奏并持续监测Rocha 描述服务商限流、互动信号和声誉。
- 2远程智能体访问要求重新审视权限Resend 在分发远程 MCP 集成前构建了 OAuth 和可观测性。
- 3文本让智能体更容易读取价格示例交互式组件被误读后,后续测试从文本中得到了正确数字。
- 4Rocha 把家庭时间与公司增长一起列为重点他说与女儿保持亲近是一项重要选择。
要点建议
- 邮件投递需要控制发送节奏、管理声誉并识别滥用。
- API 优先的产品既可以支持人类界面,也可以支持智能体工具。
- 机器可读页面可以让智能体更容易获取信息,但很难单独判断其对推荐的影响。
- Rocha 有意识地将产品打磨和家庭时间列为重点。
按章节阅读整理后的全文
从开发者工具到邮件投递
Rocha 解释 Resend 的起源和邮件发送背后的复杂性。
Resend 联合创始人 Zeno Rocha 说,他的邮件平台起步于开发者体验问题,如今服务数百万用户。他也谈到如何在创业时优先安排与家人的时间。
主持人 swyx 介绍 Rocha;Rocha 过去的项目包括 Dracula 编辑器主题。他说,人们曾经更熟悉 Dracula,而不是 Resend。
Rocha 来自前端开发领域,并非邮件基础设施领域。他用过现有服务,觉得开发者值得获得更用心的体验。
他报告录制时平台有 430 万用户和 12 万付费客户,涵盖个人开发者和大型公司。
swyx 披露自己是 Resend 的天使投资人。他回忆自己的项目已经配置了其他邮件服务,编程模型仍建议他添加 Resend。
Rocha 说,他投入大量精力,让产品在新的分发环境中被发现:人们会询问模型应该使用哪些工具。
Rocha 说,大量发送邮件不只是扩容问题。不同邮箱服务商有不同规则,还会观察收件人的行为。
公司最初移除了漫长的审批流程以减少摩擦,后来才理解老牌服务为何这样做:欺诈、钓鱼和滥用是重大的运营问题。

大批邮件需要排队并控制速度。Rocha 说,服务商可能先观察早期收件人的互动,再决定如何处理后续邮件。
平台还要管理 IP 池和发送速率。Rocha 说,持续稳定的发送模式可能比突然大量发送、随后长期沉默更健康。
他介绍团队如何查看域名年龄、网站信号和发送行为来识别可疑账户,同时区分恶意滥用与普通用户的操作错误。
Rocha 说,用户不应该必须成为邮件专家才能避免基本错误。产品会在工作流程中提供提示和检查,帮助用户遵循最佳实践。
服务开始根据 HTML 邮件生成纯文本版本。Rocha 说,这有助于过滤器检查内容,但纯文本也会改变打开率追踪方式。
不可见图片可以记录打开事件,但隐私功能和自动扫描可能在人没有阅读邮件时加载图片。因此 Rocha 认为打开率不再那么可靠。
他还讨论链接追踪域名:如果恶意客户损害共享追踪域名的声誉,其他发送者也可能受影响。
团队选择让用户快速开始,在出现警示信号时介入。Rocha 说,之后会与用户沟通,判断问题是误用还是故意滥用。
支持服务、DNS 与开源模板
对话涵盖文档、域名设置和 React Email。
话题转向支持服务。早期员工负责回复工单,但 Rocha 说团队还需要改善文档,防止相同问题反复发生。
团队曾规定支持回复必须包含文档链接。起初编写文章更花时间,但之后可以向其他客户重复提供答案。
DNS 配置仍是常见障碍,尤其对使用 AI 构建工具、却不知道如何排查 CNAME 或 TXT 记录的人来说。
Rocha 介绍 Domain Connect:该协议让服务通过授权流程与参与的提供商协调 DNS 修改。推动其采用需要与各家提供商合作。
邮件基础设施也依赖行业关系。Rocha 说,公司聘请了有投递经验的人,并借助他们已有的人脉网络。
React Email 成为产品的开源入口。Rocha 说,它先解决邮件模板难写的问题,之后用户才需要发送服务。
他说团队先启动 Resend,再根据用户研究发现的痛点构建 React Email:把设计转换为兼容邮件的 HTML 很麻烦。
该框架用 React 风格的组件生成邮件标记。两人指出邮件客户端不会执行普通网页 JavaScript,因此主要收益在于模板编写。
Rocha 回忆有人警告他邮件服务商可能要投入大量精力对抗滥用。他因此认为自动化至关重要,不能只靠不断扩大人工团队。
他说 Resend 的 SDK 下载量超过了 SendGrid,同时承认 SendGrid 仍发送多得多的邮件,也拥有大型企业客户。
两人讨论邮件及短信、消息等相邻渠道的经济模式。Rocha 说,他更广泛的目标是帮助客户与受众建立联系。
掌握基础设施并服务智能体
Rocha 讨论发送基础设施、API 设计和 MCP。
Resend 最初建立在 Amazon SES 之上,重点改善开发者工具。Rocha 说,发送成本低并不意味着不需要事件、队列、日志和 webhook 等配套设施。
公司现在正在建设更多自己的发送基础设施。Rocha 期待由此更好地控制吞吐量、投递表现和展示给客户的信息。
他介绍管理 IP 地址段、发往邮箱服务商的流量,以及运营基础设施所需的关系。他希望用户能更清楚地看到邮件发送后发生了什么。
为改善性能,公司把发送路径的一部分从 JavaScript 技术栈迁到 Go。Rocha 说团队愿意在合适的地方使用不同语言。

Rocha 希望客户能通过所需的任何界面使用 Resend。他说,API 优先的方法后来让向智能体开放功能更容易。
他报告 MCP 使用量持续增长,并说第一个实现来自一位投资人的开源项目,后来转移给了公司。
为提供远程 MCP 集成,团队重新审视权限并构建 OAuth 支持。随后又加入可观测性,并努力通过官方目录分发集成。
Rocha 说自己更喜欢由软件厂商维护的官方集成。对他而言,是否提供这类集成会影响产品选择。
他会观察工具调用和返回的数据量。MCP 工具已增加到 80 多个;他说最近并未看到工具数量造成此前预想的混乱。
覆盖仪表盘里的全部功能很困难,尤其是账单、邀请、账户配置和删除等功能。团队必须决定哪些操作适合放进 API。
两人讨论让公共 API 独立于用户界面。Rocha 说,分别维护公共和私有路径曾给团队带来重复工作。
界面、收件箱与投递
两人探讨 CLI 访问、协作和收件功能。
Resend 也提供 CLI 和 SDK。Rocha 展示求职者除了使用常规界面,还可以通过 CLI 或 API 申请职位。
他说,团队支持多种语言并提供免费层,部分原因是他记得自己在巴西用有限资源和网络条件开发软件的经历。
产品还提供协作编辑器。Rocha 说,有些团队希望营销人员可视化编辑模板,另一些则更愿意把模板放在源码控制中。
谈到收件时,他介绍了通过程序创建多个收件箱,并开放读取、标记和分类邮件等操作的计划。
Rocha 说不同邮箱服务商的接收规则不同。声誉越来越多地与域名及 IP 地址关联,因此发送方可能分开交易邮件和营销邮件。
让产品信息更容易被发现
Rocha 分享文档和机器可读页面的实验。
Rocha 转向可发现性。公司为具体语言和框架组合编写简短文档,后来又在各页面加入问答内容。
团队还发布页面的机器可读 Markdown 版本。Rocha 说,模型曾误读交互式价格组件;他加入文本版本后,后续测试得到了正确数字。

分别维护 HTML 和 Markdown 可能产生多个需要更新的来源。两人讨论了从共同来源生成两者的可能性。
Rocha 说比较页面和迁移页面是另一项实验。他把重要图表数据写成文本,因为抓取文本的智能体可能不会执行 JavaScript 组件。
他怀疑较新的工具和独立讨论会影响推荐,但两人也承认很难分离出究竟是哪种可发现性策略产生了效果。
他们介绍追踪推荐情况和进行实验。Rocha 说现有分析产品能报告可见度,但不总能告诉他采取什么行动可以改善。
企业增长与家庭
讨论以销售、产品定位和个人重点收尾。
谈到企业销售,Rocha 说公司谨慎增加相关职能,以维护文化。企业客户可能需要实质不同的产品,而不仅是一份更长的功能清单。
营销邮件和交易邮件的成本结构不同。Rocha 描述大型营销活动需要分批发送、观察互动并调整速率。
Rocha 谈到自己作为父亲参加 Y Combinator,以及与家庭处境不同的创始人比较所带来的困难。
一位顾问曾说他在设计上花了太多时间。Rocha 最终决定,产品的个性和使用体验是值得坚持的重点。
他说,他宁愿经营规模较小的公司并与女儿保持亲近,也不愿为了更大的公司牺牲这段关系。
两人都承认,雄心勃勃的工作占据注意力时,很难全心陪伴家人。Rocha 说他每天都试着做得好一点。
swyx 最后区分了在现有品类中领先与创造新品类。两人讨论了用简洁语言解释一个新品类有多困难。
两人在回顾产品定位、公司建设和家庭之后结束对话。
同频道的其他文章
23:15EN → 简体中文
1:42:28EN → 简体中文
50:37EN → 简体中文
50:50EN → 简体中文
1:12:24EN → 简体中文
34:48EN → 简体中文