用 Cloudflare + Resend 搭建自己的私人 Email 系统
用 Cloudflare + Resend 搭建自己的私人 Email 系统
Blog 版：在 F-SJ Blog 阅读
为什么想做自己的 Email
有了自己的域名之后，除了可以绑定网站，另一个很自然的想法就是：能不能也拥有自己的 Email？
普通邮箱通常是固定服务商域名，比如某个公共邮箱平台。它当然能用，但也有几个问题：好名字经常已经被注册；邮箱名称很难保持统一；个人展示、项目联系、账号注册和长期沉淀混在一起，也不够清晰。
自定义域名 Email 解决的正是这个问题。只要拥有域名，就可以围绕这个域名规划自己的邮箱地址，例如：
1 | <name>@email.example.com |
这让邮箱从“抢一个别人平台里的名字”，变成“在自己的域名下设计一套地址体系”。名称更自由，也更个性和职业化，不用再烦恼常用用户名被别人注册。
对个人项目来说，它也是 Blog 的一个很合适的配件：Blog 用来展示内容，私人 Email 用来承接联系、通知、评论提醒和账号体系。
为什么它适合个人低成本项目
这个项目最有价值的地方，是把“自定义名称 + 多地址管理 + 私有接收发送服务”组合到了一起。
1. 自定义名称
邮箱地址不再依赖公共邮箱平台剩下的用户名，而是依赖自己的域名。
这意味着可以按用途设计地址：
- 个人主邮箱。
- Blog 联系邮箱。
- GitHub 或开源项目邮箱。
- 注册服务专用邮箱。
- 临时测试邮箱。
这样看起来更统一，也更职业化。
2. 多地址管理
有了域名后，可以围绕同一个域名管理多个地址或别名。它适合做多账号、多项目、多用途隔离。
例如，一个地址用于公开联系，一个地址用于系统通知，一个地址用于测试注册。不同来源的邮件可以被分开处理，后续也更容易做过滤、转发和统计。
这里的“多地址”不等于可以无限滥发邮件。实际数量、发送频率和平台策略仍受 Cloudflare、Resend 等服务规则限制。但对个人学习、个人 Blog 和轻量项目来说，这套方式已经足够灵活。
3. 私有接收和发送服务
传统邮箱是完整托管在邮箱服务商中。这个项目的思路是：用 Cloudflare 接收邮件，用自己的 Worker 和 Web Inbox 管理邮件，再用 Resend 处理对外发送。
这样既不用自己维护完整邮件服务器，也可以拥有更强的自定义能力。
最终选型
当前私人 Email 系统使用的核心组合是：
- Cloudflare DNS：管理域名和邮件相关 DNS 记录。
- Cloudflare Email Routing：接收发往自定义域名的邮件。
- Cloudflare Workers：处理邮件 API、收件、转发和 Blog 邮件发送接口。
- Cloudflare Pages：部署 Web Inbox 管理界面。
- Resend：负责从自定义域名发送邮件。
- GitHub：保存源码、记录修改历史，并配合部署流程。
参考开源项目：
当前这个系统不是从零写完整邮件服务器，而是在 Cloudflare 生态和开源项目基础上做适配、部署和定制。
Cloudflare Email Routing 是什么
Cloudflare Email Routing 是 Cloudflare 提供的邮件路由能力。它可以接收发往自定义域名的邮件，并把邮件转发到指定目标，或者交给 Cloudflare Worker 继续处理。
文档：
在这个项目中，它主要负责“收信入口”：
- 外部有人发邮件到自定义域名地址。
- Cloudflare 根据 DNS 和 Email Routing 配置接收邮件。
- 邮件被转发或交给 Worker 处理。
- Worker 保存、解析或展示邮件。
这样就不需要自己搭建传统 SMTP 收信服务器。
Cloudflare Workers 是什么
Cloudflare Workers 是运行在 Cloudflare 边缘网络上的轻量服务。它可以处理 HTTP 请求，也可以处理部分 Cloudflare 事件。
文档：
在私人 Email 项目中，Worker 主要承担后端逻辑：
- 接收邮件事件。
- 解析邮件内容。
- 提供邮件列表、详情、删除等 API。
- 管理地址、用户、设置和转发规则。
- 给 Blog 提供独立邮件发送接口。
- 调用 Resend 完成对外发信。
它的好处是不用维护服务器。代码部署到 Cloudflare 后，由 Cloudflare 负责运行和扩缩容。
Cloudflare Pages 是什么，在这个项目里做什么
Cloudflare Pages 负责部署前端页面。
文档：
在 Blog 项目中，Pages 托管 Blog；在私人 Email 项目中，Pages 托管 Web Inbox，也就是浏览器里的邮件管理界面。
这个界面可以用来：
- 登录邮箱管理后台。
- 查看收到的邮件。
- 管理地址。
- 处理发送、转发、过滤等功能。
这样整个系统就不只是“收到邮件后转发”，而是有了一个自己的私有收件箱。
Resend 是什么
Resend 是面向开发者的邮件发送服务。它提供 API，可以让应用通过 HTTP 请求发送邮件。
官网和文档：
为什么需要 Resend？因为收信和发信是两件事。
Cloudflare Email Routing 更适合处理收信和路由；对外发信则需要可靠的发送服务，包括 DKIM、SPF、退信处理和发送信誉。Resend 正好适合承担这个角色。
在这个项目中，Resend 负责“发信出口”：
- Worker 收到发信请求。
- Worker 校验权限和参数。
- Worker 调用 Resend API。
- Resend 使用自定义域名完成邮件发送。
这样 Blog 评论通知、站点联系、系统提醒都可以使用自己的域名邮箱发出。
DNS 是什么，为什么 Email 特别依赖 DNS
DNS 是域名系统。网站绑定域名要靠 DNS，Email 更依赖 DNS。
网页通常只需要把域名指向网站服务；Email 还需要告诉外界：这个域名的邮件由谁接收、谁有资格发送、签名如何验证。
常见邮件 DNS 记录包括：
- MX：说明这个域名的邮件由哪台邮件服务接收。
- SPF：说明哪些服务可以代表这个域名发送邮件。
- DKIM：给邮件加签名，证明邮件确实来自授权服务。
- CNAME：把一个子域名指向另一个服务地址。
这个项目里大致分成两组 DNS：
1. 收信 DNS
收信 DNS 让 Cloudflare 可以接收发往自定义域名的邮件。
概念上包括：
1 | email.example.com MX -> Cloudflare Email Routing |
2. 发信 DNS
发信 DNS 让 Resend 可以代表自定义域名发邮件。
概念上包括：
1 | send.email.example.com MX -> Resend / SES feedback service |
这些记录配置完成后，外部邮件服务更容易判断：这封邮件是被域名授权发送的，而不是伪造的。
域名和地址规划
当前项目的思路是：把 Blog 和 Email 拆成不同子域名，各自职责清晰。
- Blog：
blog.example.com - Inbox：
inbox.example.com - Email 域：
email.example.com
实际使用时，只需要把 example.com 换成自己的域名。
这种拆法的好处是：
- Blog 是公开内容入口。
- Inbox 是私人邮箱管理入口。
- Email 域专门用于邮件地址。
- 后续如果增加更多服务，不会互相挤占命名空间。
搭建流程概览
整个私人 Email 项目可以拆成几个阶段。
第一步：准备域名
先拥有一个可以托管到 Cloudflare 的域名。
域名是整个系统的前提。没有域名，就无法真正拥有自定义后缀邮箱。
第二步：接入 Cloudflare DNS
把域名交给 Cloudflare 管理 DNS。这样后续 Pages、Workers、Email Routing、Resend 验证都可以在同一个地方配置。
第三步：部署收件系统
部署 Cloudflare Worker 和 Web Inbox。
Worker 负责后端 API 和邮件处理；Pages 负责网页界面。
第四步：配置 Cloudflare Email Routing
在 Cloudflare 中启用 Email Routing，并为邮件子域名配置 MX / SPF 等记录。
配置完成后，Cloudflare 就可以接收发往自定义域名的邮件。
第五步：配置 Resend 发信域名
在 Resend 中添加发信域名，并根据 Resend 提供的 DNS 要求添加 SPF、DKIM、MX 等记录。
验证通过后，就可以使用这个域名对外发信。
第六步：打通 Worker 和 Resend
Worker 保存 Resend 调用凭据作为环境变量。发信时由 Worker 调用 Resend API。
公开文档中只记录组件关系和用途，不记录任何真实凭据。
第七步：连接 Blog
Blog 评论通知、订阅通知或联系表单不直接调用 Resend，而是调用自己的邮件 Worker 接口。
这样 Blog 只知道“向自己的邮件服务发请求”，真正的发信实现留在 Email 项目里。以后如果更换发信服务，也只需要改 Email 项目。
我们增加的自定义能力
在开源项目和 Cloudflare 基础能力之上，当前系统做了这些定制：
- 使用自己的域名规划邮件地址。
- 部署独立 Web Inbox 作为私人收件箱。
- 使用 Cloudflare Worker 管理邮件 API。
- 使用 Resend 作为发信出口。
- 给 Blog 提供专用邮件发送接口。
- 让 Blog 评论、通知、联系能力统一走自己的 Email 服务。
- 把收信和发信都纳入自己的域名体系。
这种设计让 Email 成为 Blog 平台的基础配件，而不是临时外挂。
它适合什么场景
这套私人 Email 系统适合：
- 个人 Blog 联系邮箱。
- GitHub / 开源项目联系地址。
- 多账号注册隔离。
- 个人项目通知发送。
- 评论、订阅、联系表单邮件。
- 学习 Cloudflare DNS、Workers、Pages、Email Routing 和 Resend。
它不适合一开始就承担大规模商业邮件营销，也不应该用来绕过平台限制批量发信。免费额度和平台策略适合个人学习、小型项目和低频真实邮件场景。
这次搭建的收获
有了域名之后，自定义 Email 是一个非常合适的配件。
Blog 解决“内容展示和沉淀”的问题；Email 解决“联系、通知和身份”的问题。两者结合后，一个个人云端平台就更完整了。
它的价值不只是拥有一个好看的邮箱地址，而是把域名、DNS、收信、发信、前端页面、边缘函数和 API 串成了一个真实系统。
以前自己搭邮件服务器门槛很高：要处理 SMTP、反垃圾、证书、IP 信誉、运维和安全。现在借助 Cloudflare 和 Resend，可以不从零维护邮件服务器，也能拥有足够个性化和可控的私人 Email 服务。
对个人开发者来说，这确实是一个很适合“低成本搭建个人基础设施”的方案：
- 自定义名称，解决邮箱名字被占用的问题。
- 多地址规划，适合多账号和多项目管理。
- 私有 Inbox，保留自己的管理入口。
- 自定义域名发信，让对外沟通更统一。
- 和 Blog 打通，形成个人平台闭环。
Cloudflare 相关扩展：私人 Email 的 DNS、收信、Worker、Pages 和安全能力都依赖 Cloudflare，可以看 Cloudflare：个人云端平台的低成本基础设施。
相关链接
参考开源项目：
官方文档：
