A Cloudflare Email Routing support address is the cheapest way to get support@yourdomain.com into a mailbox you already read: $0, no mail server, about 10 minutes. I set one up for my own domain earlier this month, and the same address now receives my metrics alerts and my support mail.
That second part is the problem this note ends on. The setup is the first half; the three limits are the second.
What Cloudflare Email Routing does and does not do
Email Routing takes over your domain's MX records and forwards inbound mail to a destination address you have verified. It stores nothing.
Sending is a separate product, Email Sending, under the same Email Service umbrella. Routing by itself is a reliable, free forwarder that lives in your DNS.
How do you set up a support address on Email Routing?
Enable Email Routing on the zone, verify one destination mailbox, add one rule for support. Cloudflare writes three MX records and one SPF TXT record for you; the destination gets a verification link; the rule maps support@yourdomain.com to that destination. Nothing forwards until the link is clicked. The whole thing is three dashboard screens and one dig to confirm.
Step 1: enable it
Dashboard, Compute, Email Service, Email Routing, Get started on your zone. If the zone already has MX records pointing elsewhere, Cloudflare flags the conflict and offers to replace them; there is no "run both" mode.
dig +short MX yourdomain.com
# route1.mx.cloudflare.net.
# route2.mx.cloudflare.net.
# route3.mx.cloudflare.net.Step 2: add a destination
Destination addresses, add the personal mailbox you already read. Cloudflare emails a verification link. Until it is clicked, rules to that address do nothing.
Step 3: create the rule
Routing rules, custom address support, action Send to an email, pick the destination. Optionally turn on Catch-all so anything@yourdomain.com lands somewhere instead of bouncing.
# from any other account
echo "ping" | mail -s "routing test" support@yourdomain.comTen minutes. This is where most tutorials stop, and where I stopped too.
3 things Email Routing can't do
It can't store mail. There is no mailbox. If the destination filters a message to spam, it is gone from Cloudflare's side. The dashboard keeps an Activity log of recent messages and a daily forwarded/dropped count, and that is all, unless the rule targets a Worker (next section).
It can't be shared. A rule maps one address to one destination. To copy two people you already need a Worker calling forward() twice, and then each person has a copy with no idea whether the other replied. The moment a second person needs to see support mail, the personal-inbox approach breaks.
It can't reply as support@ later. Hitting reply in your mailbox sends from your personal address. An Email Worker can call message.reply(), but only once, inside the same SMTP session, to the original sender. A human answering an hour later needs Email Sending or another provider.
Where an Email Worker gets you
Instead of "Send to an email", a routing rule can target a Worker. The Worker receives the raw message as a stream and can store it, forward a copy, or reject it:
export default {
async email(message, env, ctx) {
const raw = await new Response(message.raw).text();
await env.DB.prepare("INSERT INTO mail (from_addr, to_addr, raw) VALUES (?,?,?)")
.bind(message.from, message.to, raw)
.run();
await message.forward("you@personal.example"); // destination must be verified
},
};That is the whole trick behind having an inbox: the Worker is the inbox. Messages up to 25 MiB per the Email Routing limits, on the free plan, no extra bindings.
The 30-line version with a D1 schema and the three self-hosted inboxes built on it is in Cloudflare Email Worker inbox: store every message in D1. If you are weighing this against a paid mailbox, see Cloudflare Email Routing vs Google Workspace vs Zoho.