DEV Community: nonozone

Cloudflare Email Sending Is Now in Public Beta — OhRelay Fills the Gap It Left Behind

nonozone — Sat, 18 Apr 2026 09:43:45 +0000

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.com arrives 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.

Do You Really Need Separate Mailboxes for Every Business Email Address?

nonozone — Tue, 14 Apr 2026 12:27:22 +0000

Most small businesses want domain-based email addresses.

That part is normal.

They want addresses like:

hello@yourcompany.com
support@yourcompany.com
billing@yourcompany.com
because those addresses look more professional, separate personal and business communication, and avoid exposing someone's private inbox.

The problem starts when every one of those public-facing addresses turns into another mailbox account.

For larger teams, that may be fine.

For founders, tiny studios, agencies, and small operator-led teams, it gets annoying very quickly.

The old model assumes one person, one mailbox
Traditional mailbox pricing makes sense when each employee really needs their own mailbox seat.

But many small businesses do not actually work that way.

A two-person team may still need:

hello@
support@
info@
billing@
project-specific addresses across multiple domains
The visible address count grows because the business needs clear contact points.

The real operator count does not.

That is where the per-seat model starts to feel wrong.

Scenario 1: multiple projects, too much inbox switching
If you run more than one project or brand, email quickly turns into inbox switching.

You check one mailbox for one domain, another for a different project, and then have to remember which sender identity to use when replying.

That creates three kinds of friction:

context switching
scattered history
wrong-sender mistakes
Receiving in one place is only half the problem. Reply identity is the other half.

If a customer wrote to hello@site-a.com, your reply should also come from hello@site-a.com, not from your personal inbox and not from some unrelated project identity.

Scenario 2: small teams pay for addresses as if they were people
A small studio may have one or two people handling all incoming email, while still needing several outward-facing addresses.

Traditional mailbox tools often push that team toward buying more mailbox accounts just to preserve those identities.

But the team is not actually buying more handler capacity.

It is buying more visible addresses.

Those are different needs.

Scenario 3: people change, but the public address should not
Customer-facing addresses often outlive the person currently responsible for them.

That is especially common with support, operations, and project-based work.

When someone leaves or a project changes hands, mailbox-account-based setups often create handoff pain:

creating new accounts
migrating old history
reconfiguring clients
making sure the next person can keep replying cleanly
A better model keeps the public address stable and changes where it routes behind the scenes.

What I built instead
That is the problem I built OhRelay for.

It is not another mailbox suite.

It is a routing layer for teams that have:

more visible addresses than real handlers
more domains than they want to manage as separate mailbox accounts
a real need to keep replies coming from the correct branded identity
The model is simple:

Customers keep writing to the addresses they already know
Those addresses route into the inboxes your team already uses
Replies go back out from the correct branded address automatically
So instead of turning every address into another mailbox seat, you separate the address layer from the mailbox-account layer.

That fits the way a lot of small businesses actually work.

Final thought
A lot of small businesses do need business email.

What they do not always need is a separate mailbox account for every public-facing address.

Sometimes the real problem is simpler:

you need multiple branded addresses, but only one or two real inboxes behind them.

That is the gap OhRelay is meant to solve.

If you are dealing with this today, I would genuinely love to know how you are handling it:

separate mailboxes
aliases
forwarding rules
shared inbox tools
something else entirely

Product: OhRelay.com

The part Cloudflare Email Routing doesn't solve — and how I fixed it

nonozone — Thu, 02 Apr 2026 04:42:53 +0000

Cloudflare Email Routing is genuinely good. Free, reliable, zero infrastructure to manage. You point your MX records at Cloudflare, configure a few rules, and emails sent to support@yourdomain.com start appearing in your Gmail inbox within minutes.

If all you need is to receive email at a custom domain, it's hard to beat.

The problem starts when you hit reply.

What forwarding actually does

When Cloudflare forwards a message from support@yourdomain.com to your personal Gmail, it doesn't just move the email. It rewrites the envelope.

The original SMTP transaction looked like this:

MAIL FROM: customer@example.com
RCPT TO: support@yourdomain.com

