Cloudflare Email Routing Send Email: How to Actually Send From Your Domain

You set up Cloudflare Email Routing, got your domains receiving, and now you want to send email from those same domains. Maybe a password reset, an order confirmation, a reply to a customer. So you go looking for how to make Cloudflare email routing send email, and you land in a tangle of docs about Workers, bindings, and something called "Email Service" that might or might not be the same thing. Here is what is going on, how sending works, what it costs, and where it still leaves you stuck.

Cloudflare Email Routing still does not send email

Let's clear up the naming first, because Cloudflare rebranded and it confuses everyone.

What used to be called "Email Routing" is now part of a broader product called Cloudflare Email Service. Email Service has two halves:

• Email Routing handles incoming mail. It forwards messages sent to your domain to another mailbox you already own. This is the part that is free and works on any Cloudflare plan. It receives. It does not send.
• Email Sending (still in beta) handles outbound mail. This is the part you are looking for if you want to send email from your domain. It is a separate feature with its own setup, its own pricing, and its own limits.

So when people ask "can Cloudflare email routing send email," the honest answer is: Email Routing itself cannot. Cloudflare added a separate sending feature under the Email Service umbrella, and that is what handles outbound. They are two tools that happen to share a product page.

How Email Service sending actually works

If you want to send email from a domain on Cloudflare, here is what you are working with. Email Sending gives you three ways to get mail out:

Workers binding. You write a Cloudflare Worker (a serverless function), add a send_email binding to your wrangler config, and call env.EMAIL.send() from your code. This is the native Cloudflare path, fast but dependent on Workers.

REST API. A standard HTTP endpoint. You POST a JSON payload with your to, from, subject, html, and text to https://api.cloudflare.com/client/v4/accounts/{account_id}/email/sending/send with a bearer token. This works from any platform, not just Workers.

SMTP. Authenticated SMTP submission to smtp.mx.cloudflare.net:465. You can point any SMTP-capable app at it. Useful if you have existing code that speaks SMTP.

All three do the same thing under the hood. The catch is what surrounds them.

What it costs and what limits you hit

Email Sending requires the Workers Paid plan, which is $5/month. On the free plan you can only send to verified destination addresses (basically test sends to addresses you have confirmed). Sending to real recipients needs the paid plan.

On the paid plan you get 3,000 outbound emails per month included. After that it is $0.35 per 1,000 emails. Inbound routing is unlimited and free on both plans.

A few limits worth knowing before you build on this:

• 5 MiB max message size including attachments (25 MiB if sending to verified destinations only).
• 50 recipients per email combined across to, cc, and bcc.
• 30 domains per zone for both routing and sending combined.
• Daily sending limits start conservative for new accounts and scale up based on your reputation. You can request increases via a form.
• Transactional only. Cloudflare's own FAQ says Email Service is for transactional email, not marketing or bulk. They plan to add that later.

There is also a quiet gotcha: emails sent from a Worker using the send_email binding show up as "dropped" in the Email Routing summary, even when they delivered fine. You have to check the Email Sending metrics separately to track outbound success. That one catches people.

The catches that are not in the pricing table

Those numbers are clear enough. The friction is in the setup requirements.

You must use Cloudflare DNS. Email Service only works on domains hosted on Cloudflare's nameservers. If your domain's DNS lives somewhere else, you either migrate it or you are out of luck.

Each sending domain gets onboarded separately. You pick a domain from your Cloudflare account, and Cloudflare adds MX, SPF, DKIM, and DMARC records to a cf-bounce subdomain. That is per domain. Five domains means five onboarding passes.

There is no inbox and no reply button. This is the one that matters most for people who found us through our Cloudflare email routing reply guide. Email Sending is an API for firing outbound messages. It does not give you a place to read incoming mail, and it does not give you a way to hit "reply" on a message a customer sent you. You can build a Worker that receives an inbound email and fires back a response programmatically, but that is code, not an inbox. If you want to read a customer message and type a reply from your domain, Email Service does not have that.

No multi-domain inbox. If you run several domains, Email Routing can forward each one to a destination address, and Email Sending can send from each one. But there is no unified view across them. You are stitching together forwarding rules, Workers, and an external mailbox to approximate one inbox for multiple domains.

What you actually need vs. what Email Service gives you

Strip it down and most people who go looking for "Cloudflare email routing send email" want more than just an API endpoint. They want:

• Receive mail on their domain. Email Routing does this fine.
• Send email from that domain, authenticated. Email Service does this if you are on the Workers Paid plan and your domain is on Cloudflare DNS.
• Read and reply in one place. Neither half of Email Service gives you this.
• One inbox across every domain. No. Each domain is its own config, and you still need an external mailbox to read anything.

None of this is to knock Cloudflare. If you are already building on Workers and you want to fire transactional emails from your edge code, Email Service sending is a solid, cheap option. 3,000 free sends on a $5 plan is hard to beat for pure outbound volume. The gap is everything around the sending: reading, replying, and managing mail across domains without writing Workers for it.

Where Mailyond fits

We built Mailyond for the person who started with Cloudflare Email Routing, realized they also need to send, and then realized Email Service still does not give them an inbox to read and reply from.

The idea is simple:

• Add one DNS record per domain or subdomain and verify it. That sets up signed sending so your replies pass DMARC.
• Receive mail from any address on any of your domains in one shared inbox, tagged per domain.
• Reply from the right domain, authenticated, without logging into five things.
• Send transactional email from your app with a plain REST call. It is Resend-API compatible, so existing code points at it with one line changed.
• One flat price, every domain. Adding a project does not change the bill.

You keep your main email wherever it is. Mailyond runs alongside Gmail or Workspace, on a subdomain if you want, not instead of them. To be straight: it is live now, flat priced, and built for people juggling several domains rather than running one company mailbox.

If you came here from a sending problem and also need to reply, read our breakdown of why Cloudflare Email Routing can't reply and the full one inbox for multiple domains guide. For the cost angle across providers, see our Google Workspace alternative for multiple domains comparison or check the pricing.

The short version

Cloudflare Email Routing does not send email. Cloudflare added Email Sending (beta) under the Email Service product, and it works through a Workers binding, REST API, or SMTP. It requires the Workers Paid plan ($5/month), only works on domains using Cloudflare DNS, and is transactional only. 3,000 sends per month are included, then $0.35 per 1,000. What it does not give you is an inbox to read mail, a reply button, or one view across all your domains. If you need to send from your app and that is all, it does the job. If you also need to read, reply, and manage mail across several domains without writing Workers for it, that is the gap we built Mailyond to fill.