Cloudflare Email Routing 确实很好用。免费、可靠、零基础设施。把 MX 记录指向 Cloudflare，配置几条规则，发往 support@yourdomain.com 的邮件几分钟内就出现在你的 Gmail 收件箱里。
如果你只需要接收自定义域名邮件，很难找到比它更好的方案。
问题从你点击回复开始。
转发实际上做了什么
当 Cloudflare 把一封邮件从 support@yourdomain.com 转发到你的个人 Gmail 时，它并不是简单地移动邮件——它重写了信封（envelope）。
原始 SMTP 事务是这样的：
MAIL FROM: customer@example.com
RCPT TO: support@yourdomain.comCloudflare 把它改写成：
MAIL FROM: support@yourdomain.com（或某个转发地址）
RCPT TO: your-gmail@gmail.com这样 Gmail 才能接受它。但这个重写过程丢失了一件重要的事：谁是原始收件人这个信息不再以 Gmail 能理解的方式保留下来。
邮件是送达了。但它送达的方式让 Gmail 在你回复时无从判断——你应该以哪个地址Reply。
你点击回复时发生了什么
Gmail 看到这封邮件：发件人是 customer@example.com，收件人是你的 Gmail 地址 your-gmail@gmail.com。
所以当你点击回复时，Gmail 填入：
- 发件人：
your-gmail@gmail.com - 收件人：
customer@example.com
你的客户收到的回复，发件人是你的个人 Gmail 地址——而不是他们最初写信的 support@yourdomain.com。
几种可能的结果：
- 你的客户以为这是某个不同的人发来的邮件。
- 他们回复到你的个人 Gmail，而不是品牌地址。
- 你暴露了本不想公开的个人邮箱地址。
- 品牌一致性遭到损害。
这不是 Cloudflare 的 bug，而是转发工作机制的本质局限。
为什么别名不能完全解决问题
你可能会说：「我可以在 Gmail 里添加 support@yourdomain.com 为别名。」
是的，这是一个选项。但它有几个问题：
一、你需要单独的 SMTP 凭据
要让 Gmail 以 support@yourdomain.com 的身份发送邮件，你需要一套能代表该域名发信的 SMTP 凭据。这意味着：这个域名需要有自己的邮件发送基础设施，或者你需要使用某个能发送的 SMTP 中继。
二、Gmail 不会自动选择正确的别名
即使别名配置好了，Gmail 的默认行为是按照你在「账号和导入」设置中配置的「默认发件人地址」发送——不是自动匹配来信地址。你必须在每次回复前手动从下拉菜单选择正确的地址。这在只管理一两个地址时还能接受，但随着地址数量增加，很容易出错。
三、这无法跨收件人身份扩展
如果你管理 5 个域名地址，通过 Cloudflare 路由转发到同一个 Gmail，你需要为每个地址配置别名，并在每次回复时记住使用哪个。即便如此也不太可靠。
信封重写真正解决了什么
Cloudflare 转发的根本问题是：它在消费者 Gmail 的上下文中接收邮件，然后 Gmail 用 Gmail 的规则处理回复。
真正的修复是在中间加一层——一个邮件中继，它：
- 接受来自你工作收件箱的出站邮件。
- 检查转发上下文（原始收件地址是什么）。
- 在把邮件发出去之前重写信封，让发件人显示正确的域名地址。
这就是信封重写（envelope rewriting）——让你的回复真正从你应该所在的地址发出。
在技术层面，即：
你在 Gmail 里写邮件 → Gmail 把它发给中继
中继确认：「这封邮件最初发往 support@yourdomain.com」
中继重写 MAIL FROM 为 support@yourdomain.com
中继将其投递给收件人最终结果：你的客户收到的回复，发件人是 support@yourdomain.com——和他们最初写信的那个地址完全一致。
这如何在实践中工作
从操作员的角度来看，过程很简单：
- 你启用 OhRelay 作为你工作收件箱的 SMTP 中继。
- 来自
support@yourdomain.com的邮件按正常方式到达你的 Gmail。 - 当你回复时，你选择 OhRelay 网关地址作为发件人（或者在配置了这个功能的桌面客户端中自动完成）。
- OhRelay 识别上下文，把邮件以正确的
support@yourdomain.com身份发出。
技术上的信封重写对你是不可见的——你只是在正常回复，发件人永远正确。
边缘案例：OhRelay 无法确认上下文时
有时系统可能无法 100% 确定哪个域名地址应该是发件人——例如：你在移动端发起新邮件（没有转发上下文），或路由配置还没建立好。
在这种情况下，OhRelay 拒绝发信，而不是冒险使用错误的发件人。
这是有意为之的安全优先设计。泄露个人或内部邮箱地址，对某些场景（如代理客户域名管理）会是严重问题。拒绝发送，好过用错发件人发送。
结论
如果你使用 Cloudflare Email Routing 来路由自定义域名邮件，收件端你已经处理得很好。
需要修复的是回复端：在 Cloudflare 转发之后，你需要一个能正确处理出站身份的层。
配置转发很容易。处理转发之后的那一步，需要更多工作——这正是 OhRelay 存在的原因。