玩转Cloudflare-16：不租服务器、不买企业邮箱：我用 Cloudflare 白嫖了一套域名邮箱

玩转Cloudflare-16：不租服务器、不买企业邮箱：我用 Cloudflare 白嫖了一套域名邮箱

导读：手里有域名的话，收发邮件这套活儿 Cloudflare 的免费额度基本能全包——这篇把成本、额度、动手前必须想清楚的三件事，还有我自己踩过的坑，一次讲完。

前阵子群里有人问我：公司想搞个@自己域名.com的邮箱，企业邮箱的报价单一发过来，按人头算，十几个人一年就是小几千。

我回了句：你有域名吧？

有域名的话，这笔钱其实可以先不花。

不是让你去薅什么灰色资源，是有个项目把「邮箱服务」这件事，整个搬到了 Cloudflare 的免费额度里。没有服务器，没有月租，也没有按人头收费。

项目叫Cloud Mail。

免费 一、先把钱算清楚：到底省的是什么

我不喜欢「零成本」这种说法，因为它总会漏掉一个前提。这里的前提很明确——域名本身要钱。

.com一年几十块，.xyz之类的首年更便宜。这是唯一一笔绕不过去的硬支出。除此之外：

项目

实际花费

服务器 / VPS

0

，根本没买

邮箱系统本身

0

，MIT 开源

数据库、缓存、文件存储

0

，吃 Cloudflare 免费额度

发信通道

0

，Resend 免费档 100 封/天

附件存储

0

，R2 免费 10 GB

域名

几十块一年

所以准确的说法不是「零成本」，是**「除域名外零成本」**。

省下来的其实是两块：一是那台你本来要买的服务器，二是企业邮箱按人头收的那笔年费。

对个人和小团队来说，第二块才是大头。

二、Cloud Mail 是什么来路

我去翻了下仓库，数据比介绍里写的更有意思。

• • Star1.48 万，Fork 却2.25 万

• • 2025 年 4 月建仓，到现在一年半

• • 最新版本 v3.3.0，2026 年 9 月发的

• • 到今天（10 月 20 日）仓库还有新提交，没弃坑

• • MIT 协议，随便改随便用

Fork 数比 Star 还多，这在 GitHub 上不多见。原因很简单：这项目的官方推荐姿势就是「一键 fork 到自己账号，然后部署」，所以每一个真的装起来的人，都会在 Fork 计数上留一笔。

换句话说，这个数字不是「收藏了待会看」，而是「我确实动手了」。

仓库在这，自己去看：github.com/maillab/cloud-mail

另外提一句，它的前端是 Vue3 + Element Plus 写的，响应式做得挺规矩。我第一眼看到登录页的时候愣了一下，不太像个人开源项目的水平。

三、它到底能干什么

官方的功能列表挺长，我挑真正影响使用的说：

• •收信 + 发信：发信走 Resend，支持群发、内嵌图片、带附件，发出去还能查状态

• •附件：存 Cloudflare R2，收发都行

• •多号模式：一个账号下挂多个邮箱地址，像正规邮箱平台那样切换

• •验证码识别：用 Workers AI 直接读邮件里的验证码，不用点进去看

• •邮件推送：收到信自动转给 TG 机器人，或者转到你常用的邮箱

• •开放 API：批量建账号、按条件查邮件

• •后台管理：RBAC 权限、限制某个用户能用多少资源

• •数据看板：ECharts 画邮件增长曲线

• •人机验证：接的 Turnstile，防批量注册

对我来说，真正值钱的是验证码识别和多号模式。

前者是给自动化流程用的——注册、登录、找回密码，这些场景都要读验证码，以前得写一堆正则去抠，现在交给模型认，稳得多。

后者是给「一个人要管好几个身份」用的。做测试、跑爬虫、给不同业务分邮箱，一个面板全切完，不用来回登。

四、三件事必须先想清楚

