用 Cloudflare 搭域名邮箱：收信、发信、DNS 与滥用边界

我原本也以为 Cloudflare 只能收信

很多旧教程把 Cloudflare 域名邮箱写成一条单向路：邮件转发进来，发信必须另找服务。现在这句话已经不完整。

截至本文核验日期，Cloudflare Email Service 同时包含 Email Routing 与 Email Sending Beta。前者处理进入域名的邮件，后者面向事务邮件，并受当前计划和 Beta 条件约束。

但“能发”不等于已经拥有完整邮箱。转发、收件箱、事务邮件和营销群发仍然是四种不同产品，DNS、发件信誉、退信和滥用责任也不会因为用了 Cloudflare 自动消失。

本轮没有购买新域名、部署 Cloud Mail 或发送测试邮件。下面的架构来自 Cloudflare 当前文档和 maillab/cloud-mail 仓库；真正部署时还要重新核对计划、限制和项目版本。

四种需求不能混为一谈

邮件转发

例如把 contact@yourdomain.com 收到的邮件转发到你已有的 Gmail。

你不一定拥有一个完整邮箱后台，只是让自定义地址成为入口。

完整邮箱

用户可以登录、查看收件箱、管理附件、发送邮件和维护账号。

Cloud Mail 这类项目属于这一层，需要数据库、权限、存储和前端。

事务邮件

注册验证码、密码重置、订单确认和系统提醒。它们由应用触发，强调可达性、身份验证和日志。

营销群发

新闻邮件和推广活动。它需要退订、投诉、名单来源、频率和法规合规。

不要用一个轻量转发方案承担完整邮箱，也不要把事务发送接口直接变成营销群发器。

最小方案：只做自定义地址转发

如果你只是想公开 contact@yourdomain.com，最简单的路径通常是 Email Routing：

1. 域名托管到 Cloudflare。
2. 启用 Email Routing。
3. 添加并验证真实目标邮箱。
4. 创建自定义地址和转发规则。
5. 按平台提示添加或确认 DNS 记录。
6. 从外部邮箱发送测试邮件。
7. 在目标邮箱检查到达时间和邮件头。

成功标准不是控制台显示 Active，而是外部邮件真的到达，并且回复路径符合你的预期。

这种方案不自动提供以 contact@yourdomain.com 发信的完整邮箱体验。

完整 Cloud Mail 多了什么

maillab/cloud-mail 官方仓库显示，项目基于 Cloudflare Workers，并组合多项服务：

• D1 保存结构化数据。
• KV 用于缓存或配置。
• R2 保存附件。
• Resend 等服务承担发件。
• Vue 前端提供邮箱与管理界面。
• Turnstile 防止批量滥用。
• Workers AI 可以处理验证码识别等扩展能力。

组件越多，越不能把它理解成“复制几条 DNS 即可”。

你还要负责：

• 用户权限。
• 管理员账号。
• 数据库迁移。
• 附件生命周期。
• 发件凭证。
• 滥用限制。
• 备份恢复。
• 版本更新。

DNS 至少要理解四类记录

MX

告诉其他邮件服务器，发往这个域名的邮件应该送到哪里。

MX 配错时，通常是完全收不到，而不是“晚一点到”。

SPF

声明哪些服务器可以代表域名发信。

SPF 不是越长越好。多个互相冲突的 SPF 记录会造成验证失败。

DKIM

发件服务使用签名证明邮件内容和身份。公钥通常通过 DNS 发布。

不要从别人的教程复制 DKIM 值，每个域名和服务都有自己的记录。

DMARC

告诉收件方，当 SPF 或 DKIM 不符合时怎样处理，并可以提供报告。

第一次配置可以从观察策略开始，先看真实流量，再逐步收紧。直接设置严格拒绝，可能把自己的合法邮件一起挡掉。

收信与发信要分开验收

收信测试

• 从不同外部邮箱发送。
• 检查普通文本与附件。
• 检查转发是否保留必要邮件头。
• 检查垃圾邮件目录。
• 检查不存在地址怎样处理。

发信测试

• 发送到 Gmail、Outlook 和自己的其他邮箱。
• 检查 From、Reply-To 与 Return-Path。
• 查看 SPF、DKIM 和 DMARC 结果。
• 检查退信。
• 检查是否进入垃圾邮件。
• 检查发送日志。

发出接口返回 200，不等于收件人收到，更不等于送达率良好。

域名邮箱不是身份资格制造器

教育后缀、企业后缀或自定义地址可能看起来像某种组织身份，但其他平台有自己的资格验证和条款。

不要把域名邮箱用于：

• 批量注册平台账号。
• 冒充学校或企业。
• 绕过学生资格验证。
• 获取不符合条件的优惠。
• 接收来历不明的验证码。
• 出售临时邮箱。

技术可行不等于使用合规。滥用还可能影响整个域名和发件服务的信誉。

管理后台的安全检查

完整邮箱后台至少需要：

• 强管理员密码。
• 两步验证或受控登录。
• 最小角色权限。
• Turnstile 或速率限制。
• 登录与发件审计。
• 敏感日志脱敏。
• 数据库备份。
• 附件类型和大小限制。
• 用户注册关闭或严格审核。
• 管理接口不直接暴露秘密。

默认管理员口令必须在首次启动时修改。仓库里的示例值不能进入生产。

附件为什么会增加风险

附件不仅占 R2 存储，还可能包含恶意内容和隐私数据。

需要明确：

• 最大文件大小。
• 允许类型。
• 保存多久。
• 谁能下载。
• URL 是否可猜。
• 删除账号后是否删除附件。
• 备份是否包含附件。
• 是否执行病毒扫描。

不要把 R2 公共桶当作私人邮箱附件目录。

费用要看整条链

可能产生费用的地方包括：

• 域名续费。
• Workers 请求。
• D1 使用量。
• KV 操作。
• R2 存储和读取。
• Email Sending。
• Resend 或其他第三方发件。
• 日志与监控。
• 超量和滥用请求。

免费额度与 Beta 条件会变化。部署前查看 Cloudflare Email Service、Workers、D1、R2 和发件服务的当前价格页。

常见失败怎样定位

完全收不到

检查域名状态、MX、路由规则和目标邮箱验证。

只有部分邮件不到

检查发件方退信、垃圾过滤、邮件大小和规则条件。

能收不能发

确认你配置的是 Routing 还是 Sending，发件服务和域名认证是否完整。

发信进垃圾箱

查看 SPF、DKIM、DMARC、域名信誉、邮件内容和投诉，而不是只换一个 SMTP。

附件打不开

检查 R2 权限、对象路径、签名 URL、内容类型和生命周期。

后台可以注册无限用户

这不是成功，而是需要立即补访问控制和滥用限制。

个人网站通常不需要完整邮箱系统

如果只是联系入口：

• 使用 Email Routing 转发。
• 不搭完整邮箱后台。
• 使用一个长期控制的目标邮箱。
• 对外只公开少量地址。

如果应用需要验证码和系统通知：

• 使用事务邮件服务。
• 配置 SPF、DKIM 与 DMARC。
• 保存发送与退信记录。

只有当你确实需要多个用户、收件箱、附件和后台时，再部署 Cloud Mail。

个人网站先把一个 contact 地址稳定收进自己的长期邮箱，往往已经够用。只有真实业务需要收件箱、附件和多用户时，再承担完整邮箱系统的维护责任。