After forwarding, the message arrives in your Gmail with extra headers like X-Forwarded-To and X-Original-To that record where it originally went. But your Gmail client doesn't read those headers. It sees one thing: this email arrived at your Gmail address.

So when you hit reply, your email client does the obvious thing — it replies from your Gmail address.

Your customer, who wrote to support@yourdomain.com, now gets a reply from yourname@gmail.com.

That's the gap. Cloudflare solved receiving. Nobody solved replying.

The obvious workarounds (and why they fall short)

1. Add a "Send As" alias in Gmail

Gmail lets you add custom From addresses via SMTP. So you add support@yourdomain.com as a Send As alias, pointing at a transactional SMTP provider.

This works — until you have more than one or two addresses. When you're managing support@, sales@, admin@, billing@ across two or three domains, you now have to:

Manually pick the correct From address every time you reply
Remember which address the customer originally wrote to
Hope you don't reply from the wrong one

At some point you will mis-send. A support@ customer gets a reply from founder@. A sales@ prospect gets a reply from your personal address. The professional illusion collapses.

2. Set up separate mailboxes per address

This is the traditional solution — buy a Google Workspace seat (or Fastmail, or Zoho) for each address. It works, but now you're paying per identity, not per person, and you're context-switching between inboxes all day.

If your address count grows faster than your headcount — which is common for small studios, agencies, and solo operators — this gets expensive fast.

What actually needs to happen

The root problem is that forwarded email loses its routing context by the time it reaches your client. To reply correctly, something needs to:

Preserve the original recipient address when forwarding
Read that context when you hit reply
Rewrite the envelope on outbound — so the SMTP MAIL FROM and the visible From: header show support@yourdomain.com, not your personal address

Step 3 is the key one. It's called envelope rewriting, and it's what makes the difference between "email forwarding" and "identity routing."

The flow looks like this:

Customer
  → support@yourdomain.com
  → Cloudflare Email Routing (inbound MX)
  → Relay layer (preserves routing context in headers)
  → Your working inbox (Gmail / Outlook / Apple Mail)

You hit reply
  → Mail client sends to relay's SMTP
  → Relay reads X-Original-To header
  → Relay rewrites MAIL FROM to support@yourdomain.com
  → Customer receives reply from support@yourdomain.com ✓

Your client sees one SMTP connection. You configure it once. After that, every reply automatically goes out from whatever address the original email was sent to — no manual selection, no switching, no mistakes.

Building this

I run a small one-person studio with a few projects, each with its own domain. I got tired of either paying per mailbox or manually managing Send As aliases. So I built a relay layer that sits between Cloudflare Email Routing and my working inbox.

The inbound side was straightforward: Cloudflare already stamps X-Forwarded-To and X-Original-To on every forwarded message. I just needed to make sure those headers survived into my inbox intact.

The outbound side was the real work. When you provide custom SMTP credentials to a mail client, the client hands off full control of the outgoing message. That's where envelope rewriting happens — inspect the message for routing context, determine the correct sender identity, rewrite the headers, and relay to the upstream MTA.

A few things that made this interesting to get right:

Sender verification: You can't let anyone claim any From address. The relay has to know which addresses are authorised for which accounts.
Header precedence: Mail clients sometimes set Sender: and Reply-To: in ways that conflict. Getting the priority chain right takes care.
Bounce handling: When a rewritten outbound message bounces, the bounce goes to MAIL FROM — which is now your domain address. You need to route those back correctly.

The result

After setting this up, the workflow became:

All domain email lands in one inbox
Hit reply — correct sender, every time, automatically
No manual address selection
No per-seat mailbox costs
No context switching

I called the tool OhRelay and opened it up to early access: ohrelay.com

It works on top of Cloudflare Email Routing, so if you're already using that for inbound, setup is mostly just DNS and one SMTP config in your mail client. The guide covers Gmail, Outlook, and Apple Mail.

If you've been living with the wrong-sender problem or managing too many mailbox seats, it might be worth a look. Happy to answer questions in the comments about how the relay layer works — it's an interesting corner of email infrastructure that doesn't get talked about much.