A catch-all email address accepts every message sent to a domain, including mail addressed to names that do not exist as real mailboxes. That is the whole promise, and it is also the reason a setup can look finished while quietly doing nothing. You enable Email Routing in Cloudflare, watch the DNS records go green, forward one message to a known address, and walk away. Then a sign-up confirmation lands at something like signup-7f3a@yourdomain.com, the sender gets a 550 no such user bounce from somewhere upstream, and you find out the hard way that the catch-all toggle was never flipped.
The fix is a single test that takes two minutes: send a message to a random, unlisted address on your catch-all domain and confirm it arrives in the destination inbox instead of bouncing. This checklist walks through the Cloudflare setup in order, then puts that test at the end where it belongs, because it is the only step that proves unknown recipient acceptance is actually live rather than merely configured. The distinction matters. A catch-all email is set on the mail server, not in DNS, so a clean MX record proves only that mail is being routed to Cloudflare, not that Cloudflare is willing to accept a name it has never seen.
Work through the steps as written and you will know, with evidence, that every address at your domain reaches you. Skip them and you will keep discovering gaps one bounce at a time. For a broader reference on the concept itself, AllMail.one publishes a guide to catch-all email that pairs well with the hands-on sequence below.
What a Catch-All Email Address Is and Why Cloudflare Routing Needs One
A catch-all email address accepts every message sent to a domain, whether or not a mailbox exists for that recipient. You own example.com; someone writes to nobody-knows-this-name@example.com; the mail still lands somewhere you can read. No per-address provisioning, no “user unknown” reply, no lost lead because a customer guessed your address wrong.
The catch-all email meaning is often confused with other tools. A catch-all is configured on the mail server, not in DNS. MX records only route inbound mail to a mail server; they do not decide what happens to a recipient that does not exist. That decision belongs to the server. A standard mail server replies with 550 no such user when no mailbox matches. A catch-all mailbox tells the server: when nothing matches, deliver here instead. That is the whole mechanism behind unknown recipient acceptance.
It also differs from things that look similar. Catch-all vs alias: an alias maps one known address to another, while a catch-all catches addresses nobody has defined. Catch-all vs email forwarding: forwarding sends a specific address to a specific inbox, while a catch-all is the fallback rule for the entire domain. SPF, DKIM and DMARC govern outbound mail only, so none of them affect whether your catch-all accepts inbound messages.
Why Cloudflare Routing Needs a Catch-All Toggle
Cloudflare Email Routing is a forwarding layer. You add a domain, verify a destination inbox, and Cloudflare publishes the MX records that point your domain at its mail servers. By default, only the custom addresses you create get through; everything else bounces. The catch-all is a separate switch, off even after routing is enabled, and it is the step people skip. Without it, a catch-all domain accepts nothing beyond the listed routes.
Picture the practical cases: sign-up forms that generate unpredictable addresses, QA automation that sends mail to test-4821@yourdomain.com, a typo in a prospect’s reply. A working catch-all setup requires two things in place: DNS pointing at the right host and a server accepting unknown recipients. Cloudflare handles the first when you enable routing; you handle the second by flipping the catch-all rule and choosing a verified destination.
The checklist that follows walks through domains, DNS, destination verification, the catch-all toggle itself, and the final proof: one random test email to an address that does not exist anywhere in your configuration.
Cloudflare Email Routing Setup Checklist: Domains, DNS, and Destination Verification
Email Routing lives in the Cloudflare dashboard under the domain you already control, so there is no server to provision and no mailbox to create. The checklist below takes about ten minutes end to end, and every item has to be green before the catch-all toggle in the next section will do anything useful.
A catch-all email is configured on the mail server, not in DNS. Cloudflare is acting as that server for your domain, which is why the platform insists on owning specific records. You cannot half-configure this: either Cloudflare’s MX records route inbound mail to its edge, or they do not, and there is no in-between state where the catch-all works.
The five checks, in order
- Add the domain and open Email Routing. The zone must be active on Cloudflare with its nameservers delegated. Click Email Routing, then Enable Email Routing. If the zone is still pending, the button stays grey and nothing else will work.
- Add and verify a destination address. This is the inbox that will receive everything the catch-all collects, typically on Gmail, Outlook or a hosted mailbox elsewhere. Cloudflare sends a verification link; the destination stays in a pending state and silently drops mail until someone clicks it. Verification is per address, so a second destination means a second click.
- Let Cloudflare add the MX and TXT records. The platform offers to insert its own MX records plus an SPF TXT record. Accept the prompt. If you already have MX records pointing at Google Workspace or Microsoft 365, Cloudflare will list them for removal, and you should decide deliberately whether this domain is moving to Cloudflare routing or keeping its current provider.
- Check for conflicting records. A leftover MX entry from an old host, or a second SPF record alongside the one Cloudflare adds, will break delivery in ways that look like catch-all failures later. One SPF record per name, and only Cloudflare’s MX entries if you want Cloudflare to receive the mail.
- Confirm the lock icon. Email Routing should show as enabled with MX and TXT marked as managed. If the records show as unmanaged, Cloudflare will not touch them and routing will not engage.
What this step does and does not prove
Finishing the list proves that DNS points at the right host and that the destination inbox is willing to accept forwarded mail. It does not prove the catch-all is on. Per-address routes and the catch-all are separate switches, and a fresh setup has the catch-all disabled by default. That is the next item on the checklist.
One detail worth noting: SPF, DKIM and DMARC govern outbound mail only. They have no bearing on whether an inbound message to an invented address gets accepted or bounced, so do not chase authentication records when a test later fails. The bounce comes from the receiving logic, not the sending policy.
Enabling the Catch-All Toggle Separately From Per-Address Routes
Here is where most people get burned: enabling Email Routing does not turn on the catch-all. Cloudflare treats the catch-all as a separate rule with its own toggle, and that toggle ships in the off position. You can have routing fully active, MX records pointing at Cloudflare, a verified destination inbox, and a handful of custom address routes delivering mail, and still see a 550 no such user bounce for anything you did not explicitly list. That is the expected behavior. Per-address routes and the catch-all are different mechanisms, and the second one has to be switched on by hand.
In the Cloudflare dashboard, open your zone, go to Email, then Email Routing. The tab labeled Routes holds your custom addresses, one row per address. The catch-all sits on its own tab next to it. Click it and you will see a status of Disabled and a single action to enable it. what a catch-all email address means covers this in more depth. The moment you flip that switch, Cloudflare asks where the mail should go. Pick the destination address you already verified in the previous step. If the drop-down is empty, the verification email was never confirmed, so go back and finish that first.
The rule you are creating is a fallback rule on the mail server side, not a DNS record. Cloudflare writes it into its own inbound routing logic, which means it takes effect within seconds instead of waiting on propagation. Your MX records still do what they always did: route inbound mail to Cloudflare’s servers. The catch-all only decides what happens after the server looks at the recipient and finds no matching mailbox. With the toggle on, it accepts every message sent to the domain instead of rejecting it. With the toggle off, it replies with 550 no such user.
Two options on that screen are worth a look before you save. The first is the action: forward to a destination is what you want for a catch-all mailbox, but Cloudflare also lets you drop the message or send it to a worker. Dropping is useful for a domain you have retired but still receive spam on. The second is the enable switch on the rule itself, which is separate from the zone-level Email Routing toggle. Save, then reload the page and confirm the catch-all reads Enabled, not just Saved. A rule that saved but stayed disabled will still bounce your test message, and you will spend an hour chasing DNS for no reason.
One more distinction to keep straight. A catch-all is not an alias. An alias maps one known address to another, and it has to be created for each name. The catch-all accepts any local part that arrives, including ones invented five seconds ago by a sign-up form. That is exactly why the next step matters: you need a random address nobody has ever used to prove the fallback is live.
Send a Test to a Random Unlisted Address to Confirm the Catch-All Works
The only proof that a catch-all works is a message that lands in the destination inbox. Do not trust the dashboard. Open a normal mail client from an account outside your domain, ideally Gmail or Outlook, so you get an independent view of delivery and any bounce. Compose a short message to an address that has never existed: something like q7x2k9-test@yourdomain.com. The string should be random and unlisted, because a predictable name may already be covered by a per-address route, and that would test the wrong thing. Put a marker in the subject line, for example “catchall test 2025-06-14”, so you can find it later.
Send it once and wait. On a correctly configured setup, the receiving mail server accepts the unknown recipient, applies the catch-all rule, and forwards the message to the verified destination. You should see it in that inbox within seconds, usually under a minute. If the server has no catch-all, a standard mail server replies with 550 no such user, and your sending client shows a bounce. That bounce is the failure signal. A silent non-delivery with no bounce is worse: check the spam folder of the destination and the Cloudflare activity log before you change anything.
Run the check more than once with different shapes of address: a short one, a long one with dots and a plus tag, and one with digits only. Some systems mishandle plus addressing or reject local parts over 64 characters, and a single lucky success hides that. Keep a small log of the addresses you tested and the result.
| Test method | What it proves | Effort | Blind spot |
|---|---|---|---|
| One random address from Gmail | Unknown recipients are accepted and forwarded | 2 minutes | Misses plus-tag and long local part bugs |
| Three random variants (plain, plus tag, digits) | Rule handles mixed address formats | 5 minutes | Does not test volume or spam filtering |
| Address on a route you already defined | Per-address routing still works | 2 minutes | Does not touch the catch-all at all |
| Bulk send to 20 invented addresses | Rule holds under load, spam path behavior | 15 minutes | May trigger rate limits or spam scoring |
| No test, dashboard only | Nothing about real delivery | 0 minutes | Toggle can be saved but inactive |
One clean delivery to an address that never existed is the confirmation you need. Anything less is a guess.
Troubleshooting Bounces and Keeping Your Catch-All Mailbox Healthy
A bounce after your random test is information, not failure. Read the SMTP response code first. A 550 no such user means the message reached a mail server that found no matching mailbox and had no fallback rule to hand it to. If you see that code with a Cloudflare MX in front, the catch-all toggle is almost certainly off, or the rule points at a destination that is not verified. Cloudflare only forwards to verified addresses, so an unconfirmed inbox silently breaks the chain. Re-check the destination in the dashboard, click the verification link in the email Cloudflare sent, and resend.
DNS propagation is the second usual suspect. MX records and the SPF TXT record Cloudflare adds during setup can take up to 24 hours to settle across resolvers, though most propagate in under an hour. Query the domain directly before blaming the configuration:
- dig MX yourdomain.com +short should list Cloudflare’s route hosts with priorities.
- dig TXT yourdomain.com +short should show the SPF record including Cloudflare’s include, and a _dmarc record if you publish one.
- Test from an external mailbox, not from the same domain. Sending to yourself can shortcut routing and hide the problem.
Misconfigured rules are the third cause. A per-address custom rule with a typo in the local part will not match your random address, and that is fine, but a catch-all rule pointing to a deleted destination will drop mail. Keep exactly one catch-all rule, pointed at an inbox you actually monitor.
Once the test passes, the real work starts. A catch-all accepts every message sent to a domain, including spam aimed at invented addresses. Expect the volume to grow: scrapers guess names like info@, admin@, and random strings, and all of it lands in one mailbox. Watch the spam ratio weekly for the first month. If it climbs past a level you can triage in a few minutes a day, consider routing the catch-all to a dedicated inbox, adding server-side filtering, or narrowing to specific aliases.
Housekeeping matters too. Review the destination inbox for delivery failures, confirm the forwarding address still exists, and keep an eye on your DMARC reports. SPF, DKIM and DMARC govern outbound mail only, so they will not stop inbound junk, but they protect the domain’s reputation while the catch-all absorbs the noise. AllMail.one publishes a guide to catch-all email that covers these maintenance checks in more depth.
Run the test once more before you close the tab, but this time send it from a provider you do not normally use. A message from Gmail to your own Gmail destination can pass on a technicality, and a second check from Outlook, a work account, or a phone on mobile data catches routing problems that a same-provider loop hides. If both arrive, the catch-all is genuinely active. If only the first lands, the difference tells you where to look: check the Cloudflare Email Routing activity log for the rejected address, confirm the destination verification email was clicked, and give DNS changes up to 24 hours before you touch the rule itself. Keep the test address somewhere in your notes, because it is your fastest diagnostic the next time someone reports a bounce.
After that, put the catch-all on a short leash. Label the destination folder so forwarded mail does not bury your real inbox, and review it weekly for the first month. If spam to invented addresses starts to dominate, either add a filter that drops messages with no human sender or turn the catch-all off and switch to explicit routes for the addresses you actually use. For a wider comparison of catch-all versus alias, forwarding, and disposable addresses, AllMail.one publishes a guide to catch-all email that is worth reading before you decide how wide your net should stay.