零成本搭建域名邮箱：Cloudflare Email Routing + Workers 实现无限别名收信与发信

如果你也和我一样，注册任何网站都习惯用一个独立邮箱前缀，那么迟早会面对一个问题：这个前缀要不要去邮箱服务商后台一个个建账号？真的要为了 marketing@、support@、hr@ 这种地址去租一台服务器、买企业邮箱套餐，或者自己鼓捣一套邮件系统吗？答案是不用。我过去两年一直在用 Cloudflare 的 Email Routing 和 Workers 搭建自己的域名邮箱系统，收件别名基本无限，整套基础设施的成本为零。所谓零成本，不是指域名免费，而是指邮件系统本身不需要再掏钱——Cloudflare 不会按邮箱数量收费，也不会因为你多转发了几封邮件就找你要钱。这篇文章就把这套方案完整拆开，从原理到实操，从收件到发件，从踩坑到进阶，一步一步带你复刻出来。

1. 为什么我不再自建邮箱服务器

1.1 自建邮件服务器的真实成本

很多人在搭建域名邮箱时会走一条最重的路：自己买一台 VPS，装 Postfix、Dovecot，配数据库，做 Web 管理面板。真正做过这件事的人都知道，这绝对不是“一个周末就能搞定”的项目。邮件服务器和普通 Web 服务完全是两个物种，它牵扯到反向 DNS、固定 IP、25 端口放行、MX 记录、SPF/DKIM/DMARC 三条 DNS 记录的配合、发信 IP 信用的积累、垃圾邮件过滤、病毒扫描、用户账户管理、邮件存储备份，还有 TLS 证书和定期安全更新。

这些环节里，任何一环出了问题，最终的表现都极其难排查。最常见的结果就是：你发出去的邮件被别人当成垃圾邮件，或者直接被对方拒收。我见过太多人打开邮箱后台，看到自己发的信全部进了 Gmail 的垃圾箱，然后开始怀疑是不是排除了 DNS 的 A 记录，实际上问题可能出在 IP 信誉上。自建服务器最尴尬的一点是，你的 VPS IP 往往是个共享的、名声一般的机房地址，今天能用，明天可能就被 RBL（实时黑名单）列进去，你又得花两周去申诉。

所以我的结论很明确：除非你有能力长期维护邮件基础设施，否则不要自建。自建邮箱这件事，表面看是省钱，实际是把运维成本、时间成本和邮件投递率风险全吞了。

1.2 Cloudflare 邮箱路由解决了什么

Cloudflare 的 Email Routing 是一个免费功能，它的工作逻辑非常清晰：把你域名下收到的邮件，通过 MX 记录接收进来，再根据你设定的规则转发到真实的收件邮箱。整个过程不需要你安装任何软件，不需要提供存储空间，也不需要处理邮件队列。

它的设计思路很聪明。传统的邮件系统是先有“账号”再有“邮箱”，你得为每个业务地址创建用户，配置密码、存储配额、别名列表。而 Email Routing 反过来了：你只需要定义一条规则，它负责把发到某个地址的邮件“转交”给真实邮箱，真实邮箱仍然托管在 Gmail、Outlook、QQ 邮箱、企业邮局等任何你习惯的平台上。你的域名成为一个“入口”，而不是一个“仓库”。

这让域名邮箱的建设成本直接被压缩到接近零：不需要自己在服务器上维护任何收信端，不需要配置特快专用的邮件端口，不需要为每 GB 存储付钱。Cloudflare 同时还负责处理域名下 MX 记录的自动添加，你只需要点击几个按钮。

1.3 无限别名到底怎么个“无限”法

“无限别名”这个词很容易被误解。很多人以为无限别名是指“可以创建无限多个映射列表”，但 Email Routing 的做法完全不同。它里面有一个叫 Catch-All（捕获全部）的开关，打开之后，理论上任何任意字符串@你的域名的地址都会被这个规则接收。

也就是说，你不必提前创建support@、billing@、newsletter@这些账号，它们在邮件到达的那一瞬间天然存在。anything-you-like@mydomain.com和another.alias@mydomain.com都可以被 Catch-All 接住，然后统一转发到同一个目的地，或者交给程序做进一步分发。这就是“无限”的本质：别名不是一个一个账号，而是路由规则里的一个通配符。

这也意味着你可以在注册网站时随手编一个前缀，比如taobao@mydomain.com、amazon@mydomain.com，不必预先申请，就能收到邮件。如果哪天某个网站开始疯狂发垃圾宣传邮件，你只需要把对应前缀的那条规则删掉，或者直接在目标邮箱里对该前缀做过滤，立刻就能切断骚扰源。

