想给个人网站配一个hello@你的域名.com这种域名邮箱，问了一圈不是按月付费，就是免费版处处受限。其实很多人不知道，Cloudflare 除了加速和防护，还自带一个 Email Routing 功能，可以把发到自定义域名的邮件永久免费地接收下来，再转发到你已有的邮箱里。我当年第一次看到这个功能的时候也有点吃惊：一家以 CDN 出名的公司，居然把邮件服务也顺手做了，而且对个人用户完全免费。
这篇教程我会把整套流程拆开揉碎，从原理讲到最后的排查，带着你把域名邮箱搭起来，顺便解决几个教程里很少写清楚的痛点：为什么你找不到 Email Routing 入口、为什么搭好之后只能收信不能发信、为什么发出去的邮件容易被当成垃圾邮件。如果你一直在犹豫要不要搞一个属于自己的域名邮箱，这篇可以直接照着操作。
1. 为什么我推荐用 Cloudflare 做域名邮箱：免费的邮件路由到底怎么工作
很多人以为“搭建域名邮箱”需要自己买一台服务器、装邮件系统，其实对个人场景来说根本不需要这么重。理解 Email Routing 到底做了什么，你才知道为什么它可以做到零成本。
1.1 域名邮箱的原理：MX 记录、收信与转发
正常情况下，你发一封邮件到hello@example.com，发件人的邮件服务器会根据域名example.com去查 DNS，找到这条域名的MX 记录，也就是“负责接收这个域名邮件”的服务器地址。查到之后，它会把邮件投递给这台服务器。
所以搭建域名邮箱的核心问题就变成了：谁能提供一台“长期在线、稳定收件”的服务器，并且你不需要为此付费。Cloudflare Email Routing 做的就是这件事。它把 MX 记录指向自己的邮件服务器，替你收下发到@你的域名的所有邮件，然后按照你配置的规则，把邮件原样转发到你提前填好的个人邮箱里，比如 Gmail、Outlook、QQ 邮箱、163 邮箱都可以。
这个过程有个很形象的类比：就像你在公司前台留了一个统一的对外联系电话，前台接到电话后转给对应的同事，你自己并不需要装一台电话交换机。Cloudflare 就是那个前台，而“转发规则”就是前台手里的转接表。转接表你可以随时改，今天把hello@指向 A 邮箱，明天把billing@指向 B 邮箱，都行。
1.2 Cloudflare Email Routing 的边界：只管收信，不管发信
不过有一点必须先说清楚，避免很多新手搭完之后一脸懵：Cloudflare Email Routing 只处理收件，不提供发件 SMTP 服务。也就是说，它能帮你的域名接住邮件并转发到你的私人邮箱，但不能让你用“配置一个邮箱客户端，输入账号密码，通过 Cloudflare 的服务器发邮件”这种传统方式去发信。
这个限制其实是理解整套方案的关键。正因为 Cloudflare 不碰发信，它才能把收信成本压到几乎为零，也才能对个人用户免费开放。实际使用中，“能收不能发”确实会让人觉得不完整，但后面第 4 节我会给你一套可行的发信方案，让它变得完整。这里你先记住：Cloudflare 解决了“接住邮件”这一半问题，另一半“发送新邮件”需要用别的方式补上。
2. 搭建前的准备：域名、Cloudflare 账号和接收邮箱
搞清楚原理之后，正式动手之前还需要把基础环境准备好。别小看这一步，很多人的配置过程卡住，不是因为后面哪里点错了，而是前面的准备没到位。
2.1 域名与 DNS 托管：不是只加一条记录这么简单
要使用 Cloudflare 的 Email Routing，第一步当然要有一个自己的域名。任何常见的域名注册商买的域名都可以，.com、.net、.dev、.me这类都比较稳妥。如果你还没有域名，可以先在任意域名注册商那里买一个便宜的，个人使用的话一年几十块就足够了。
这里有一个很多人忽略的关键点：Email Routing 要求域名是在 Cloudflare 上托管的，也就是这个域名的 DNS 服务器（NS 记录）必须指向 Cloudflare。你不能只在 Cloudflare 里添加一条 MX 记录就跑回去用原注册商的 DNS，那样 Cloudflare 是没法自动帮你管理收信记录的。
所以完整路径是：让 Cloudflare 成为这个域名的权威 DNS 服务商，然后整个域名的所有 DNS 解析都由 Cloudflare 接管，邮件路由功能才能正常工作。
2.2 把域名的 DNS 切到 Cloudflare：NS 修改与等待激活
具体操作分三步走：
- 注册或登录 Cloudflare 账号，点击右上角“Add a site”，输入你的域名。
- Cloudflare 会自动扫描这个域名现有的 DNS 记录，比如 A 记录、CNAME 记录、TXT 记录等，你确认无误后继续。
- 选择计划的时候选Free就完全够了。最后 Cloudflare 会给你两个
*.ns.cloudflare.com格式的 DNS 服务器地址。
拿到这两个地址之后，去你购买域名的注册商后台，找到“DNS 服务器 / Name Server”的设置项，把原来的 DNS 服务器替换成 Cloudflare 分配的那两个地址。修改之后通常需要几分钟到几小时不等的时间才能在公网生效，Cloudflare 那边会显示“Pending Nameserver Update”，等状态变成Active就可以继续配置邮箱了。
这一步其实也顺便解决了一个常见问题：很多人觉得“我只是想弄个邮箱，为什么要改整个域名的 DNS？”其实只有把域名完整托管过来，Cloudflare 才能在你配置 Email Routing 的时候自动帮我补好 MX 记录、SPF 记录、DKIM 记录。否则邮件能不能收进来都是个未知数。
2.3 接收邮箱的准备与规划别名列表
在开始添加规则之前，建议先想清楚两个问题。
第一，你的接收邮箱用什么。因为是“转发”模式，最终接收邮件的还是你现有的邮箱，比如 Gmail、Outlook、QQ 邮箱都行。接收邮箱本身必须可用，因为 Cloudflare 会给你发一封验证邮件，点击验证之后才算绑定成功。
第二，你的邮件地址怎么规划。域名邮箱最大的优势是可以创建无数个自定义别名，常见用法是：
| 别名 | 常见用途 |
|---|---|
hello@域名 | 对外品牌联系邮箱 |
info@域名 | 通用咨询 |
me@域名 | 私人使用 |
admin@域名 | 后台类用途 |
github@域名 | 单独用于注册 GitHub，追踪来源 |
我自己的习惯是给不同网站注册时都用不同的别名，比如siteA@域名、siteB@域名。如果日后某个别名突然收到大量垃圾邮件，我立刻就能判断是哪个网站泄露了这个地址。这是个人域名邮箱非常好用的一个特性，顺带解决了隐私问题。
3. 保姆级配置过程：从入口到第一条路由
准备完成之后，进入正式的配置环节。很多人做这一步的时候卡在了“找不到 Email Routing”，所以我单独把入口问题先讲。
3.1 找不到 Email Routing？先对照这几条排查清单
如果你在 Cloudflare 控制台里看不到 Email Routing，不要急着换平台，大概率是下面这些原因之一：
- 域名还不是 Active 状态：如果域名刚添加或者刚改完 NS，Cloudflare 还在等待 DNS 生效，许多功能入口都不会显示，先去 Overview 页面看域名状态。
- 选错了账号或没有权限：如果 Cloudflare 账号是通过团队组织管理的，当前账号可能没有该域名的编辑权限。切到超级管理员权限的账号再试。
- 入口位置找错了：进入域名首页后，在左侧菜单往下拉，找 “Email” 或 “Email Routing” 这一项，新版控制台把邮件入口放得比较靠下，不仔细看容易忽略。也可以在控制台顶部的搜索框直接搜 “Email”。
- 域名类型不支持：极少数特殊后缀域名在 Cloudflare 上可能不显示该功能，但常见主流后缀基本都没有问题。
如果以上都排除了还是看不到，把域名删除后重新添加一次，重新走一遍 DNS 导入，一般就能解决。亲测这一步非常有效。
3.2 添加目标邮箱并完成验证
找到 Email Routing 入口之后，页面上会提示你开始配置，大致流程是：
- 点击Get started或Start using Email Routing。
- 页面会让你添加一个 Destination address，也就是你希望把邮件转发到哪个目标邮箱。输入你的 Gmail 或 QQ 邮箱地址。
- Cloudflare 会向这个目标邮箱发送一封标题类似
/Verify Destination Email的邮件，你需要去邮箱里找到这封邮件并点击验证链接。
这里我想特别提醒一点：验证邮件可能不在收件箱，记得去垃圾邮件里翻一下。因为发件地址是 Cloudflare 的系统地址，部分邮箱服务商对陌生发件人比较敏感，很容易误判。点完验证链接之后，回到 Cloudflare 页面刷新，目标邮箱会显示 Verified 状态。
3.3 创建自定义地址与 Catch-all 的取舍
目标邮箱验证通过之后，就可以创建自定义地址了。在 Routing rules 里点击Create address，然后填写：
- 自定义地址的前缀，比如
contact、hello、admin； - 选择转发到的目标邮箱，也就是你刚验证过的那个地址。
每创建一个地址，整个过程几乎秒级生效。建议你最优先创建的是admin@域名或者postmaster@域名，因为很多服务在验证域名所有权、配置 TLS 证书或处理第三方服务通知时，会默认找这两个邮箱。
接下来是容易被忽略的环节：Catch-all 要不要开。Catch-all 的意思是，任何发往@你的域名的邮件（只要没有匹配到明确规则）都会被转发到指定邮箱。这个功能看起来方便，但实际上风险不小：垃圾邮件发送者经常会随机生成前缀来试探，开了 Catch-all 之后，那些乱七八糟的邮件就会全部涌进你的收件箱。
我的建议是：初始阶段不要开 Catch-all，先用明确规则，比如hello@、admin@。等后续发现自己经常收到发到某个未配置前缀的邮件，再针对性添加对应的转发规则，这样既灵活又干净。
3.4 检查 DNS 自动添加的记录：MX、SPF、DKIM
当你启用 Email Routing 并创建第一条规则后，Cloudflare 会在 DNS 页面自动添加几条记录。这一步非常重要，我建议你配置完成后一定要手动去检查一遍：
- 进入域名的DNS → Records页面；
- 确认存在 MX 记录，记录值是类似
route1.mx.cloudflare.net这样的地址； - 确认存在 SPF 记录，内容是包含
include:_spf.mx.cloudflare.net的 TXT 记录； - 确认存在几组 DKIM 记录，通常以
_domainkey开头，用于邮件签名。
这些记录就是域名邮箱能够正常收信、并且降低被判定为垃圾邮件概率的底层保障。如果你之前这个域名在别的地方配置过 SPF 记录，要注意不能让两条 SPF 记录并存，需要手动合并成一条，让旧内容和新内容都在同一条 TXT 记录里，否则邮件系统会不认你的 SPF。
4. 发信怎么办：让域名邮箱“能收也能发”的三种实用路线
配置到这一步，你的域名已经能接收邮件了。但很多教程到这里就结束了，导致大量用户搭完之后发现自己只能收信，不能发信。这一节我把实际可用的发信方案给你完整盘点一遍。
4.1 为什么转发邮箱直接回复达不到预期
首先解释一个常见的认知误区。假设有人给hello@yourdomain.com发了一封邮件，这封邮件被 Cloudflare 转发到你绑定的 Gmail 或 QQ 邮箱。此时你直接在当前邮箱里点“回复”，对方看到的发件人地址其实是你当前的 Gmail 或 QQ 邮箱地址，而不是hello@yourdomain.com。
原因很简单：Cloudflare 的转发只是把邮件从接收服务器搬到了你的私人邮箱，并不会替你像真正的企业邮箱一样接管“身份”。你去回复时，用的是你自己邮箱服务商的发件服务器，所以对方看到的就是你的私人邮箱。如果你只是自己用，这个体验可能还能接受；但如果你想把域名邮箱作为对外工作邮箱，就必须提供一种真正“以域名邮箱为发件人”的方式。
4.2 路线一：纯 Cloudflare 接收 + 第三方 SMTP 发信
第一种路线最贴近“还是用 Cloudflare 收信”的思路，发信则借助第三方 SMTP 服务。原理是：在 Gmail 或 QQ 邮箱中，通过“添加别名 / Send mail as”功能，把你自己的域名邮箱声明为一个“发件人地址”，然后告诉 Gmail：发送时请通过某个外部的 SMTP 服务器来投递。
第三方 SMTP 服务有很多，个人使用主要看免费额度。一些邮件和营销平台提供免费层级的 SMTP 服务，允许一定数量的免费发送额度，把这些服务的 SMTP 服务器信息填进 Gmail 的别名设置里，就可以实现“发件人显示为hello@yourdomain.com，收件人打开邮件时看到的发件地址就是这个域名邮箱”。
实际操作时大致的流程是：
- 在第三方 SMTP 服务商后台找到你的专属发信域名，根据提示完成域名验证。这里要注意，验证时通常会要求你在 DNS 里添加一条 TXT 记录或 DKIM 记录，Cloudflare 的 DNS 页面直接添加即可。
- 拿到服务商提供的 SMTP 服务器地址、端口号和账号密码（通常是 API Key）。
- 打开 Gmail 设置 → Accounts and Import → Send mail as → Add another email address。
- 填写别名地址
hello@yourdomain.com，在 SMTP 设置里填入第三方服务器的参数，完成验证邮件确认。 - 之后在 Gmail 写信时，点发件人下拉框选择
hello@yourdomain.com即可。
这条路线的优点是：收信依然完全由 Cloudflare 这个免费方案承担，发信借助第三方免费额度，整体成本还是零。缺点是：配置链路相对长，要对 SMTP 概念有一定了解，而且第三方服务的免费额度通常不是特别大，但个人日常通信完全够用。
4.3 路线二：Cloudflare 只做 DNS，邮箱服务交给 Zoho Mail 免费版
如果你觉得上面那种“收信用一套、发信用另一套”的方式太繁琐，或者你希望有一个真正的网页邮箱界面，可以收发、可以在里面管理联系人，那么第二条路线会更适合你：让 Cloudflare 继续负责 DNS，但邮件服务整体换到 Zoho Mail 的免费版。
Zoho Mail 有一个针对个人用户的免费版本，支持自定义域名邮箱。操作上大致是：
- 注册 Zoho 账号并申请 Custom Domain 邮箱服务。
- Zoho 会提供它自己的 MX 记录地址，你需要到 Cloudflare 的 DNS 页面，把原先用于 Cloudflare Email Routing 的 MX 记录删掉，替换成 Zoho 的 MX 记录。注意MX 记录只能存在一套，如果你同时保留两套，邮件投递会随机或直接失败。
- 根据 Zoho 的提示添加 SPF、DKIM 记录。
- 等待生效后，直接在 Zoho 网页邮箱里收发信即可，而且它的免费版本身功能已经很全。
这条路线的实质是：Cloudflare 变成了一个“免费的 DNS 管理面板”，邮件服务器本身由 Zoho 承担。好处是收发完整、有网页客户端，适合不折腾的人；代价是邮箱功能不再挂在 Cloudflare 名下，免费版也有一定用户数限制和存储空间限制。
4.4 路线三：临时收验证码/订阅信，不做发信
最后一个路线其实最简单，也最被低估。不少人的真实需求不是“建立一个对外沟通/邮箱”，而是“我想要一个看似专业的邮箱地址，主要用来注册网站、收验证码、收订阅邮件”。这种场景下，做一个完整发信方案完全是过度设计。
你就直接用 Cloudflare Email Routing，把几个别名指向你的私人邮箱，平时只用来收信。如果真的需要主动联系人，直接用私人邮箱发信就行。域名邮箱只在需要对外展示的场合使用，本质上它承担的是“品牌形象入口”和“垃圾邮件防火墙”的角色。这是成本最低、运维负担最轻的做法，也是我目前个人使用占比最高的方式。
| 路线 | 收信 | 发信 | 复杂度 | 适合人群 |
|---|---|---|---|---|
| 纯 Cloudflare + 第三方 SMTP | Cloudflare 免费 | 第三方 SMTP 免费额度 | 中等 | 需要对外用域名邮箱发信 |
| Cloudflare DNS + Zoho 免费版 | Zoho 免费版 | Zoho 免费版 | 低 | 需要完整邮箱客户端 |
| 只收不发 | Cloudflare 免费 | 不做 | 最低 | 注册网站、收验证码 |
5. 实测中的坑与排错：为什么收不到邮件、被识别成垃圾邮件
配置完成后，最让人崩溃的事就是：明明一切都显示正常，发过去就是收不到，或者朋友回复说你的邮件进了垃圾箱。这一节我把自己实际踩过的坑和排查路径完整列出来。
5.1 发信测试与常见“收不到”的检查路径
配置完之后，别忘了做一次完整的收发信测试。用你的其他邮箱给hello@yourdomain.com发一封测试邮件，然后确认目标邮箱是否能收到。如果迟迟收不到，按以下顺序排查：
- 看 DNS 是否生效：在本地终端执行
dig example.com mx或者用在线 DNS 查询工具，确认 MX 记录已经指向route1.mx.cloudflare.net。如果返回的还是旧记录，说明 DNS 还在传播中，等几分钟再试。 - 看目标邮箱的垃圾箱：我前面提过，验证邮件和转发邮件都有概率被误判为垃圾邮件，第一时间先翻目标邮箱的垃圾箱。
- 检查路由规则：回到 Cloudflare 的 Email Routing 页面，确认 Custom addresses 里有你要测试的那个地址，而且状态是 Active。
- 确认没有旧邮箱服务残留：如果你的域名之前用过其他邮件服务，DNS 中可能还残留着其他优先级的 MX 记录。多优先级 MX 记录并存时，发件服务器会优先选择优先级数字最小的那一条，如果那条已经不可用但你没有删除，就会出现“明明 Cloudflare 配置正确，邮件却被投到旧服务器”的情况。
排查的时候不要着急，大多数收不到邮件的问题都集中在 DNS 没生效，或者目标邮箱把邮件吃进了垃圾箱。
5.2 SPF/DKIM 与邮件进垃圾箱的处理
如果收信没问题，但用自己的域名邮箱发信时，对方常常收不到或者进了垃圾箱，那基本就是 SPF 和 DKIM 配置的问题。
SPF 的作用是告诉收件服务器“哪些 IP 有权以你这个域名发送邮件”。如果你的域名没有配 SPF 或者配了但没经过验证，对方的服务器就会认为“这个域名可能会被冒用”，从而把邮件判为垃圾邮件。DKIM 则是给邮件加数字签名，证明邮件确实来自这个域名的合法服务器。
在实际配置时你要注意，因为 Cloudflare Email Routing 只是收信方，如果你让它自动管理 DNS，它只会加入自己转发所需的记录。而当你用了第 4 节的第三方 SMTP 发信方案时，还需要根据发信服务商的要求，额外添加该服务商提供的 SPF 和 DKIM 记录。这里最稳妥的做法是把所有用到的服务的 include 段合并到同一条 SPF 记录里。比如你既想保留 Cloudflare 的转发，又用了第三方 SMTP 服务，SPF 记录可能长这样：
v=spf1 include:_spf.mx.cloudflare.net include:spf.example-smtp-service.com ~all合并后，用一些在线的邮件头分析工具发一封测试信，看看 SPF 和 DKIM 是否都显示 pass。这个动作建议所有搭完域名邮箱的人都做一遍，比你去翻各种文档都直接。
5.3 邮件头部“via”来自哪里：转发机制的自然现象
还有一个新手容易误解的地方：当你用 Gmail 收到转发过来的域名邮件时，写信人下方可能会显示一个类似via relay.example.net或者via gmail.com的提示。于是你会开始担心：是不是我配置有问题？是不是发件人看到我的邮箱会露馅？
这不是故障，而是邮件系统的正常行为。因为 Cloudflare 转发邮件时，会把邮件重新封装投递到你的目标邮箱，目标邮箱会标明“这封邮件经过某个服务器转发”。收件人如果用的是同一个邮箱服务商，通常也能看到类似的代发提示。它不会影响你正常的收信和使用，你也不需要为这个提示做什么额外操作。真正需要关心的是：你的 SPF 和 DKIM 是否配置正确。如果这两个校验都通过了，就算有“via”提示，也不会影响邮件送达率。
5.4 其他容易忽略的细节：免费额度、服务稳定性、账号安全
最后说几个容易忽略但影响使用体验的细节。
免费额度的问题。Cloudflare Email Routing 对个人用户目前是免费使用，支持的自定义地址数量非常多，对普通人的量级来说基本等于无限。但是免费的东西不承诺 SLA，如果你后续把它用于关键商务场景，需要自己评估风险。
账号安全的问题。既然整个域名都托管在 Cloudflare，你的 Cloudflare 账号就等于握住了整个域名的命脉。强烈建议开启两步验证，强密码，不要和别人共享账号。万一账号失守，攻击者改几条 DNS 记录就能截走你所有邮件，这不是危言耸听。
子域名与根域名的区别。如果你后续需要同时使用 Cloudflare 的 CDN 服务和某个第三方邮件提供商，要注意把邮件服务和网站服务放在正确的域名层级上。最简单的方式是主体域名用第三方邮箱的 MX 记录，子域名比如cdn.你的域名.com单独走 Cloudflare CDN，两者互不冲突。
写在最后
配置完 Cloudflare Email Routing 之后，我最大的感受是：这种“借力打力”的思路很适合个人项目。Cloudflare 作为免费的 DNS 托管方，顺手解决了域名邮箱的收信问题，而发信问题可以用第三方 SMTP 或者干脆放弃发信来绕开。
如果你只打算用它收验证码、收订阅、对外留一个好看的邮箱形象，那么“只收不发”就是性价比最高的方案。如果你确实需要对外用域名邮箱发信，我建议优先考虑 Zoho 免费版那条路线，省心程度高很多。最后再分享一个小技巧：给自己常用的网站都配上单独别名，过一两个月看看收件箱，你会惊讶地发现垃圾邮件的来源指向性变得极其清晰。这算是搭这个邮箱过程中最让人惊喜的附加价值了。
