Cloudflare 邮件路由单独还解决不了什么
Cloudflare Email Routing 让收件这一步变得简单可靠，但回复时的发件身份仍然是另一个问题。这里解释真正发生了什么，以及中继层如何把这部分补上。
Cloudflare Email Routing 确实很好用。免费、可靠、几乎不用自己维护基础设施。把 MX 记录指向 Cloudflare，配几条规则，发往 support@yourdomain.com 的邮件几分钟内就能出现在您的 Gmail 主邮箱里。
如果您只需要接收域名邮箱，很难找到比它更省事的方案。
问题出在您点击回复之后。
转发实际上做了什么
当 Cloudflare 把一封邮件从 support@yourdomain.com 转发到您的个人 Gmail 时，它并不是简单地搬运邮件，而是重写了信封（SMTP envelope）。
原始 SMTP 事务是这样的：
MAIL FROM: customer@example.com
RCPT TO: support@yourdomain.com转发完成后，邮件到达 Gmail 时会附带 X-Forwarded-To 和 X-Original-To 之类的邮件头，用来记录它最初是发给谁的。但 Gmail 客户端并不会按这些邮件头来决定发件身份，它看到的只是：这封邮件到了您的 Gmail。
所以当您点击回复时，Gmail 会做一件再自然不过的事：用您的 Gmail 地址发出这封回信。
客户明明写信给的是 support@yourdomain.com，最后收到的却可能是一封来自 yourname@gmail.com 的回复。
这就是缺口所在。Cloudflare 解决了收件，但回复这一步仍然需要另一层能力。
常见的变通方案（以及它们的局限性）
1. 在 Gmail 里添加”以其他地址发送”别名
Gmail 允许您通过 SMTP 添加自定义发件地址。您可以把 support@yourdomain.com 配成一个别名，指向某个发信 SMTP 服务商。
这是可行的，但通常只在地址很少时还算轻松。一旦您同时管理 support@、sales@、admin@、billing@，而且还分布在两三个不同域名下，就会变成：
- 每次回复都要手动选择正确的发件地址
- 自己记住客户最初写信给的是哪个地址
- 希望自己没有选错
迟早会有发错的那一次。写给 support@ 的客户，收到的却是来自 founder@ 的回复，这种错误非常伤对外形象。
2. 为每个地址开独立邮箱
这是传统方案：为每个地址购买一个 Google Workspace 席位，或者用 Fastmail、Zoho 等类似服务。能用，但本质上是在为每个邮箱地址单独付费，而不是按实际处理邮件的人数付费，而且一整天都要在不同收件箱之间切换。
如果地址数量的增长速度远高于团队人数，这在小型工作室、代理商和个人运营者那里很常见，成本很快就会上来。
问题真正需要在哪里解决
根本问题是：转发邮件到达客户端时，路由上下文已经断掉了。要把回复这一步做对，系统至少要完成三件事：
- 保留转发时的原始收件地址
- 读取这个上下文，在你点击回复时识别它
- 重写信封，让发出去的 SMTP
MAIL FROM和可见的From:邮件头都显示support@yourdomain.com，而不是您的个人地址
第三步最关键，也就是所谓的信封重写（envelope rewriting）。这正是“邮件转发”和“身份路由”之间真正的分界线。
完整的流程像这样：
客户
→ support@yourdomain.com
→ Cloudflare Email Routing（入站 MX）
→ 中继层（在邮件头中保留路由上下文）
→ 您的主邮箱（Gmail / Apple Mail 等）
你点击回复
→ Gmail：在发件人字段中选择网关地址
→ Apple Mail / 其他桌面客户端：直接通过已配置的中继 SMTP 发出
→ 邮件客户端把邮件交给中继的 SMTP
→ 中继读取 X-Original-To 邮件头
→ 中继把 MAIL FROM 重写为 support@yourdomain.com
→ 客户收到来自 support@yourdomain.com 的回复 ✓对客户端来说，它只看到一个 SMTP 连接。您为每个主邮箱配置一次就够了。之后的使用方式也更简单：Gmail 里是选择同一个网关地址，而不是为每个域名邮箱地址分别维护 SMTP；Apple Mail 和很多桌面客户端则通常会直接沿用已经配置好的 SMTP。再由中继根据上下文还原真正对外显示的发件身份。
我是怎么构建这个的
我自己经营一个小工作室，手里有几个项目域名。后来实在受不了两种选择：要么为每个邮箱单独付费，要么手动维护一堆“以其他地址发送”的别名。于是我自己搭了一个中继层，夹在 Cloudflare Email Routing 和主邮箱之间。
入站侧相对简单。Cloudflare 已经在每封转发邮件上打上 X-Forwarded-To 和 X-Original-To，我要做的只是确保这些邮件头在到达主邮箱时保持完整。
出站侧才是真正的难点。当您给邮件客户端配置了自定义 SMTP 凭据后，客户端会把出站邮件的控制权交给中继。在这里执行的就是信封重写：检查路由上下文、确认正确的发件身份、重写邮件头，再通过上游 MTA 发出去。
有几个需要仔细处理的细节：
- 发件人验证：不能允许任何人随意声明任意
From地址。中继必须知道哪些地址已经授权给哪个账号。 - 邮件头优先级：邮件客户端有时会以冲突的方式设置
Sender:和Reply-To:，这部分必须把优先级顺好。 - 退信处理：当重写后的出站邮件发生退信，退信会回到
MAIL FROM，也就是您的域名邮箱地址，这些退信也得被正确路由回来。
最终效果
配置完成后，工作流程变成：
- 所有域名邮件进入同一个主邮箱
- Gmail 里回复时选择网关地址，客户看到的仍然是正确的域名邮箱地址
- Apple Mail 等桌面客户端在 SMTP 配好后，回复通常可以直接工作
- 不需要为每个地址分别维护 SMTP
- 不需要为每个地址单独购买邮箱订阅
- 不需要在多个收件箱之间切换
这就是 OhRelay 要做的事。它夹在 Cloudflare Email Routing 和您已经在用的主邮箱之间，Gmail、Apple Mail 或其他支持 SMTP 的客户端都可以。配置也很克制：DNS 按要求设好，在邮件客户端里加一条 SMTP 网关配置即可。
如果您一直在处理“回复时发件人不对”的问题，或者邮箱席位已经越来越难管，可以从这里开始了解。