2. 动手前要准备什么

2.1 域名和 DNS 托管要求

这套方案的第一步，是先有一个域名，并且让 Cloudflare 来接管这个域名的 DNS 解析。域名本身是需要成本的，不过通常一年几十元，比起企业邮箱按账号数收费的套餐，几乎可以忽略。我假设你已经注册好了域名，并且在 Cloudflare 后台成功添加了站点。

添加站点完成后，Cloudflare 会让你修改域名的 NS 记录，把这组 DNS 服务器的地址填到你注册商的后台。NS 生效时间取决于注册商，快的十几分钟，慢的可能几个小时内完成。等到 Cloudflare 首页显示站点的状态从 Pending 变成 Active，并且在 DNS 管理里能看到 Cloudflare 分配的解析服务器时，才算真正把 DNS 托管交接过来。

有一个容易忽略的点：如果域名之前在其他 DNS 服务商那里用了很久，建议先导出一份完整的解析记录，特别是有 MX 记录、其他子域名的记录，否则切换之后站点的邮件和子域名服务可能会中断。Cloudflare 在添加站点时会自动尝试扫描并导入现有记录，但自动导入不一定完整，最好手动核对一遍。

2.2 创建一个规划用的路由表

在开始配置之前，我强烈建议先花五分钟列一张表格。因为 Catch-All 一旦打开，你会收到所有前缀的邮件，如果没有提前规划，后期管理会非常混乱。我自己的规划表长这样：

不要小看这一步。有了这张表，你后面配置路由规则时就不会“想起一个加一个”，而是能很快对应上业务需求。尤其是当你需要给团队成员分配邮箱时，提前规划能避免把同事的邮箱和你的主邮箱混在一起。

2.3 Cloudflare 账号与邮箱验证

直接在 Cloudflare 官网注册账号即可。注册后进入域名管理页，在左侧菜单里会有一个 Email 相关的入口，点击进去就能看到 Email Routing 的开关。如果你第一次使用，系统会提示你启用这个功能，这个过程需要你输入一个目标邮箱，也就是你希望这些别名邮件最终寄到的真实邮箱。

目标邮箱可以是任意我们能正常收信的邮箱，Gmail、Outlook、QQ 邮箱、163 邮箱都可以。Cloudflare 会向这个邮箱发送一封验证邮件，你必须点开并确认，才能在后续配置里使用它作为转发目标。这个验证是强制性的，原因也很简单：防止有人把别人的邮箱设置为转发目标，造成隐私泄露或垃圾邮件。

这一步不用着急，验证邮件一般几分钟内到达。如果没收到，去垃圾箱看一眼，有时会被误判。

3. 核心操作：让每个别名都“活”起来

3.1 打开 Email Routing 并绑定目标邮箱

进入域名的 Email Routing 页面后，点击 Get started（开始使用）。Cloudflare 会检测域名当前是否有 MX 记录，如果检测到旧记录，会给出警告，询问你是否确认接管邮件路由。这里要仔细看：如果你之前已经在别的服务商那里配置了邮箱服务，并且还需要它，不要贸然点击覆盖。对我们这套新方案来说，如果域名之前没有用过邮件，直接确认接管即可。

接着在 Destination address 栏里填入你的目标邮箱，点击发送验证邮件。去目标邮箱里找到 Cloudflare 发出的确认信，点击验证链接，回到后台刷新页面，就能看到该邮箱变成了可用状态。

Cloudflare 会在这个过程中自动为该域名添加 MX 记录和一段自动生成的 SPF 记录。MX 记录指向它自己的邮件网关，SPF 记录则用来告诉外界“我这个域名的邮件确实由 Cloudflare 负责处理”。这一步在后台的 DNS 记录里都能看到，不需要手动操作。

3.2 开启 Catch-All 实现“无限别名”

在 Email Routing 页面里，有一个 Catch-all 区域，默认是 Off 状态。把它打开，下方会让你选择处理方式：一种是转发到一个目标邮箱，另一种是发送到一个 Worker 程序。如果你只是想快速体验无限别名，直接选择“转发到目标邮箱”，然后选你刚才验证过的那个邮箱作为兜底地址。

开完这个开关后，你就已经拥有了一个真正意义上的“无限别名收件系统”。所有没有额外定义规则的任意前缀@你的域名，都会自动进入你的目标邮箱。这时候你可以打开任意一个邮箱客户端，从外部邮箱向test-2025@你的域名发一封邮件，一会儿就能在目标邮箱里看到它。

