useSend 项目解析：开源自建的邮件发送基础设施，Resend 与 SendGrid 的 AGPL 替代
useSend 用 Amazon SES 做投递底层，在其上自建仪表盘、联系人簿、营销邮件、REST API 与 SMTP 网关，可 Docker/Railway 自托管。本文结合 README 与官方文档介绍它的定位、能力、接入方式与 AGPL 许可的取舍。
相关标签
项目概览
useSend 是一个开源的邮件发送基础设施，仓库 usesend/usesend 目前约 4,745 star、440 fork，用 TypeScript 编写，采用 AGPL-3.0 许可。README 的第一句定位很直接：The Open Source sending infrastructure——Resend、SendGrid、Mailgun、Postmark 这类商业邮件 API 的自建替代品。
它和大多数同类开源项目有一个关键区别：它不是自己造投递通道。和市面上绝大多数邮件产品一样，useSend 底层用 Amazon SES 发信，自己负责的是上层那一整套东西——域名管理、模板与可视化编辑器、联系人簿、营销活动、投递事件看板、Webhook、REST API 与 SMTP 网关。换句话说，它把 SES 那个”便宜但难用”的裸接口，包成了一个有仪表盘的完整产品。
项目目前仍标注为 beta，README 明确说正在推进公开测试。
它解决什么问题
用 SES 直接发信的人大概都经历过同样的落差：价格是便宜，但你要自己处理域名验证、退信与投诉通知（得自己接 SNS）、打开与点击追踪、退订管理、模板渲染、发送队列与限速。这些杂事加起来，往往比省下的钱更贵。
用 Resend 这类托管服务则相反：开发体验很好，但按封计费，量大之后成本陡增，而且数据、域名信誉、联系人列表都在别人那里。
useSend 想占的是中间位置：投递交给 SES（成本可控），上层产品自己托管（数据自己拿）。README 里对这件事的表述是”提供一种开放的方式，可靠且便宜地发邮件，同时有一个好用的仪表盘”，并且可以直接管理联系人、发送群发邮件（newsletter、产品更新），订阅关系由系统负责。
能力清单
README 用勾选列表把已完成与规划中的能力分得很清楚：
- 已支持：添加域名、事务邮件、REST API、仪表盘（送达 / 打开 / 点击 / 退信）、营销邮件、SMTP 支持、定时发送 API、Webhook
- 尚未完成：收信（inbound email）、自带 AWS 凭证（BYO AWS credentials）
对照文档的 API 索引，实际暴露的接口面比这份清单更宽：邮件维度有发送、批量发送、查询、列表、修改定时、取消定时；联系人维度是完整的 contact book 与 contact CRUD（含批量创建、批量删除、upsert）；域名维度有创建、验证、列表、删除；营销活动（campaign）可以创建、排期、暂停、恢复、删除；分析维度有邮件时间序列与发件信誉指标。
文档里还有几个能体现”产品化程度”的细节：Double Opt-In（新订阅者先收确认信才进联系人簿）、Campaign Personalization（用联系人变量做逐收件人个性化）、Webhook 按域名过滤，以及和 React Email 的配合使用。
技术栈
README 把整套栈列得很坦率，基本是当下 TypeScript 全栈的主流组合：
| 层 | 选型 |
|---|---|
| 框架 | Next.js |
| ORM | Prisma |
| 样式 | Tailwind |
| 组件库 | shadcn/ui |
| 认证 | NextAuth.js |
| 内部 API | tRPC |
| 公开 API | Hono |
| 队列 | Redis |
邮件编辑器是单独的一个包（packages/email-editor），核心是 tiptap，用 jsx-email 把编辑内容转成 HTML，交互设计上受 maily.to 启发。这个拆分挺合理：编辑器是可以被单独复用的资产，不必绑死在主应用里。
怎么用
路径一：REST API / SDK
官方提供 Node、Python、Go 三套 SDK。以 Node 为例，装包、初始化、发一封信三步：
安装：
npm install usesend-js
初始化（自建实例需要传 base URL）：
import { UseSend } from "usesend-js";
const usesend = new UseSend("us_12345");
// 自建时：
// const usesend = new UseSend("us_12345", "https://your-usesend-instance");
发送：
usesend.emails.send({
to: "hello@acme.com",
from: "hello@company.com",
subject: "useSend email",
html: "<p>useSend is the best open source product to send emails</p>",
text: "useSend is the best open source product to send emails",
headers: { "X-Campaign": "welcome" },
});
文档特别说明：自定义 header 会原样透传，平台只管理 X-Usesend-Email-ID 与 References 两个头——这对需要自己做投递追踪或线程归并的团队很重要。
加联系人也同样是 SDK 调用，先拿到 contact book 的 id，再 usesend.contacts.create(bookId, {...})。
路径二：SMTP
不想改代码的话，useSend 提供 SMTP 网关，现有系统把 SMTP 配置一换就能接上。官方参数是：
主机与端口：
Host: smtp.usesend.com
Port: 465 / 587 / 2465 / 2587
文档里给了 Nodemailer 的完整示例，认证用 useSend 生成的凭证。对已经在用 Nodemailer、PHPMailer、Django 内置 mailer 的老系统来说，这是迁移成本最低的路径。
路径三：自托管
这是 useSend 真正的卖点。前置条件只有两样：一个 GitHub 账号（用来做登录鉴权）和一个 AWS 账号（SES 发信、SNS 回传投递状态）。核心依赖是 Postgres（数据库）+ Redis（队列），配置走 .env.selfhost.example。
自托管要准备的凭据大致是三类：
- AWS：创建一个带
AmazonSNSFullAccess与AmazonSESFullAccess策略的程序化访问用户，填AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY - GitHub App：回调地址为
https://<你的实例>/api/auth/callback/github，账号权限里”Email addresses”需要只读（用来把新账号和团队邀请对上） - 数据库与队列：
DATABASE_URL（Postgres）、REDIS_URL（Redis），共用 Redis 时还可以用REDIS_KEY_PREFIX做命名空间隔离
部署方式有三种：官方 Docker 镜像（DockerHub 与 GHCR 双通道，usesend/usesend）、docker-compose（数据库和 Redis 会自动起好）、或者 Railway 一键部署。README 里还留了一句很实在的话：目前登录只支持 GitHub，如果想要邮箱密码登录，”请在代码上帮我们一把”。
最近的进展
按官方 changelog，最新版本是 v1.9.0（2026 年 3 月），主题是营销侧的完善：
- Campaign Personalization with Contact Books：营销活动支持联系人簿变量，可以按订阅者数据做个性化
- Double Opt-In Customization：确认流程与文案可自定义，便于匹配自家 onboarding 与合规要求
- API / SDK 覆盖扩展：联系人簿能力进入 SDK，仪表盘分析数据在公开 API 与 SDK 都能拿到，新增删除 campaign 的公开端点
- Webhook 按域名过滤：多域名场景下可以按域名路由与监控事件
再往前一版 v1.8.0 铺的是地基：Webhook 上线、联系人簿公开 API、请求幂等支持。
与同类方案的取舍
把三者放在一起看比较清楚：
| 商业 API（Resend / SendGrid / Postmark） | 裸用 Amazon SES | useSend | |
|---|---|---|---|
| 成本 | 按封计费，量大后偏高 | 最低 | 只付 SES 费用 + 自己的服务器 |
| 上手成本 | 最低 | 高（需自建上层） | 中（自托管要配 AWS、DB、Redis） |
| 数据归属 | 厂商 | 自己 | 自己 |
| 产品能力 | 完整 | 几乎没有 | 仪表盘、营销、联系人、Webhook、API、SMTP |
| 许可 / 锁定 | 商业条款 | 云服务条款 | AGPL-3.0，可自建可改 |
需要说清楚的是许可：AGPL-3.0 是强 copyleft，如果你修改了 useSend 并把它作为网络服务对外提供，按 AGPL 的要求需要开放相应源码。内部自用、不对外提供服务的场景不受这条约束，但把它嵌进闭源 SaaS 再对外卖，就得先想清楚合规。
项目状态与许可
- 仓库：usesend/usesend，2024 年 3 月创建，主语言 TypeScript，约 4,745 star / 440 fork，49 个 open issue
- 状态：beta，README 明确说明正在准备公开测试；收信（inbound）与自带 AWS 凭证仍在待办
- 许可：AGPL-3.0
- 周边：官方云服务 app.usesend.com、文档 docs.usesend.com、Discord 社区，Docker 镜像双仓库发布，Railway 一键部署
获取与了解
- 仓库：https://github.com/usesend/usesend
- 官网：https://usesend.com
- 文档：https://docs.usesend.com
- 自托管指南：https://docs.usesend.com/self-hosting/overview
- 本地开发：https://docs.usesend.com/get-started/local
- Docker 镜像：
usesend/usesend（DockerHub 与 ghcr.io）
如果你正在为”每月几十万封事务邮件 + 偶尔发发 newsletter”这件事付一笔不小的 API 账单，又不想回到裸用 SES 的蛮荒时代，useSend 值得花一个下午自建一套试试——尤其是它已经把 SMTP 和 REST 两条接入路径都铺好了，切换成本比想象中低。
更多资讯
想看更多优质内容？
浏览所有资讯