No Cloudflare Email Routing tutorial starts by explaining what the service doesn't do. They show the configuration in five steps, confirm that the email has reached its destination, and close. What is left out are the cases in which forwarding starts rejecting legitimate messages, catch-all becomes a spam tap, or Worker drops client email because a line of code threw an exception. These cases exist, they are predictable, and it is worth knowing about them before putting the service into production for something critical.
Sending via domain does not exist here
The most important point, and the most often misunderstood: Email Routing receives email. Only. There is no way to send a message from voce@seudominio.com using this service. When you set up forwarding and someone sends you an email to contato@seudominio.com, you receive it in Gmail. When you reply in Gmail, the sender the recipient sees is your Gmail address — not your domain alias.
To send email via your own domain you need a separate service: Resend, SendGrid, Mailgun, Amazon SES, Postmark, Brevo. Each of these will require its own DNS records — SPF and DKIM specific to the chosen provider. Cloudflare automatically configures SPF records for incoming, but it has nothing to do with the records that an outgoing provider will need. Anyone who mixes the two flows in the same DNS configuration ends up with authentication errors in both directions.
The deliverability problem with forwarding and DMARC
When Cloudflare forwards an email, it relays the message from its own servers — not the sender's original servers. This creates friction with DMARC that affects specific but important cases.
If the original sender has a DMARC policy with p=reject — common in banks, large companies, email providers like Gmail and Outlook — and the email is forwarded through Cloudflare, the final destination server receives a message whose header From: shows the original sender's domain, but whose sending IP belongs to Cloudflare. DMARC alignment fails because SPF checks the sending IP (Cloudflare) against the domain on From: (the bank, the company), and they don't align.
Cloudflare uses ARC (Authenticated Received Chain) when forwarding, which preserves the authentication information from the original hop. This improves the situation for providers who understand and respect ARC — Microsoft, Google included. But it is not universal. Some corporate email servers with stricter policies still reject forwarded email even with ARC. The practical result: you may miss legitimate emails sent from strict p=reject domains, and Cloudflare has no control over the receiving policy of the destination server.
There is no complete solution for this within Email Routing. Anyone who needs guaranteed delivery to all possible senders needs a solution with its own inbox — Google Workspace, Fastmail, Microsoft 365.
Catch-all and the spam that comes with it
Enabling catch-all *@seudominio.com is useful: any address you give in forms, newsletters and events falls into the same inbox without having to create aliases in advance. The problem is that spammers scan domains trying to deliver email to random addresses. With catch-all active, each attempt arrives in your inbox.
A domain with some exposure on the web can receive hundreds of emails a day to addresses that never existed — info@, admin@, noreply@, sales@, random variations. Everyone arrives. Gmail has spam filters, but the volume creates noise.
The mitigation within Email Routing itself is to route the catch-all to an Email Worker rather than directly to a destination address. The Worker can check if the destination address is one of the legitimate aliases you defined, reject anything that doesn't match, and forward only the rest. You maintain catch-all flexibility without accepting all the junk.
The Worker who drops email in production
Email Workers have a behavior that catches developers off guard: if the Worker throws an uncaught exception, the message is rejected with a 5xx error. There is no retry, there is no queue, there is no dead letter. The email disappears.
Imagine a Worker that POST to an external API to create a support ticket. The external API is down. The Worker throws a network error. The email from the customer requesting support is rejected — and you never find out unless the customer tries again and complains.
The correct pattern is to wrap all processing logic in a try/catch and, in catch, call message.forward() for a manual sorting address. The email is not lost, and you can process what failed after the external service comes back. Without this fallback, any transient failure in any Worker dependency becomes lost email.
What changes when you move beyond the base cases
Simple forwarding of a few aliases to Gmail or Fastmail addresses works reliably and without surprises. Problems appear when you add dependencies: Workers with external calls that can fail, catch-all without filtering, scenarios with senders that have restricted DMARC. In these cases the service is still useful, but it requires you to understand the failure surfaces and build corresponding mitigations.
Cloudflare doesn't prominently document these cases because most users won't encounter them. But for teams that rely on email more seriously — customer support, operational communication, integration with partners that use strict DMARC policies — it's worth testing before migrating, especially checking behavior with senders from large corporate providers.
Also read
- Cloudflare Email Routing: receive email on your domain — and what's not included
- SPF, DKIM, and DMARC with Email Routing: What Cloudflare Sets Up and What You Still Need to Do
- Email Routing vs Improvmx vs Forward Email: honest comparison
- Email Routing + Workers: Programmatically process emails on edge
- Cloudflare DNS: network infrastructure that goes far beyond resolving names
- Cloudflare Load Balancing and Geo Steering: When DNS becomes an intelligent traffic layer