有一个优先级规则要记住：在 Email Routing 里，你手动定义的“自定义地址”（比如你单独创建了一个 hr@），优先级高于 Catch-All。换句话说，Catch-All 是最后一道兜底，自定义地址是精确匹配。理解了这个顺序，你才能设计出清晰的路由逻辑。

3.3 配置自定义路由规则

在 Custom addresses 区域，可以添加单独的路由规则。比如我想把发给billing@mydomain.com的邮件直接转给财务同事的邮箱，就可以创建一条自定义地址billing@mydomain.com，转发目标选财务同事的邮箱。这条规则的生效优先级高于 Catch-All。

自定义规则非常适合固定业务场景：联系客服的support@、接收简历的jobs@、对外公关的press@。每条规则都可以独立管理，想停掉某个业务邮箱，不需要删除“账号”，只需要删掉对应规则或者把转发目标换个方向，整个流程在界面操作上非常直观。

如果你有很多规则需要在代码层面控制，也可以把 Catch-All 指向一个 Worker，让程序来决定每个前缀转发到哪个邮箱。这个我稍后在第 5 章详细展开。

3.4 测试邮件怎么发，效果才算“真”

很多人测试的时候只给自己发同一封邮件，看不出问题。我建议做一组最小测试：用一个外部邮箱（不是你的目标邮箱）分别向三个地址发信，分别是info@你的域名、billing@你的域名、abc123@你的域名，然后观察目标邮箱是否都收到了。

这一步的目的是同时验证自定义规则和 Catch-All。如果只测了自定义地址，你会误以为 Catch-All 也自动生效了。如果只测了 Catch-All，自定义规则的问题又会被掩盖。两边都测到，心里才有底。

4. 不解决发信问题，这套方案只完成了一半

4.1 为什么收信免费但发信要借道

Email Routing 只解决“收信”这件事。它接收别人发到你域名下的邮件，再转发给真实邮箱，但它不提供 SMTP 发信服务。这意味着你没法直接通过 Cloudflare 的这套系统从yourname@你的域名向外部发邮件。

很多人在这里会卡住：收件已经无限别名了，但是要回复客户、要发通知，总不能一直用目标邮箱的原始地址发吧？我当时的解决方案，是引入一个发信服务商，用 API 或标准 SMTP 协议来发送来自你域名的邮件。这样发件人地址依然是你自己的域名，看起来完全“企业级”。

这里必须提醒一句：以前很多人推荐的 MailChannels 免费发信服务已经停掉了，网上大量旧教程还在用它，照着做只会得到一个无效的 API Key，别再浪费时间。目前我自己的选择是 Resend，它有免费额度，配置简单，并且自带 SPF/DKIM 的 DNS 指引，适合个人和企业邮箱场景。

4.2 选一个发信服务：我为什么用 Resend

Resend 是一家面向开发者的邮件发送服务，你可以把它理解为一个“邮件代发 API”。你不需要维护邮件服务器，只需要调用接口，它就会从你验证过的域名替你发信。它的免费套餐足够一个人或者小团队日常使用，大概每月有几千封的量级，具体以官网最新说明为准。

接入流程很直接：注册账号后，在后台添加你的域名。它会生成三条 DNS 记录，让你手动加到 Cloudflare 的 DNS 管理里，包括 SPF 和 DKIM。加完之后点击验证，域名状态变成 Verified，之后就可以用这个域名发信了。

你会注意到一个细节：Resend 要求的 SPF 记录，和 Cloudflare Email Routing 自动生成的 SPF 记录，在同一个 TXT 下可能会冲突。原因在于一个域名只能有一条 SPF 记录，如果你新增一条而不合并原记录，DNS 校验会失败，邮件很可能被判定为伪造或投递失败。正确的做法是编辑 Cloudflare 自动生成的那条 TXT 记录，把 Resend 的 include 追加进去，而不是另起一行。合并后的效果类似：

v=spf1 include:_spf.mx.cloudflare.net include:amazonses.com ~all

4.3 完整配置 SPF、DKIM、DMARC

SPF 的作用是声明“哪些服务器有权限以你的域名发信”。DKIM 则是给邮件附加一段加密签名，证明邮件在传输过程中没有被篡改。DMARC 是一份收件方可以查询的处置策略。三者配合，邮件系统才算完整可信。

在 Resend 的添加域名流程里，它给你跳转出来的就是 SPF 和 DKIM 记录。把它们手动填到 Cloudflare DNS 里，其中 DKIM 记录的主机名通常是resend._domainkey.你的域名，类型为 TXT，值是一长串加密字符串。如果填写正确，验证会在几分钟到几小时内完成。

