This article was originally published on OhRelay Insights.
Cloudflare quietly opened its Email Sending feature to public beta this week. If you use Cloudflare Email Routing or build on Workers, this is worth understanding — both for what it adds and for what it still doesn't solve.
What Cloudflare Email Sending actually is
The new Email Sending service lets you send email programmatically from a Cloudflare Worker or via a REST API. The setup is straightforward: onboard a domain through the Cloudflare dashboard, let it add the required DNS records (SPF, DKIM, DMARC, bounce MX), then call env.EMAIL.send() from your Worker code.
const response = await env.EMAIL.send({
to: "user@example.com",
from: "welcome@yourdomain.com",
subject: "Welcome!",
html: "<p>Thanks for signing up.</p>",
text: "Thanks for signing up.",
});
That's the core use case: transactional email from a Worker. Think signup confirmations, magic links, order receipts — the kind of email your application sends automatically, not the kind a person composes and sends.
The real limitations
Before you consider switching your email stack, the current constraints are significant:
1. Workers Paid is required — no free option
Email Sending is gated behind the Workers Paid plan at $5/month. There is no free tier access, even for testing small volumes. If you're on the free Workers plan, you'll see a paywall before you can send a single email.
2. Recipient restrictions in early usage
When you first enable Email Sending, you can only send to verified destination addresses already configured in your Cloudflare account. Sending to arbitrary recipients requires a paid plan and Cloudflare's assessment that your account is in good standing. The daily sending volumes are also set per-account by Cloudflare with no documented ceiling — you have to request increases through a form.
3. Workers-only architecture
The Workers binding (env.EMAIL) only works inside a Cloudflare Worker. If your sending infrastructure lives elsewhere — a Node.js service, a VPS, a Docker container — you'll need to use the REST API instead, which is functional but loses the native integration angle. Either way, this is not an SMTP relay: you cannot point Postfix, Nodemailer, or your mail client at Cloudflare to send email.
4. No alias management, no identity routing
Email Sending is an outbound primitive. You specify a from address, Cloudflare sends the email. There is no concept of aliases, no inbox management, no routing rules, and critically — no connection to the inbound side of Cloudflare Email Routing.
Where Email Routing + Email Sending still leaves a gap
Cloudflare now has two email products:
- Email Routing — receives mail at your custom domain, forwards it to a personal inbox (Gmail, Outlook, etc.)
- Email Sending — sends transactional email from your Worker
Together, they look like a complete email stack. But there's a fundamental gap in the middle.
When Cloudflare Email Routing forwards a message from support@yourdomain.com to your Gmail, your Gmail client sees only the Gmail address. When you hit reply, the reply goes out from Gmail — not from support@yourdomain.com. Your customer gets a response from yourname@gmail.com.
Email Sending doesn't fix this. It's designed for application code, not mail clients. You cannot configure Gmail or Apple Mail to use Cloudflare Email Sending as an SMTP relay for manual replies.
The gap is: you can receive with a custom domain identity, but you can't reply with that same identity from your existing inbox.
What OhRelay adds
OhRelay is a relay layer that sits between Cloudflare Email Routing and your working inbox, specifically to close this identity gap.
When Cloudflare forwards an email to your inbox, OhRelay preserves the original recipient address in the forwarded message. When you reply, OhRelay's SMTP gateway intercepts the outbound message, reads the original routing context, rewrites the envelope so the MAIL FROM and visible From: show support@yourdomain.com, and forwards the email onward.
The result:
- Email sent to
support@yourdomain.comarrives in your Gmail - You hit reply
- Your customer receives a reply from
support@yourdomain.com
No separate mailbox. No per-seat pricing. No manual address selection every time you reply.
This is a different problem from what Email Sending solves. Cloudflare Email Sending is built for developers shipping applications. OhRelay is built for operators who want their working inbox to behave professionally across multiple domain addresses.
The broader picture
Cloudflare is building out a complete email infrastructure stack, piece by piece. Email Routing handles inbound. Email Sending handles programmatic outbound. The company is clearly moving toward owning more of the email layer for its customers.
But "complete email stack" and "email identity management" are different things. The challenge of replying correctly from a forwarded address is a workflow problem, not just a protocol problem. It requires understanding the relationship between inbound routing, inbox context, and outbound identity — and enforcing that relationship consistently across every reply your team sends.
That's what OhRelay handles. If you're already using Cloudflare Email Routing and the wrong-sender issue has been a persistent friction point, see how OhRelay works.
