I've Been Waiting for Cloudflare Email Sending. Then It Shipped — and I Built My Own Tool Instead.
Cloudflare Email Sending just hit public beta. I was excited. Then I realized it doesn't solve the email problem I actually live with every day — so I built OhRelay.
Cloudflare just opened Email Sending to public beta. I’d been watching for this. After years of relying on Cloudflare Email Routing as the backbone of how I handle email across multiple domains, I was genuinely curious whether this would finally close the loop.
Then I read the docs. And I realized it’s solving a completely different problem from the one I have.
What it does (quick version)
Cloudflare Email Sending lets you send email programmatically from a Worker or REST API. You onboard a domain, Cloudflare auto-configures SPF, DKIM, DMARC, and you call env.EMAIL.send() from your Worker:
await env.EMAIL.send({
to: "user@example.com",
from: "welcome@yourdomain.com",
subject: "Welcome!",
html: "<p>Thanks for signing up.</p>",
});
Genuinely useful for developers sending transactional email from applications — signup flows, magic links, notifications. Clean, well-designed API.
But this isn’t the email problem I live with.
My actual problem
I run several projects under different domains. Each domain has multiple address prefixes — hello@, support@, billing@, hey@. I want emails to all of these to land in one place, and I want to reply from the right address without thinking about it.
This is a pretty common situation for indie developers, small agencies, freelancers running multiple things at once. And the solutions out there all have the same rough edges.
Business email (Google Workspace, Fastmail, etc.)
Works. But you pay per mailbox, per seat, sometimes per domain. Once you have six addresses across four domains, you’re paying a non-trivial monthly bill just to manage email identity — before you’ve shipped anything. And you’re still juggling multiple inboxes.
Cloudflare Email Routing
Free. Zero infrastructure. Emails sent to support@yourdomain.com land in your Gmail within minutes. It handles the inbound side beautifully.
But when you hit reply, your Gmail sends from your Gmail address. The customer who wrote to support@yourdomain.com gets a reply from yourname@gmail.com. The professional image cracks. Cloudflare Email Sending doesn’t fix this — Gmail can’t use it as an SMTP relay for manual replies from your inbox.
Gmail “Send As” aliases
You can add custom sender addresses to Gmail via an external SMTP provider. This works at small scale. Two or three addresses, manageable. Six domains and a dozen prefixes, and you’re manually selecting the right address on every reply — and eventually sending from the wrong one.
None of these felt like a complete answer.
So I built something
I spent the past few months building a relay layer specifically for this problem. The idea: sit between Cloudflare Email Routing and my existing inbox. Preserve routing context on inbound. Rewrite the envelope correctly on outbound.
The result is OhRelay.
What it does:
- When Cloudflare forwards a message to your inbox, OhRelay stamps the original recipient address into the email headers — so the routing context isn’t lost by the time it reaches your Gmail.
- When you reply, OhRelay’s SMTP gateway intercepts the outbound message, reads that context, and rewrites the envelope so the reply goes out from
support@yourdomain.com— automatically, without you picking anything. - It works with Gmail, Outlook, and Apple Mail. Configure once per inbox. Replies just work.
- OhRelay uses the Cloudflare API to automatically configure the required DNS records and deploy the necessary Worker scripts on your behalf — so non-technical users can get this working without touching DNS manually or writing a single line of code.
The workflow:
- Email arrives at
support@yourdomain.com - It lands in your Gmail via Cloudflare Email Routing
- You hit reply
- Your customer gets a response from
support@yourdomain.com✓
No extra mailboxes. No per-seat costs. No manual address selection.
Where it stands now
OhRelay is about 90% of the way there. The core relay works. Real emails are flowing through it. The setup takes maybe 15 minutes if you’re already on Cloudflare Email Routing.
What it needs now is more real users — people with actual domain setups and real email workflows — to surface the edge cases I haven’t encountered yet. Every new configuration teaches me something the next user will benefit from.
If the wrong-sender problem is something you’ve been putting up with, or if you’re managing too many addresses across too many domains and the existing tools feel like duct tape, I’d genuinely love for you to try it. Start here. Setup is mostly DNS and one SMTP config in your mail client.
And if you hit a weird edge case, reach out. I’m still in the “building with users” phase. Real feedback is what shapes the next 10%.
As for Cloudflare Email Sending: it’s a solid addition to the Workers ecosystem, and for developers shipping applications that send programmatic email, it’s worth looking at. But it’s a developer API, not an inbox tool. The gap between receiving email at a custom domain address and replying from that same address — in your actual mail client, to real humans — is still there. That’s the one I’ve been working on.
Keep your inbox. Run every domain address you manage.
14-day free trial.