DMARC 记录建议你顺手加上。新建一个主机名为_dmarc.你的域名的 TXT 记录，内容如下：

v=DMARC1; p=quarantine; rua=mailto:dmarc@你的域名

加这条记录的意义在于，如果未来有人伪造你的域名发邮件，收件服务器会按照quarantine策略把伪造邮件隔离，而不是投递到用户收件箱。你也就能通过rua指定的邮箱收到聚合报告，及时发现异常。

4.4 用 Workers 做一个自己的“发信接口”

收件解决了，发信服务商也接好了，下一步是把发信能力变成自己的工具。Cloudflare Workers 是运行在边缘的轻量函数，用它包一层统一发信接口非常方便。

我写了一个最简版本的 Worker 函数，支持接收 POST 请求，携带收件人、主题和 HTML 内容，然后调用 Resend 的 API 发信：

export default { async fetch(request, env) { if (request.method !== 'POST') { return new Response('Method Not Allowed', { status: 405 }); } const { to, subject, html } = await request.json(); const res = await fetch('https://api.resend.com/emails', { method: 'POST', headers: { 'Authorization': `Bearer ${env.RESEND_API_KEY}`, 'Content-Type': 'application/json' }, body: JSON.stringify({ from: 'no-reply@你的域名', to, subject, html }) }); const data = await res.json(); return new Response(JSON.stringify(data), { headers: { 'content-type': 'application/json' } }); } };

部署完成后，在 Worker 的设置页面里添加一个环境变量，名称写RESEND_API_KEY，值填你从 Resend 后台复制的那串 Key。切记不要把密钥硬编码到代码里，通过环境变量引用，将来换 Key 或者给同事分配权限都方便得多。

这个接口建议做一层鉴权。最简单的做法是在请求头里约定一个固定令牌，只有携带正确令牌的调用方才能触发发送。否则你的 Worker 一旦被恶意刷接口，就会变成垃圾邮件发送器，不仅消耗免费额度，还可能拖累域名信誉。

4.5 日常回信体验：不是所有回信都要走 API

Workers 发信接口适合系统通知、工单回复、自动确认这类场景。如果是普通的人工回信，不需要每次都调 API。你可以直接在你使用的目标邮箱客户端里，把“发件人地址”配置成你的域名地址。比如 Gmail 里就有“用其他地址发送邮件”的功能，你把someone@你的域名添加进去，并填写 SMTP 配置指向 Resend 的服务器，之后在 Gmail 回复客户邮件时，就可以直接选择用域名地址发出。

这种方式的好处是，你的整个工作流还是停留在熟悉的邮箱客户端里，不需要切换到命令行或者 Postman。缺点是需要额外配置一次 SMTP 参数，并且不同客户端界面差异较大，一次性设置好了，后续使用反而最省心。

5. 进阶：用 Worker 把邮箱系统变成自动化管道

5.1 邮件进入 Worker 做自动分类

Catch-All 还有一个非常强的选项：“发送到 Worker”。开启之后，所有到达你域名的邮件都会先进入一段 JavaScript 代码，由代码决定转发、丢弃或回复。这等于把邮箱系统变成一个可编程入口。

有一段示例代码，展示了如何按照前缀把邮件归类：

export default { async email(message, env, ctx) { const toAddress = message.to.toLowerCase(); if (toAddress.startsWith('billing@')) { await message.forward('caoye@target.com'); } else if (toAddress.startsWith('hr@')) { await message.forward('hr-team@target.com'); } else if (toAddress.startsWith('spam')) { message.reject('blocked'); } else { await message.forward('inbox@target.com'); } } };

这段逻辑的含义很简单：billing前缀转给财务邮箱，hr前缀转给人力邮箱，spam开头的前缀直接拒绝，剩下的统一进主收件箱。你在创建 Email Worker 的时候，把这段代码贴进去，然后在 Email Routing 的 Catch-All 区域选择对应的 Worker，就能替代原来的静态转发规则。

它的意义在于，路由规则不再需要你一条条手动维护。你可以基于前缀、发件人、甚至是邮件标题里的关键字来做动态决策，完全由代码控制，调整逻辑只需部署一次。

5.2 自动回复与 Webhook 通知

邮箱 Worker 不仅能转发邮件，还能调用其他 API。最常见的场景是自动回复：客户往support@你的域名发了一封邮件，Worker 收到后先回一封“已收到，会在 24 小时内处理”的模板邮件，同时向你的企业内部群机器人发一个 Webhook 通知，提醒你有一封新工单。