这三条我翻文档翻了半天才理清楚，也恰恰是新手最容易卡住的地方。放在动手之前说。

第一，域名必须托管到 Cloudflare。

不是在 Cloudflare 加个域名记录就行，是要把域名的 NS（域名服务器）整个改成 Cloudflare 给的那两个。这一步不改，后面什么都做不了。

代价是：这个域名原来的解析记录会一起搬过去，得提前导出来，别改完发现网站打不开了。

第二，收信不是 Workers 自己收的。

它靠的是 Cloudflare 免费的Email Routing——这个功能专门负责接住发到你域名的邮件，然后再投递给 Worker 去处理。

所以流程是这样的：别人发到hi@你的域名，Cloudflare 接住，Worker 解析，存进 D1，附件丢进 R2。

Email Routing 本身不额外收费，配好就行。

第三，发信要靠 Resend，而且得验证域名。

Resend 不是填个 API Key 就能用。你得在它后台添加自己的域名，然后按它给的提示去 DNS 里加几条记录（SPF、DKIM 那一套），验证通过才能发。

这一步不做，代码跑起来也会一直报发信失败。

另外还有个小坑：默认给的xxx.workers.dev域名，国内访问经常不稳。正经用一定要绑自己的域名，别拿默认域名测完就以为成了。

五、部署方案 1.注册Cloudflare，并添加域名

操作略，如果没有账号，可以看星哥的其他文章

2.克隆仓库到自己的GitHub账号

点击 fork叉到自己的账号下

https://github.com/maillab/cloud-mail

3.cloudflare中新建worker项目

如图点击，worker和pages，创建应用程序

选择GitHub导入

4.设置目录 mail-worker，并部署

点击部署

5.设置环境变量

变量名

必需

用途

domain

邮箱域名,多域名用（例如["example.com","example2.com"]）

admin

管理员邮箱地址（例如admin@example.com）

jwt_secret

JWT密钥 随便输入一串字符串，不要输入特殊字符

6.创建KV和D1数据库

绑定数据库

7.添加绑定，变量名必须为kv和db

7.设置转发

接入域名

8.登录网站

浏览器输入 https://你的worker自定义域/api/init/你的jwt_secret 初始化数据库

六、发送邮件

报错：
发信服务未配置，只能给站内邮箱发件

原因

cloud‑mail 本身没有自建 SMTP 发信能力，外域发信依赖第三方邮件发送服务Resend；没有配置RESEND_API_KEY环境变量时，系统就会限制仅允许同域名站内互发，向外网邮箱发送就弹出该提示。接收邮件靠 Cloudflare Email Routing，发送邮件必须单独配置 Resend 才能对外发信。

1.打开 resend.com 注册账号

登录

2.并添加域名，完成DNS验证

免费的域名不支持

我就换一个域名

授权

1. 1. Resend 控制台 →Domains→Add domain，填入你的邮箱域名

2. 2. 根据 Resend 给出的记录，到你的域名 DNS 管理处添加SPF、DKIM、DMARC解析记录。

注意：如果域名托管在 Cloudflare，DKIM 记录的代理模式设置为 DNS only（仅 DNS），不要开启橙色云代理。

验证成功

等待 DNS 生效，Resend 页面显示域名Verified验证成功。

3.获取API Keys

进入API Keys→Create API key，生成密钥，复制保存好密钥字符串。

4.设置发送状态回调

 https://worker自定义域/api/webhooks

4. 测试

登录 cloud‑mail 网页，尝试发送邮件到外部邮箱（QQ/163 等），不再提示 “发信服务未配置” 即为修复成功。

免费额度到底够不够用

这是我最关心的部分，因为「免费」两个字最怕的是用到一半突然收费。

我把官方价格页翻了一遍，2026 年 10 月的口径是这样：

资源

免费额度

Workers 请求

10 万次/天

D1 数据库

500 万行读/天，10 万行写/天，5 GB 存储

