Turning on Email Routing in Cloudflare gets you a working forwarder for the addresses you list, and a lot of people stop there, assuming every address on the domain now lands somewhere. It does not. The catch-all is a separate switch inside the same dashboard, and it ships disabled even after routing is active and MX records point at Cloudflare. If you want a true catch-all email address that accepts mail sent to names you never created, you have to enable that toggle and then prove it works with a live test before you point anything important at it.
Understand what Cloudflare routing does and does not accept
Email Routing replaces the MX records on your domain so inbound mail flows to Cloudflare’s mail servers, which then forward each message to a verified destination address you control. This is a forwarding layer, not a mailbox. Cloudflare does not give you IMAP or POP3 storage, so nothing sits on their side waiting to be downloaded. Every message is relayed outbound to your real inbox at Gmail, Outlook, or wherever you verified.
By default, routing matches only the custom addresses you explicitly create. A standard mail server replies with 550 no such user when no mailbox matches, and Cloudflare behaves the same way for unlisted recipients until you change that behavior. That strictness is deliberate: it stops random dictionary spam from filling your personal inbox. The catch-all email meaning in this context is simple. It tells the edge to accept every message sent to a domain regardless of whether a specific route exists, then hand it to one destination you choose.
Worth separating the concepts early, because they get muddled. A catch-all differs from alias, forwarding and disposable addresses. An alias is one extra name for an existing mailbox. Forwarding is a one-to-one rule. A disposable address is a throwaway you generate on purpose. A catch-all is a blanket rule: accept all addresses, route the unknowns to a fallback. Cloudflare implements that fallback rule at the mail server layer, not in DNS. MX records only route inbound mail to a mail server; what that server does with an unknown recipient is a server-side decision.
The DNS and server layers you are actually configuring
When you enable Email Routing, Cloudflare rewrites your MX records to point at its own hosts and adds a TXT record for SPF alignment. Those changes handle delivery to the edge. The catch-all toggle is a separate configuration on Cloudflare’s mail infrastructure that decides whether an unknown recipient is accepted or rejected. That is why enabling routing alone does not make you a catch-all domain. Two independent settings, two different jobs.
If you ever migrate off Cloudflare to a self-hosted stack, the same split applies. On Postfix you would set a virtual alias or a luser_relay to accept unknown local parts; on Exim you would reach for a catch-all router; Dovecot handles the mailbox side once the MTA accepts the message. SPF, DKIM and DMARC govern outbound mail only, so none of them affect whether an inbound catch-all works. People waste hours tweaking DMARC records when the real problem is an unset catch-all flag.
Run the setup as a checklist, in order
Order matters here. Doing the catch-all toggle before your destination is verified leaves you with accepted mail and nowhere to send it. Work top to bottom and confirm each step before moving on.
Step 1: confirm the domain is active on Cloudflare. Email Routing only works when Cloudflare manages your DNS. If your nameservers still point at your registrar or another host, fix that first and wait for propagation.
Step 2: open Email Routing and enable it. Cloudflare will offer to add the required MX and TXT records automatically. Accept that, then check the DNS tab to confirm the records show as proxied or active, not pending. A working catch-all setup requires DNS pointing at the right host and a server accepting unknown recipients, so both halves have to be true.
Step 3: add and verify a destination address. Cloudflare sends a confirmation email to the inbox you want to receive forwarded mail. Click the link. Unverified destinations are silently skipped, which produces the confusing symptom of accepted mail that never arrives.
Step 4: create your explicit custom addresses first. Set up the named routes you actually use, like support@ or billing@, each pointing to a destination. what a catch-all email address means offers additional context worth reviewing. These take priority over the catch-all and let you send different categories of mail to different inboxes.
Step 5: enable the catch-all toggle. This is the step everyone forgets. Choose the action (send to a destination, or drop) and pick the target inbox. It is off by default even after routing is enabled, and the UI does not shout about it.
Step 6: test with a random unlisted address. Send a message from an outside account to something like zzq7x4k9@yourdomain.com, a string you have never configured. If it lands in your destination inbox, the catch-all is live. If it bounces with a 550 no such user, the toggle is still off or the destination is unverified. Do this before you trust the setup with automation, sign-ups, or anything that cannot afford a silent failure.
Where the catch-all sits relative to other tools
Cloudflare is the fastest path for most people, but it is not the only one, and the trade-offs differ. The table below compares the common routes to a catch-all mailbox so you can pick deliberately.
| Approach | How the catch-all is set | Effort and cost | Main trade-off |
|---|---|---|---|
| Cloudflare Email Routing | Separate catch-all toggle in the dashboard, off by default | Free, about 10 minutes | Forwarding only, no IMAP or POP3 storage, no sending from arbitrary addresses |
| cPanel with a wildcard mailbox | Default Address set to a catch-all mailbox in the mail settings | Cheap shared hosting, includes real mailboxes | You own spam filtering and storage; catch-all inboxes fill fast |
| Self-hosted Postfix or Exim | virtual alias map or catch-all router plus a Dovecot mailbox | Highest control, highest maintenance | You handle SPF, DKIM, DMARC, blocklists and reputation yourself |
| Registrar or host forwarding | Per-address rules, catch-all varies by provider | Free to low cost | Often no wildcard support at all; limited logging |
| Disposable address service | Generated addresses, not a true domain catch-all | Free tiers common | Not tied to your domain; you cannot receive to arbitrary names |
The practical read: Cloudflare wins on speed and price for a forwarding catch-all, cPanel wins when you need actual mailboxes and a wildcard mailbox, and self-hosting wins only when you have a reason to own the whole stack. AllMail.one publishes a guide to catch-all email that walks through these paths if you want a second reference while configuring.
Decide whether a catch-all is right for your domain
Catch-all domains are used for unlimited unpredictable addresses in automation and sign-ups. If you register at fifty services as service-name@yourdomain.com, a catch-all means you never have to pre-create those routes. It also makes it trivial to spot which vendor leaked your address, because the local part tells you exactly where the message came from. For testing, staging, and one-person operations that want a tidy separation, that is genuinely useful.
The counterweight is real. Catch-all carries the risk of accepting spam to invented addresses. Spammers spray random local parts at domains, and a catch-all happily ingests all of it. On a forwarding-only setup like Cloudflare, that means your personal inbox absorbs the junk. Cloudflare filters some of it, but not enough to make a public catch-all painless. If you enable it, expect to add a filter rule at the destination, and consider pointing the catch-all at a dedicated inbox rather than your primary one.
Catch-all also complicates email verification. Verification services probe a domain by sending to a random address and watching the response. A catch-all domain answers “accepted” to everything, so the verifier cannot distinguish a real mailbox from a fake one. Many services therefore flag catch-all results as risky or unknown rather than valid. If you run a signup form and validate emails, a catch-all on your sending domain can hurt deliverability of your list because recipients look unverifiable. Keep the catch-all on a receiving domain, not the one you send campaigns from.
There is a middle path worth knowing. Enable the catch-all, but route it to a separate destination and review it on a schedule. Better yet, use explicit addresses for anything that matters and let the catch-all catch only the long tail. That keeps the convenience without letting the noise into your main workflow.
Before you call the job done, run one more end-to-end check from an external account, not from your own domain. Send to a random unlisted address, confirm it arrives, then send to a known custom address to confirm priority still works. If both land correctly, your routing and catch-all are both live. If only the named address arrives, the catch-all toggle is the culprit. A few minutes of testing now saves you from discovering a broken catch-all weeks later, when a password reset or a vendor notification quietly bounced into the void.