这样做的好处是，你不需要时刻盯着邮箱，也能保证客户在第一时间收到确认反馈。模板确认邮件和人工回复邮件是两码事，前者是体验，后者是解决问题。

我建议自动回复的模板要克制，不要写长篇大论，一两句话说明已经收到、预计响应时间、是否需要提供更多材料，就够了。过度设计的自动回复邮件反而会让客户觉得没人处理。

5.3 防滥用和垃圾邮件的几个铁律

开启 Catch-All 之后必然面临一个问题：会有大量随机爆破的前缀地址涌入。邮件爬虫和垃圾发送者经常会枚举admin@、test@、info@这类常见前缀，给你发送钓鱼邮件。所以，防垃圾策略必须同步上线。

我的经验是三条铁律组合使用。第一，精确地址优先原则：公司重要的业务邮箱尽量使用自定义规则，而不是依赖 Catch-All。第二，Worker 里做来源域名白名单或黑名单判断，对明显来自可疑域名的邮件直接reject()，不进入真实收件箱。第三，你的 Worker 发信接口必须鉴权，绝不能让外部匿名调用你的发信能力。

还有一个容易被忽略的点：不要轻易把邮件转发到无法验证的第三方地址。Email Routing 对转发目标有一定的验证要求，这是保护机制。即便你可以通过 Worker 自由控制转发对象，也必须确认目标地址是自己的或经过对方确认的，否则会变成开放的邮件转发器。

6. 我踩过的坑和排查清单

6.1 邮件全部进垃圾箱

这个问题 90% 出在 SPF 或 DKIM 配置上。我第一周测试时，发给 Gmail 的邮件全部被丢进垃圾箱，检查之后发现，SPF 记录没有合并，域名下同时存在两条 SPF TXT 记录，这直接被收件方判定为 SPF 错误。删掉其中一条、合并 include 之后才恢复正常。

另一个常见原因是域名刚启用，发信 IP 信誉还不高。这种情况没有捷径，只能用固定发信服务持续发一段时间，逐步积累信誉。不要今天用 Resend 发，明天换 SendGrid，后天又换别家，频繁更换发信服务商对域名信誉伤害很大。

6.2 测试邮件一直收不到

先看目标邮箱的垃圾箱和隔离区。很多邮箱服务商不认识海外邮件转发域名，第一封邮件会被隔离。确认地址验证链接有没有点完，否则 Email Routing 后台显示“未验证”，即使 Catch-All 开着也不会投递。

再看 DNS 里的 MX 记录。如果域名的 MX 记录还指向旧服务商，邮件会走旧链路，收不到非常正常。启用 Email Routing 时，Cloudflare 会自动添加 MX 记录，但如果你之前手动改过，需要检查是否冲突。

6.3 Email Worker 没有触发

Worker 没有触发，首先检查 Catch-All 区域的处理方式是否真的选择了那个 Worker。如果你在 Custom addresses 里也配置了相同前缀，精确规则会优先于 Catch-All，导致邮件进不了 Worker。

另外注意，Cloudflare Email Worker 和普通 HTTP Worker 的编写方式不同。普通 Worker 处理fetch，Email Worker 处理email方法。如果把两种代码结构搞混，控制台不会报错，但邮件会静默失败。

6.4 免费额度比想象中够用

Cloudflare Workers 免费计划每天有大量请求额度，只用来处理邮件转发和调 API，个人台账非常充足。Resend 免费计划对日常收信恢复和系统通知也够用。这里的“零成本”并不是一句空话，但如果你打算用这套系统群发几十万封营销邮件，那我劝你老老实实去买一个专门的邮件营销服务，任何免费方案都承受不住这种量级，还会把域名信誉搞垮。

7. 常见问题速查表

这些坑不是看文档能完全避开的，尤其是 SPF 合并、Worker 代码结构、验证邮件点确认这三件事，几乎每个人都会栽一次。把这章截图保存下来，配置出错时对照排查，能省下大把时间。

我个人在实际操作中的体会是：这套系统最厉害的地方不是“免费”，而是“所有权”。收件和发件都在你自己域名的控制范围内，规则由你写，入口由你管，出口由你定义。你注册网站、订阅服务、给客户留联系方式时，不再是某个人邮箱的地址，而是一个完全由你掌控的域名入口。我用它给数百个不同平台分配了独立别名，后来某几个平台开始频繁发促销垃圾，我直接把对应前缀的转发规则关掉，主收件箱从此干干净净。第一周你会觉得这样只是省了企业邮箱的钱，用久了你才发现，这是一个可以随意编程、随时收缩和扩张的邮件基础设施。