Cloudflare email
Cloudflare Email Routing Can Receive — Here's How to Send, Too
Email Routing is a mail slot, not a mailbox: letters drop in, and nothing leaves through the same hole. "How do I send, then?" only sounds like a hard question until you see that receiving and sending are two separate machines that never came in the same box — and that you don't have to be a developer to connect them.
This is the no-code map. We'll leave the actual Worker code to the developer's guide and answer the question most people are really asking: given that Routing already catches my mail, what are my options for sending — and exactly which ones need a programmer?
What Cloudflare Email Routing actually does
Email Routing is an inbound service. Turn it on for a domain and Cloudflare publishes the MX records that tell the world "send this domain's mail here," then forwards each message to a verified destination, applies a catch-all so nothing bounces, or hands it to an Email Worker. Every one of those is about receiving. Routing is a very good doorman for your domain's mail; what it is not is a post office that accepts your outgoing letters.
Why Cloudflare Email Routing won't send email on its own
There are two honest reasons Routing stays receive-only. First, sending mail is a reputation game — receiving systems judge outbound mail by the sending address, the domain's authentication, and the track record of the IP it came from, and keeping that reliable is a specialist's job Cloudflare keeps Routing free by not taking on. Second, an open sender is an abuse magnet: a service that would send to anyone on anyone's behalf is exactly what spammers want, and staying inbound-only sidesteps that entirely.
Receiving is a solved, free utility. Sending is a reputation you have to earn — which is why it lives with specialists, not with the doorman.
The no-code decision guide
Before anyone tells you to "just write a Worker," here's the honest split: what you can do with no code at all, and where code — yours, or an app that already contains it — becomes the only way.
You can send with no code if…
- You use a mail app built for this pattern. It holds both ends — receives through Routing, sends through a provider — so you just open it and hit reply. This is the closest thing to "Routing that sends," and the subject of the mail app built for Cloudflare.
- You only need the occasional message. Once your domain is verified with a sending provider, you can compose by hand in the provider's own dashboard — fine for a one-off, clumsy for everyday mail.
- You accept the forwarding stopgap. Keep forwarding into your personal inbox and reply from there. It works, but your answers leave from your personal address, not the domain the mail came to — the reply trap that quietly breaks the illusion you own the address.
You need code (or an app that already has it) if…
- Replies must go out from the exact address they came to, automatically, every time.
- You want to send from your own website or app, on a schedule, or in reaction to incoming mail.
- You want one inbox that unifies receiving and sending across every domain you own.
Put simply: the no-code routes get you sending; the coded routes get you sending well — automatically, from the right address. Don't want to write that? An app that already wires Routing to a provider is the shortcut — the Workers guide has the code, but you needn't read a line to use an app that already did.
Exactly which DNS records sending needs
Here's the detail that trips people up most: receiving needs one kind of record, sending a different set, and the confusion is not knowing which side each belongs to. This table settles it — your provider hands you the exact values, so you never invent one.
| Record | What it does | Which side | Who gives it to you |
|---|---|---|---|
| MX | Points incoming mail at Cloudflare | Receiving | Cloudflare — added automatically when you turn Routing on |
| SPF (a TXT record) | Lists which services may send for your domain | Sending | Your sending provider |
| DKIM (a TXT or CNAME record) | Publishes the key that verifies each message's signature | Sending | Your sending provider |
| DMARC (a TXT record) | Tells receivers what to do when SPF or DKIM fail, and can report spoofing | Sending | You choose the policy; the provider suggests a starting point |
Read the "which side" column and it clicks: MX is your receive machine; the other three are your send machine. Turning Routing on handled the first row — sending is entirely about the other three. Add them in the same Cloudflare DNS dashboard your domain already uses, then confirm them with our SPF, DKIM and DMARC checker.
The no-code walk-through: receive-only to sending
Here's the whole path as an ordered checklist — every step happens in a dashboard, not an editor. The first three switch on receiving; the last four add sending. No Worker, no code.
- Enable Email Routing. In the Cloudflare dashboard, open your domain → Email → Email Routing and turn it on. Cloudflare adds the MX records for you.
- Verify a destination. Add the real inbox you want mail forwarded to, then click the confirmation link Cloudflare sends it. Nothing forwards until that destination is verified.
- Set a catch-all. Point every address on the domain at that verified destination, so sales@, hello@ and anything else lands instead of bouncing. Receiving now works.
- Add your domain to a sending provider. Create an account with a transactional email provider and start its "add a domain" flow — this is the piece that will actually push mail out.
- Publish the records it gives you. The provider shows an SPF entry, a DKIM key, and a suggested DMARC record. Add each one in the same Cloudflare DNS tab your domain already uses — copy and paste, no inventing values.
- Confirm the domain is active. Back in the provider, click "verify." It re-reads your DNS and flips the domain to verified — sometimes at once, sometimes after the records propagate.
- Send a test. Mail yourself at an outside address from the verified domain and check it arrives out of spam and shows as authenticated — proof sending is live.
Follow those seven and Routing receives while your provider sends — two machines, connected, no code between them.
Common mistakes when adding sending
Most of the trouble isn't with Routing — it's the sending half. Three traps recur: sending from a domain you haven't verified (the provider must confirm you own it first, or mail bounces); forgetting DMARC alignment, where SPF and DKIM have to pass for the exact domain in your "from" address, not just any domain, or strict receivers distrust the message; and treating a transactional provider like a bulk mailer, which hits sending limits fast. None are hard to dodge once you know they exist — they're the gap between "it technically sent" and "it landed, from the right address, every time."
The honest limits
Two things plainly. First, sending depends on a third party — some provider does the delivery, and that's a relationship you're choosing to have; you can switch providers, but you can't make Routing send by itself. Second, deliverability is ongoing, not one-and-done — good authentication gets you most of the way, but sending habits (volume, complaints, list hygiene) still matter over time. Neither is a reason to avoid the approach: it's the trade for not running your own mail server, which for almost everyone is the better one.
- Can Cloudflare Email Routing send email by itself?
- No. It only receives and forwards. To send, you add a transactional sending provider's API and configure SPF, DKIM and DMARC on your domain.
- Do I lose my forwarding if I add sending?
- No. Receiving through Routing and sending through a provider are independent. You can keep catch-all forwarding and still send proper replies.
- Will my sent mail land in spam?
- Not if the domain is authenticated. With SPF, DKIM and DMARC in place and a reputable sending provider, your mail is treated like any other legitimate business email.
- Is this hard to set up without coding?
- The DNS records are copy-and-paste. The connecting logic is where an app that's already built for this — receiving via Routing and sending via an API — saves you the development work.