KV 缓存

10 万次读/天，1000 次写/天，1 GB

R2 附件存储

10 GB/月，出站流量免费不限

Workers AI

1 万 Neurons/天

Resend 发信

100 封/天，3000 封/月

拿这个额度对一下实际使用：

收信，一天几百封都算多的，10 万次请求够你用很久。

发信，100 封/天是真正的天花板。自己用、小团队内部用完全够；要是拿它跑营销邮件，第二天就撞墙了。

附件，10 GB 是唯一我觉得可能顶到的地方。别人发来的大附件会一直躺在 R2 里，不清就一直占着。

验证码识别，1 万 Neurons 一天，具体消耗跟模型有关，按常见的识别量估算，一天认几百封问题不大。

结论：个人用绰绰有余，十几人的小团队也够，唯一要盯的是 R2 存储和每天的 100 封发信上限。

几个我必须提前说的坑

有几个地方是真的会让人翻车，不说清楚不厚道。

别动已经在用的邮箱。

如果这个域名上已经有企业邮箱在跑，千万别为了玩这个去改 MX 记录。改完的结果就是老邮箱全线收不到信，而且恢复起来很麻烦。

想试，拿一个子域名（比如mail.你的域名）单独试。

新域名发信，大概率进垃圾箱。

域名越新，发信 reputation 越差。发给 QQ、163 这些大厂邮箱，头几封很容易被判成垃圾邮件，甚至直接退信。

这不是项目的问题，是邮件这套老规矩决定的。慢慢养，别一上来就群发。

重要验证码别绑在这上面。

银行、支付、政务这类验证码，一旦漏收就是大事。自建邮箱出问题的概率不高，但也不是零——Cloudflare 抖一下、额度超了、代码更了一版，都可能让你收不到那封关键邮件。

我的建议：重要账号继续用大厂邮箱，自建这套拿来接不重要的、量大的、需要自动化的。

数据在你手上，备份也得你自己做。

这是自建的好处，也是代价。邮件都存在 D1 里，附件在 R2 里，哪天你想迁移，得自己去导出。

建议养成习惯：定期把 D1 导一份出来，丢到别的地方存着。

一键部署 = fork 一个仓库。

官方的部署按钮背后就是帮你 fork 一份到自己的 GitHub。这没问题，但要注意别把 API Key、Resend 的密钥写进公开仓库的代码里，那些应该放在 Cloudflare 的环境变量里。

cloud]‑mail适合谁

我列一下，对号入座就行。

适合：

• • 手里有域名，想搞个@自己域名的邮箱，又不想按人头付费的个人

• • 十几人的小团队，需要几个分部门的邮箱地址

• • 要跑自动化的人，需要能读验证码、能批量建号的邮箱

• • 做测试的，需要临时邮箱收注册确认信

不太适合：

• • 完全没域名、也不想买域名的（第一步就得掏钱，别被「免费」两个字骗了）

• • 要收重要验证码的（还是大厂邮箱稳）

• • 想拿它做营销群发的（100 封/天的上限，不够看）

• • 完全不懂 DNS 的（改 NS、加 SPF/DKIM，这几步绕不过去）

别一上来就把主域名的邮箱全搬过来。

先拿一个子域名试水，跑通收信、发信、附件、验证码这一整条链路，用一两周，觉得稳了再考虑扩大。

这中间你会遇到几个具体问题：DNS 记录加错、邮件进垃圾箱、附件传不上去。在一个不重要的子域名上踩这些坑，代价最小。

至于「值不值得折腾」，我的判断是这样：

如果你只是想要个@自己域名的邮箱，按官方的路子走，一小时之内能跑起来，之后基本不用管。这种情况下，折腾的成本远低于一年几千块的企业邮箱。

但如果你要的是一个「什么都能干、绝对不能出问题」的邮箱，那还是老实买企业邮箱。免费的东西，代价通常是你得自己当运维。