如果你也和我一样注册任何网站都习惯用一个独立邮箱前缀那么迟早会面对一个问题这个前缀要不要去邮箱服务商后台一个个建账号真的要为了 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-likemydomain.com和another.aliasmydomain.com都可以被 Catch-All 接住然后统一转发到同一个目的地或者交给程序做进一步分发。这就是“无限”的本质别名不是一个一个账号而是路由规则里的一个通配符。这也意味着你可以在注册网站时随手编一个前缀比如taobaomydomain.com、amazonmydomain.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 一旦打开你会收到所有前缀的邮件如果没有提前规划后期管理会非常混乱。我自己的规划表长这样别名用途转发目标info对外业务咨询team我自己的主邮箱press媒体对接me我的主邮箱admin系统通知me我的主邮箱任意前缀注册网站用catch-all 兜底到 me不要小看这一步。有了这张表你后面配置路由规则时就不会“想起一个加一个”而是能很快对应上业务需求。尤其是当你需要给团队成员分配邮箱时提前规划能避免把同事的邮箱和你的主邮箱混在一起。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 区域可以添加单独的路由规则。比如我想把发给billingmydomain.com的邮件直接转给财务同事的邮箱就可以创建一条自定义地址billingmydomain.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 选一个发信服务我为什么用 ResendResend 是一家面向开发者的邮件发送服务你可以把它理解为一个“邮件代发 API”。你不需要维护邮件服务器只需要调用接口它就会从你验证过的域名替你发信。它的免费套餐足够一个人或者小团队日常使用大概每月有几千封的量级具体以官网最新说明为准。接入流程很直接注册账号后在后台添加你的域名。它会生成三条 DNS 记录让你手动加到 Cloudflare 的 DNS 管理里包括 SPF 和 DKIM。加完之后点击验证域名状态变成 Verified之后就可以用这个域名发信了。你会注意到一个细节Resend 要求的 SPF 记录和 Cloudflare Email Routing 自动生成的 SPF 记录在同一个 TXT 下可能会冲突。原因在于一个域名只能有一条 SPF 记录如果你新增一条而不合并原记录DNS 校验会失败邮件很可能被判定为伪造或投递失败。正确的做法是编辑 Cloudflare 自动生成的那条 TXT 记录把 Resend 的 include 追加进去而不是另起一行。合并后的效果类似vspf1 include:_spf.mx.cloudflare.net include:amazonses.com ~all4.3 完整配置 SPF、DKIM、DMARCSPF 的作用是声明“哪些服务器有权限以你的域名发信”。DKIM 则是给邮件附加一段加密签名证明邮件在传输过程中没有被篡改。DMARC 是一份收件方可以查询的处置策略。三者配合邮件系统才算完整可信。在 Resend 的添加域名流程里它给你跳转出来的就是 SPF 和 DKIM 记录。把它们手动填到 Cloudflare DNS 里其中 DKIM 记录的主机名通常是resend._domainkey.你的域名类型为 TXT值是一长串加密字符串。如果填写正确验证会在几分钟到几小时内完成。DMARC 记录建议你顺手加上。新建一个主机名为_dmarc.你的域名的 TXT 记录内容如下vDMARC1; pquarantine; ruamailto: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 日常回信体验不是所有回信都要走 APIWorkers 发信接口适合系统通知、工单回复、自动确认这类场景。如果是普通的人工回信不需要每次都调 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(caoyetarget.com); } else if (toAddress.startsWith(hr)) { await message.forward(hr-teamtarget.com); } else if (toAddress.startsWith(spam)) { message.reject(blocked); } else { await message.forward(inboxtarget.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 处理fetchEmail Worker 处理email方法。如果把两种代码结构搞混控制台不会报错但邮件会静默失败。6.4 免费额度比想象中够用Cloudflare Workers 免费计划每天有大量请求额度只用来处理邮件转发和调 API个人台账非常充足。Resend 免费计划对日常收信恢复和系统通知也够用。这里的“零成本”并不是一句空话但如果你打算用这套系统群发几十万封营销邮件那我劝你老老实实去买一个专门的邮件营销服务任何免费方案都承受不住这种量级还会把域名信誉搞垮。7. 常见问题速查表问题常见原因解决方法收不到邮件MX 记录不是 Cloudflare 的在 DNS 里确认 MX 记录删除旧记录只在垃圾箱收到SPF/DKIM 缺失或重复合并 SPF补上 DKIM加 DMARC自定义别名不生效Catch-All 优先级高于自定义不是自定义高于 Catch-All检查规则是否配置正确并测试精确前缀Worker 没有收到邮件Catch-All 指向不对确保转发目标选择的是 WorkerResend API 返回错误域名未验证回 Resend 后台查看 DNS 验证状态发信被拒绝SPF 记录里缺少发信服务商 include把 include 合并进原 SPF收到大量爆破邮件Catch-All 太开放Worker 里增加黑名单和 reject 逻辑这些坑不是看文档能完全避开的尤其是 SPF 合并、Worker 代码结构、验证邮件点确认这三件事几乎每个人都会栽一次。把这章截图保存下来配置出错时对照排查能省下大把时间。我个人在实际操作中的体会是这套系统最厉害的地方不是“免费”而是“所有权”。收件和发件都在你自己域名的控制范围内规则由你写入口由你管出口由你定义。你注册网站、订阅服务、给客户留联系方式时不再是某个人邮箱的地址而是一个完全由你掌控的域名入口。我用它给数百个不同平台分配了独立别名后来某几个平台开始频繁发促销垃圾我直接把对应前缀的转发规则关掉主收件箱从此干干净净。第一周你会觉得这样只是省了企业邮箱的钱用久了你才发现这是一个可以随意编程、随时收缩和扩张的邮件基础设施。