博文概览 #
你是不是也想过这件事：域名都买了，总不能一直只拿来挂网站吧。搞几个 admin@your-domain.com、me@your-domain.com、notice@your-domain.com 这种邮箱，看起来舒服，注册服务也方便。
但现实通常很扫兴：企业邮箱要钱，传统自建邮箱要维护 SMTP、IMAP、反垃圾、证书、端口、信誉，一套下来像是在给自己加班。Cloud Mail 刚好卡在中间：它把邮箱 Web 服务跑在 Cloudflare Workers 上，收信接 Cloudflare Email Routing，数据落到 D1/KV，附件可以放 R2，发信用 Resend 这类第三方服务补上。
先把丑话说前面：邮箱不是玩具。它经常是账号找回、验证码、账单通知、登录提醒的入口。部署成功只代表“能跑”，不代表“从此万无一失”。正式使用前至少想清楚：
- 域名必须稳定托管在 Cloudflare
- 管理员账号别乱填，
jwt_secret别用示例值 - 收件、发件、附件、备份都要单独验证
- 重要账号别一上来全部迁进去
- 对送达率有强要求时，别幻想自建服务能立刻打赢成熟邮箱厂商
这篇文章做五件事：
- 准备域名、Cloudflare 和 GitHub
- Fork Cloud Mail 项目，并从 Cloudflare 控制台部署 Worker
- 绑定 D1/KV/R2，补齐环境变量
- 配置 Email Routing，让域名邮件进 Worker
- 初始化系统，注册管理员，再补上发信、附件和安全配置
0. 先讲清楚：Cloud Mail 是什么 #
Cloud Mail 的定位很直接：一个基于 Cloudflare Workers 的轻量域名邮箱服务。
它不是 Gmail、Outlook、企业微信邮箱那种完整邮箱平台，也不是传统意义上自己维护一整套邮件服务器。它更像是把几块 Cloudflare 托管能力拼起来：
- Workers：跑后端接口和前端入口
- Email Routing / Email Workers：接收发到你域名的邮件
- D1：保存用户、邮件、系统配置这类结构化数据
- KV：保存缓存或默认附件数据
- R2：更适合长期保存附件
- Resend：承担发信通道
适合它的人：
- 已经有自己的域名
- 想要几个好看的域名邮箱地址
- 不想为了邮箱专门养 VPS
- 能接受 Cloudflare 生态里的配置工作
- 对“自托管服务需要自己负责维护”这件事有心理准备
不太适合它的人：
- 需要稳定企业级送达率
- 需要完整 IMAP/SMTP 客户端生态
- 不想碰 DNS、Worker、D1、KV 这些东西
- 准备把所有核心账号恢复邮箱立刻切过去
一句话：Cloud Mail 解决的是“我想低成本拥有自己的域名邮箱 Web 服务”，不是解决“我从此不用理解邮件系统了”。
1. 准备工作：先把地基打好 #
你需要准备这些东西：
- 一个自己的域名
- 一个 Cloudflare 账号
- 一个 GitHub 账号
- 能正常访问 Cloudflare 和 GitHub 的网络环境
- 一个 Resend 账号（如果要发信）
- 一个 R2 存储桶（如果要更认真地处理附件）
域名在哪里买都行，Spaceship、Cloudflare Registrar、Namesilo 都可以。关键不是在哪里买，而是这个域名要能托管到 Cloudflare，因为收信那条链路要用 Cloudflare Email Routing。
Cloudflare 账号这里最好提前完成必要的验证。D1、KV、Workers 都属于 Cloudflare 的常规能力，R2 和部分发信能力可能会遇到账号验证或地区开放情况。别等部署到一半才发现账号功能没开，那种挫败感很不值。
2. Fork 项目：先把代码放到自己名下 #
项目地址：
打开项目后，点击右上角 Fork，把仓库复制到自己的 GitHub 账号下。
这么做不是为了“仪式感”，而是为了后面让 Cloudflare 从你的仓库构建和部署。更重要的是，项目更新时你可以自己决定什么时候同步上游，而不是把线上邮箱交给别人的每一次提交。
官方文档也放这里，后面页面路径如果变了，优先看官方文档：
3. 创建 Worker：让 Cloudflare 替你跑邮箱入口 #
打开 Cloudflare Dashboard，进入：
Workers & Pages -> Create
选择从 GitHub 导入项目，授权后选择你刚刚 Fork 出来的 cloud-mail 仓库。
这里最容易漏的是目录：Cloud Mail 的 Worker 项目在仓库里的 mail-worker 目录，不是仓库根目录。部署页面里如果让你选择 Root directory，就填：
mail-worker项目的 wrangler.toml 里已经写了前端构建命令，会从 mail-vue 打包静态资源，再跟 Worker 一起部署。正常情况下按项目配置走就行，别一上来手动改一堆命令。你现在要的是先跑通，不是把部署系统改造成迷宫。
部署完成后，Cloudflare 会给你一个 Worker 访问地址。这个地址能打开只是第一步，后面还要补变量、绑定数据库、接邮件路由，不然它只是一个没接水管的水龙头。
4. 绑定自定义域名：别长期用 workers.dev #
邮箱这种服务，别长期挂在 workers.dev 上。你至少应该给 Web 入口绑定一个自己的子域名，比如：
mail.your-domain.com路径大概是：
Workers & Pages -> 你的 Cloud Mail 项目 -> Settings -> Domains & Routes -> Add Custom Domain
如果域名已经托管在 Cloudflare，通常按提示点完就会自动处理 DNS 和证书。等状态变成 active 后，用浏览器打开：
https://mail.your-domain.com这就是后面访问 Cloud Mail 管理界面的入口。
注意区分两个东西：
mail.your-domain.com：Cloud Mail 的网站入口your-domain.com：你真正收发邮件的邮箱域名
它们可以有关联，但不是同一个概念。别把这两个变量混在一起，不然后面排查会很痛苦。
5. 配环境变量：别让系统猜你的域名 #
进入 Worker 设置：
Settings -> Variables and Secrets
至少补三项：
domain=["your-domain.com"]
admin=admin@your-domain.com
jwt_secret=<一段足够长的随机字符串>domain 是邮箱域名，可以配置多个。admin 是管理员邮箱。jwt_secret 是登录身份令牌密钥，正式环境别用教程里的示例值，也别随手打 123456。
可以本机生成一个：
openssl rand -base64 48这里我建议：
domain用普通变量admin用普通变量jwt_secret用 Secret
保存后重新部署一次，让配置真正进到 Worker 运行环境里。很多“我明明填了为什么不生效”的问题，本质都是忘了重新部署。
6. 绑定 D1 和 KV：名字别改，真的别改 #
Cloud Mail 需要 D1 和 KV。到 Cloudflare 里分别创建：
- D1 数据库
- KV 命名空间
然后回到 Worker 的绑定配置里添加 Binding。关键点在名字：
D1 binding name: db
KV binding name: kv这两个名字按项目约定来，不要改成 cloud_mail_db、mail_kv 这种“更有语义”的名字。代码找的是 db 和 kv，你改得再优雅，它也不认识。
如果你要使用 R2 保存附件，再创建一个 R2 bucket，并绑定：
R2 binding name: r2R2 不是第一分钟必须配，但如果你准备长期用，尤其要收发附件，建议早点上。附件默认走 KV 也能跑，但 KV 更像“先能用”的方案，不是长期堆文件的舒服姿势。
7. 设置 Email Routing：让邮件真的进来 #
到你的域名页面：
Cloudflare Dashboard -> 你的域名 -> Email -> Email Routing
第一次使用时，Cloudflare 会引导你启用 Email Routing，并要求添加 MX、TXT 之类的 DNS 记录。如果域名 DNS 已经在 Cloudflare，一般按页面提示确认就行。
然后配置 Catch-all 路由，把发到这个域名的邮件交给 Worker：
Email Routing -> Routing rules -> Catch-all address -> Send to Worker
选择你的 Cloud Mail Worker。
到这里，外部发给：
anything@your-domain.com理论上都会先进入 Cloudflare，再转给 Cloud Mail 处理。这个设计很方便，但也意味着你要小心开放注册和滥用问题。域名邮箱一旦被乱用，难受的不只是系统日志，还有域名信誉。
8. 初始化系统：别忘了这条 URL #
完成变量、数据库和邮件路由后，打开初始化地址：
https://mail.your-domain.com/api/init/你的jwt_secret这个步骤会初始化或更新数据库结构。看到成功提示后，再打开：
https://mail.your-domain.com然后注册管理员账号。这里要注意：管理员邮箱最好跟你前面配置的 admin 对齐，比如：
admin@your-domain.com先别急着给所有人开户。用管理员账号登录后，先做一轮最小验证：
- 能不能收一封外部邮件
- 邮件正文能不能正常显示
- 附件能不能收
- 新用户能不能正常创建
- 删除、查询、权限这些基础操作是否符合预期
这一轮跑完，再进入“把它当正式邮箱用”的阶段。
9. 发信：按项目文档先接 Resend #
收信靠 Cloudflare Email Routing，发信就不是同一回事了。
按 Cloud Mail 当前文档，常规发信路径是接 Resend。大致流程是：
- 注册 Resend
- 在 Resend 添加你的发信域名
- 按 Resend 提示补 DNS 记录并完成验证
- 创建 API Key
- 回到 Cloud Mail 系统里配置发信服务
- 设置发送状态回调：
https://mail.your-domain.com/api/webhooks这里别偷懒。发信能力不是“能点发送按钮”就完事，你至少要测：
- 发给 Gmail / Outlook / QQ 邮箱是否能收到
- 是否进垃圾箱
- SPF、DKIM、DMARC 是否都按发信服务要求配置好
- 附件发信是否正常
- 退信或失败状态能不能看到
Cloud Mail 的 wrangler.toml 里也预留了 Cloudflare 发件绑定配置。这个能力是否可用，取决于你账号当前能不能使用相关功能。最稳的写法是：以官方文档和你控制台实际开放的能力为准，别靠一篇旧教程硬猜。
10. 可选配置：附件、人机验证和转发 #
10.1 R2 附件存储 #
如果你要收发附件，R2 更适合长期用。配置时记住两件事：
- Worker 绑定名用
r2 - 系统里确认附件存储已经切到 R2
附件最怕“看起来上传成功，其实下载不了”。测试时别只传一个小 txt，至少测一张图片、一个 PDF、一个稍大的压缩包。
10.2 Turnstile 人机验证 #
如果你开放注册，建议接 Turnstile。邮箱系统一旦被批量注册，后面清理用户、邮件和滥用记录会很烦。
Turnstile 的思路很简单：
- 在 Cloudflare Turnstile 创建站点组件
- 拿到 Site Key 和 Secret Key
- 回到 Cloud Mail 里配置
不开放注册的话，这一步可以晚点做。但只要你准备让别人用，就别省。
10.3 邮件转发 #
Cloud Mail 支持把收到的邮件转发到 Telegram 机器人或其他邮箱。
Telegram 这条路适合做提醒，比如“有新邮件了”。但它不适合承载敏感邮件全文，尤其是验证码、账单、账号通知这种内容。能推标题就别推全文，能做提醒就别做二次泄露。
转发到其他邮箱时，也要确认 Cloudflare 和目标邮箱侧都允许这条链路。邮件系统最真实的一点就是：你以为自己配置完了，收件方未必买账。
11. 常见翻车点 #
11.1 Worker 打开了，但登录或接口异常 #
先查三件事：
domain、admin、jwt_secret是否已经保存- D1 绑定名是否是
db - KV 绑定名是否是
kv
如果刚改完变量，重新部署。别在旧部署上刷新到怀疑人生。
11.2 收不到邮件 #
优先检查 Email Routing：
- 域名是否已经启用 Email Routing
- MX/TXT 记录是否按 Cloudflare 要求配置
- Catch-all 是否已经 Send to Worker
- 选中的 Worker 是否就是 Cloud Mail
如果只给某个地址建了规则，但你测试的是另一个地址，那它当然不会进来。Catch-all 能减少这种低级错，但也要注意滥用风险。
11.3 初始化地址打不开 #
检查你的自定义域名和 jwt_secret。初始化地址是：
/api/init/你的jwt_secret不是 /init，也不是拿管理员密码初始化。这里填错，系统不会因为你很真诚就自动理解。
11.4 发信成功率不理想 #
先别怪 Cloud Mail。发信送达率主要看发信服务、域名认证、内容质量和收件方策略。
该查的东西：
- Resend 域名是否验证完成
- SPF、DKIM、DMARC 是否正确
- 邮件内容是否太像营销垃圾
- 新域名是否没有发信信誉积累
域名邮箱最容易让人误会的一点是：收信能跑很快，发信能送稳很难。这不是 Cloud Mail 独有的问题，是邮件系统本身就很现实。
11.5 附件下载失败 #
先看你到底用的是 KV 还是 R2。再看：
- R2 bucket 是否存在
- Worker 绑定名是否是
r2 - 自定义域名或公开访问策略是否配置正确
- 上传和下载是不是走同一套存储配置
附件问题不要只看前端提示，Cloudflare Worker 日志会更诚实。
12. 我的结论：域名邮箱能轻量，但不能随意 #
Cloud Mail 的优点很明显：不用自己维护传统邮件服务器，部署成本低，界面完整，还能把收信、附件、发信、转发这些能力拼起来。
但它也不是“免费企业邮箱平替”。你真正要负责的是这些事：
- DNS 配对
- Worker 配置
- 数据库和存储绑定
- 发信服务认证
- 账号权限和开放注册
- 备份与迁移预案
如果你只是想给自己的域名配几个邮箱地址，收验证码、收通知、做轻量个人使用，Cloud Mail 是个很有意思的方案。它不要求你养服务器，也不逼你每个月为了几个邮箱付一笔企业套餐钱。
但如果这个邮箱要承载业务客户、关键账单、团队协作和高要求送达率，那就别硬省。邮箱这东西，能跑是第一层，稳定、可恢复、可送达，才是后面的真功夫。