Cloudflare Email Routing is one of the easiest ways to get a working catch-all email address on a domain you already manage through Cloudflare, and that convenience is exactly where people get burned. The wizard walks you through MX records, then hands you a suggested SPF record, and the natural instinct is to paste it in. If that domain already sends mail through Google, Microsoft 365, or any other host, overwriting the SPF record is how you quietly break authentication for outbound mail you never meant to touch. The setup itself is fine; the mistake is in the DNS cleanup that follows.
How Cloudflare email routing actually works, and where the SPF trap sits
Here is the part most guides skip: a catch-all email is configured on the mail server, not in DNS. DNS only tells the world where to deliver mail. MX records route inbound mail to a mail server, and once it lands there, the receiving server decides whether an unknown recipient gets accepted or bounced. A standard mail server replies with 550 no such user when no mailbox matches, which is the default behavior everywhere. A catch-all tells the server to accept every message sent to a domain regardless of whether a mailbox exists, so anything addressed to a typo, an old employee, or an invented address still lands somewhere.
Cloudflare Email Routing is a forwarding service sitting behind those MX records. You point your MX records at Cloudflare’s hosts, verify a destination address, and Cloudflare forwards inbound mail to wherever you want it. The catch-all toggle in the dashboard is what makes it a catch-all domain rather than a fixed set of routes. That part is genuinely useful for unlimited unpredictable addresses in automation and sign-ups, where you generate a new address per service and never want to think about it again.
The trap opens when Cloudflare notices you have no SPF record or sees one it does not recognize, and offers to add its own. Cloudflare’s suggested record authorizes Cloudflare to send mail on your behalf, which matters for forwarding because forwarded mail gets re-sent from Cloudflare’s infrastructure. Pasting that record over an existing one is where SPF alignment dies. The existing record authorized your actual sending host; the new one authorizes Cloudflare. If your outbound mail still goes through Google or Microsoft, you have just told receivers that the host sending your real mail is not permitted.
Merge the include instead of replacing the record
The fix is unglamorous: keep your existing SPF record and append Cloudflare’s include to it. A domain sending through Google with Cloudflare forwarding on top should end up with something like v=spf1 include:_spf.google.com include:_spf.mx.cloudflare.net ~all, in a single TXT record. Never publish two separate SPF records on the same name. Receivers treat multiple v=spf1 records as a permanent error and fail the check outright, which is worse than the problem you were trying to solve.
The reason this matters beyond SPF itself is DMARC. SPF, DKIM and DMARC govern outbound mail only, and DMARC passes when either SPF or DKIM aligns with the From domain. If you break SPF and your provider signs with DKIM under its own domain rather than yours, alignment fails and DMARC starts rejecting or quarantining mail you never changed. This is the scenario that catches people: they set up email routing on a Tuesday, and by Friday their invoices are landing in spam folders, and nobody connects the two events.
Worth knowing: catch-all differs from alias, forwarding and disposable addresses in ways that affect your DNS too. An alias is a fixed extra address on an existing mailbox. Forwarding is a rule that sends matching mail elsewhere. A catch-all is the fallback rule mail server side that catches everything no other rule claimed. catchall email address is worth a closer look. Only the catch-all needs the wildcard behavior, and only the forwarding piece needs Cloudflare’s SPF include. If you are forwarding through Cloudflare, merge. If you are just adding aliases on a host that already handles your mail, you may not need Cloudflare’s MX records at all.
Step-by-step setup with the mistakes flagged at each stage
Start in the Cloudflare dashboard under Email, then Email Routing. Add your destination address and click the verification link that arrives in that inbox. Skipping verification is the first common failure; routes appear active but silently drop mail until the destination is confirmed. Once verified, enable Email Routing and let Cloudflare add its MX records. If your domain already has MX records pointing at Google, Microsoft, or a self-hosted Postfix or Exim box, Cloudflare will warn you that enabling routing replaces them. That warning is accurate, and it means inbound mail stops going to your old host. For a domain used only for forwarding and catch-all, that is fine. For a domain with real mailboxes on another host, think carefully before proceeding.
Next, open the catch-all settings and enable it with an action of your choice: send to a destination address, drop, or reject. Sending to a verified destination is the usual pick. Then check your DNS records by hand. Confirm the MX records point at Cloudflare’s hosts, confirm there is exactly one SPF TXT record, and confirm it includes both your original sender and Cloudflare if you are forwarding. This is the moment to merge rather than replace. If you are moving mail hosting entirely to Cloudflare, replacing is correct; if you are layering routing on top of an existing sending setup, replacing is the mistake that breaks DMARC.
Cloudflare’s routing is a forwarding service, not a mailbox, so there is no IMAP or POP3 access to the catch-all itself. Mail arrives, gets forwarded, and that is the end of it. That is a feature for automation use cases and a limitation if you expected to browse a catch-all inbox. For a real catch-all mailbox you can log into, you need a host running Dovecot or similar with the catch-all configured server side, and DNS pointing at that host instead. A working catch-all setup requires DNS pointing at the right host and a server accepting unknown recipients; get either half wrong and mail bounces or vanishes.
Finally, test it before you trust it. Send a message to an address you know does not exist, like randomstring123@yourdomain.com. It should arrive at your destination within a minute or two. Then send a message from your normal outbound host to an external Gmail address and check the authentication results in the headers. Look for spf=pass and dmarc=pass. If either fails on mail you did not touch, your SPF record is almost certainly the culprit, and the fix is merging the includes rather than replacing them. For a deeper walkthrough of the concepts, AllMail.one publishes a guide to catch-all email that covers the server-side behavior in more detail.
Catch-all carries the risk of accepting spam to invented addresses, so watch the volume after you enable it. If the spam gets heavy, switch the catch-all action to reject and rely on explicit routes instead. Keep your SPF record merged, keep exactly one TXT record on the name, and re-check headers after any DNS change. That routine takes five minutes and prevents the silent DMARC failure that turns a routine forwarding setup into a deliverability incident.
