用 Cloudflare + Resend 搭建自己的私人 Email 系统
为什么想做自己的 Email
有了自己的域名之后，除了把它绑定到 Blog，另一个很自然的想法就是：能不能也拥有一套自己的 Email？
普通邮箱当然能用，但它始终是别人平台里的一个账号。好名字经常已经被注册，个人展示、项目联系、账号注册、系统通知和自动化消息也容易混在一起。对于长期维护的个人项目来说，这种感觉总差一点“自己的东西”。
自定义域名 Email 解决的就是这个问题。只要域名在自己手里，就可以按用途规划不同地址，例如：
1 | admin@email.example.com |
这时邮箱不再是“抢一个公共平台剩下的名字”，而是在自己的域名下设计一套地址体系。名字更自由，也更适合做个人品牌、项目联系和系统通知。
更准确地说，这套 Email 不只是某个 Blog 的配件，而是一个可以被多个项目复用的通用通信组件。它把收信、发信、身份、权限和 API 封装成独立能力：Blog 可以调用它，联系表单可以调用它，自动化脚本、评论系统、账号系统也可以调用它。
这次最终跑通的形态
这次没有选择自己维护完整邮件服务器，而是用 Cloudflare 和 Resend 拼出一套轻量、可复用的 Email 能力组件：
- Cloudflare DNS：管理域名和邮件相关 DNS 记录。
- Cloudflare Email Routing：负责接收发往自定义域名的邮件。
- Cloudflare Workers：处理收件、发信 API、权限校验和统一接口封装。
- Cloudflare Pages：部署 Web Inbox 管理界面。
- Resend：负责从自定义域名稳定对外发送邮件。
- GitHub：保存源码和部署配置，方便后续迭代。
整体结构大概是这样：
这套结构的关键点是：收信、发信、管理入口和业务系统解耦。Cloudflare 更适合做域名、收信、路由、Worker API 和 Pages；Resend 更适合做稳定发信、DKIM/SPF 验证和邮件送达。业务系统不直接依赖 Resend，只需要调用自己的 Worker API。
为什么不是自己搭邮件服务器
以前想拥有自己的邮箱，最直接的理解可能是“买服务器，搭 SMTP / IMAP”。但真正做起来会遇到很多麻烦：
- SMTP、IMAP、反垃圾规则都要自己维护。
- 服务器 IP 信誉会影响邮件送达。
- DKIM、SPF、DMARC 等 DNS 记录要配置正确。
- 邮件安全和垃圾邮件防护需要长期维护。
- 家用网络或低价 VPS 不一定适合稳定发信。
所以这次更适合选择“托管能力组合”的方式：不自己维护完整邮件服务器，而是把收信、发信、网页管理和 API 调用拆给更合适的平台。
Cloudflare Email Routing 做什么
Cloudflare Email Routing 负责收信入口。
它可以接收发往自定义域名的邮件，然后把邮件转发到指定地址，或者交给 Cloudflare Worker 继续处理。在这个项目里，我更希望邮件先进入自己的 Worker 和 Web Inbox，而不是只做简单转发。
这样做之后，系统就不只是“把邮件转给另一个邮箱”，而是有了一个自己的私有收件箱，可以在浏览器里查看和管理邮件。
Web Inbox 做什么
Web Inbox 是浏览器里的邮箱管理界面。
这部分基于开源项目 cloudflare_temp_email 做部署和适配。它让我不需要从零写完整邮箱前端，也不用一开始就自己实现所有收件、列表、详情、地址管理逻辑。
它承担的角色更像是“私人邮件后台”：
- 查看收到的邮件。
- 管理邮箱地址。
- 和 Cloudflare Worker 后端 API 配合。
- 让收信系统有一个可视化入口。
Resend 做什么
Resend 负责发信出口。
收信和发信是两件事。Cloudflare Email Routing 适合接收邮件，但评论通知、订阅确认、退订确认、联系表单通知、系统提醒这类邮件，需要一个可靠的发送服务。Resend 的定位正好是开发者邮件 API：通过 HTTP API 发邮件，同时处理 DKIM、SPF、区域和发送信誉这些问题。
Resend 的关键检查点是域名状态变成 Verified。
DNS 为什么是关键
Email 比普通网页更依赖 DNS。
网页通常只需要把域名指向网站；Email 还要告诉外部邮件系统：谁负责收信，谁有资格代表这个域名发信，邮件签名怎么验证。
这次主要配置了几类记录：
- MX：说明邮件由谁接收。
- SPF：说明哪些服务可以代表域名发送邮件。
- DKIM：给邮件做签名验证，降低被当成伪造邮件的概率。
- CNAME：把公开 Web 入口或私有 Inbox 入口指向 Cloudflare Pages。
Cloudflare DNS 记录本身可以被公开查询，MX、SPF、DKIM 也不是密钥。
收信和发信其实是两组 DNS：
1 | email.<your-domain> -> Cloudflare Email Routing 收信 |
业务系统如何接入 Email
业务系统不直接保存 Resend API Key，也不直接调用 Resend；普通浏览器用户也不能直接读取 Inbox 邮件或调用发信接口。
更合理的做法是：业务系统只在服务端调用自己的邮件 Worker 接口，由 Email 组件统一处理权限校验、发信身份、收件记录和 Resend 调用。发信接口必须带服务端 Token；收件箱读取接口必须登录后访问。这样以后如果更换邮件服务，接入方不用大改。
这个接口可以被很多场景复用：
- Blog 订阅确认邮件。
- 评论回复通知。
- 联系表单通知。
- 账号验证码或一次性确认链接。
- 管理员通知。
- 自动化脚本运行结果通知。
这也是我比较喜欢这次设计的地方：Email 不再是某个页面里的临时外挂，而是独立出来的通信基础设施。只要接口稳定，任何需要收发邮件的项目都可以接进来。
搭建流程概览
如果重新整理一次流程，大概可以拆成这些阶段。
1. 准备域名
先拥有一个可以托管到 Cloudflare 的域名。没有域名，也就没有真正属于自己的邮箱后缀。
2. 接入 Cloudflare DNS
把域名交给 Cloudflare 管理。后续 Email Routing、Resend 验证、公开站点和私有管理入口都会依赖这里的 DNS 配置。
3. 部署 Web Inbox 和 Worker
使用开源项目作为基础，部署 Cloudflare Worker 和 Pages。Worker 负责后端逻辑，Pages 负责可视化界面。这个界面属于私有管理入口，公开文章只介绍用途，不公开完整访问地址。
4. 配置 Email Routing
在 Cloudflare 中启用 Email Routing，让自定义邮箱域名可以接收邮件。
5. 配置 Resend 发信域名
在 Resend 中添加自己的发信域名，按照提示补齐 SPF、DKIM、MX 等记录，直到域名状态变为 Verified。
6. 连接业务系统
把评论、订阅、退订、联系表单、自动化通知等邮件请求统一交给自己的邮件 Worker，再由 Worker 调用 Resend 发出。这里使用服务端到服务端调用：业务系统持有内部 Token，浏览器端不接触真实发信密钥。
7. 做公开和私有记录分层
公开笔记只记录流程、架构和踩坑；真实 token、后台口令、JWT、完整收件内容、Inbox 完整地址和真实 API endpoint 放在 Private / Local，不进入 Blog。
适合什么场景
这套私人 Email 系统适合：
- 个人域名联系邮箱。
- GitHub / 开源项目联系地址。
- 多账号注册隔离。
- 个人项目通知发送。
- 评论、订阅、联系表单邮件。
- 自动化脚本、监控任务、后台系统的通知出口。
- 学习 Cloudflare DNS、Workers、Pages、Email Routing 和 Resend。
它不适合一开始就承担大规模商业邮件营销，也不应该用来绕过平台限制批量发信。免费额度和平台策略更适合个人学习、小型项目和低频真实邮件场景。
这次搭建的收获
这次最大的收获，是发现“自己的 Email”不一定要从维护邮件服务器开始。
借助 Cloudflare 和 Resend，可以先拥有一个足够可用的低成本版本：域名归自己，收信入口归自己，发信身份归自己，管理界面也归自己。底层复杂的送达、签名、边缘运行和 HTTPS 则交给更专业的平台。
对个人开发者来说，这种方案很适合用来搭建自己的基础设施：
- 自定义名称，解决邮箱名字被占用的问题。
- 多地址规划，适合多账号和多项目管理。
- 私有 Inbox，保留自己的管理入口；公开文章中只描述用途，不暴露完整管理地址。
- 自定义域名发信，让对外沟通更统一。
- 通过 API 和 Blog、联系表单、评论系统、自动化脚本打通，形成可复用的个人通信组件。
Cloudflare 相关扩展：私人 Email 的 DNS、收信、Worker、Pages 和安全能力都依赖 Cloudflare，可以看 Cloudflare：个人云端平台的低成本基础设施。
相关链接
参考开源项目：
官方文档：
