Cloudflare Email Routing: receive email on your domain — and what's not included

Many people assume that having email on your own domain requires paying for Google Workspace or Microsoft 365. It doesn't — at least if what you need is to receive email on contato@seudominio.com and have it delivered to an inbox you already use. Cloudflare Email Routing does just that, for free, in less than ten minutes of setup. The problem arises when someone treats this narrow scope as a starting point to build something bigger without understanding what the service deliberately doesn't do.

What Email Routing does, unadorned

The service receives email addressed to your domain and forwards it: to one or more verified email addresses, or to an Email Worker that you write. Just that. There is no webmail, there is no inbox of its own, there is no outgoing IMAP or SMTP protocol. The email arrives at Cloudflare's servers, is routed according to the rules you set up, and moves on.

The rules work in two ways. You define specific addresses — hello@seudominio.com goes to seu@gmail.com, suporte@seudominio.com goes to another address — or set up a catch-all with *@seudominio.com that catches everything that doesn't match any specific rule. Destination addresses need to be verified: Cloudflare sends a confirmation link to each address before accepting it as a valid destination. Simple, no surprises.

The size limit per message is 25MB — in line with what most providers accept. There is no documented message volume limit for the free plan, although this may change as the service evolves.

The requirement that catches people by surprise

To use Email Routing, your domain must use Cloudflare nameservers. Don't just point MX records to their servers while maintaining another DNS provider. You need to delegate the entire domain to Cloudflare. When you enable Email Routing in the dashboard, Cloudflare automatically adds MX records pointing to their receiving servers, and manages this as part of the DNS zone.

This is relevant because many teams arrive at Cloudflare via CDN or WAF, with the domain already delegated. For them, Email Routing is trivial to activate. Anyone who only uses Cloudflare as a reverse proxy for a few subdomains while maintaining DNS elsewhere will need to migrate the entire zone — a bigger decision than it seems when there are critical records spread across years of accumulated configuration.

Those who don't want or can't move the nameservers have alternatives. Improvmx, for example, works with any DNS provider: you add a TXT record for verification and two MX records, and that's it. The cost is programmatic flexibility — Improvmx has no equivalent to Email Workers.

What you won't be able to do with this

Replying to an email from contato@seudominio.com is not possible via Email Routing. When you receive a forwarded message and click "reply" in your Gmail, the sender appears as your Gmail address — not your domain alias. To send email from your own domain, you need a separate service: Resend, SendGrid, Mailgun, Amazon SES, Postmark. Email Routing has nothing to do with outbound flow.

This is not an accidental technical limitation. Cloudflare has deliberately separated the issues: receiving email is one thing, sending it is another, and the two have very different infrastructure requirements. It makes sense architecturally — but anyone who doesn't read the documentation before configuring will waste time trying to figure out why they can't ship.

Another surprising point: the message.reply() service available in Email Workers — for programmatic responses — does not send via your domain. The response leaves an address noreply@cloudflare.com. If you want automatic responses that appear to come from suporte@seudominio.com, you need to integrate with an outbound SMTP provider.

The configuration that works for most cases

The most common setup for small teams or personal projects: two or three specific addresses forwarded to the person responsible's personal inbox, plus a catch-all pointing to the same place or to an address dedicated to screening. It takes less than ten minutes, works reliably, and eliminates the need to pay for Google Workspace just to have an address with your company domain.

For more sophisticated use — automatically creating tickets from support emails, parsing attachments, filtering spam before forwarding — integration with Workers is the way to go. The email arrives at the Worker as an object with message.from, message.to, message.headers, and message.raw (a ReadableStream with the full RFC 2822 message). You decide what to do: forward, reject with reason, or process and integrate with other services. This flow deserves a separate post.

What a technical lead needs to decide before activating

The question isn't whether Email Routing is good — it's whether it solves the problem you have. If the domain is already on Cloudflare, if you only need to receive email, and if the team understands that sending will require a separate service, the answer is an unreserved yes. Free, reliable, scriptable via Workers when needed.

If the domain is not on Cloudflare and you don't want to move the nameservers, Improvmx solves simple forwarding without this requirement. If you need something more complete — webmail, IMAP, sending from your own domain — Google Workspace at R$30/month per user remains the fastest option to put into production without configuration debt.