LetterDuck
Business email

Catch-all email: what running one in production is actually like

Our entire inbound pipeline is a catch-all: every address at the domain, real or invented, routes through one rule. Here is what that buys, what it costs, and how to set one up.

Every address at our domain, including ones we have never created, delivers through a single catch-all route, and that route has carried our production mail since June 2026. A catch-all accepts mail for any address at a domain that has no explicit mailbox or rule of its own. Most write-ups of the idea are theoretical; ours runs, gets probed by an automated canary every two hours, and has already taught us one expensive lesson. This article covers how a catch-all routes, the honest pros and cons, the setup steps, and what one actually sees day to day. Where a catch-all fits in a full domain setup is mapped in our business email setup guide.

How a catch-all routes, using ours as the worked example

Routing happens in layers, and the catch-all is the last layer before a bounce. In our stack the path looks like this:

  1. The domain's MX record points at Cloudflare, so every message for any address at the domain arrives there first (the mechanics of that record are in our MX record guide).
  2. Cloudflare Email Routing checks its explicit rules. No match falls through to the catch-all rule.
  3. Our catch-all does not forward to a mailbox; it hands the raw message to a Worker, which parses it and writes it into our database as the source of truth.
  4. The inbox threads it, whatever local part it was addressed to.

The important property: the address was never the gatekeeper. Delivery depends on the domain, and the local part becomes routing metadata you can organize by afterward. That single property is where every pro and every con below comes from.

Because a catch-all fails silently by nature (a broken rule does not bounce mail, it just loses it), we watch ours mechanically: every two hours, a cron job sends a canary message through the real path, DNS to routing to parser to database, and alerts the owner if it fails to round-trip. Silence means healthy. The full teardown of that watchdog is in how we monitor inbound email.

The real pros

Typos still arrive. Mail to sale@ instead of sales@, or to a mangled first name, delivers instead of bouncing off a stranger's reply. A bounced reply from a customer is usually a conversation that dies; the catch-all quietly saves those. This is the single strongest argument for running one on a domain where humans give the address out loud, over the phone, or on paper.

Addresses are free to invent. Give a vendor vendor-name@yourdomain on the spot and filter on it later; the address exists the moment mail arrives for it. This is the same discipline as alias-per-purpose without the setup step per address. Our whole workspace is built on this: because inbound is a catch-all, "unlimited addresses" is not a quota we grant, it is a property of the routing.

Migration insurance. Addresses from an old provider, a former employee, or a design from three redesigns ago keep landing somewhere reviewable instead of bouncing into the void.

The real cons, from running one

The spam surface is the whole dictionary. On a fixed-address domain, mail to guessed addresses bounces at the door. On a catch-all domain every guess is deliverable, so dictionary spray against the usual suspects (info, admin, billing, test, hr) and against random strings all gets through to your filter instead of the SMTP reject. You inherit a filtering job the bounce used to do for you.

Backscatter finds you. Spammers forge random addresses at your domain as their From address; the bounce notices for that spam then come back to addresses that never sent anything, and your catch-all dutifully accepts them. Arriving in bursts, backscatter is noise you cannot unsubscribe from, only filter.

Verification tools mark you accept-all. Because a catch-all domain accepts everything, verification services cannot confirm that any single address is real, so they grade the whole domain "accept-all" and some senders treat that as risk. Expect a little more friction from strict signup flows, and expect role addresses like info@ to accumulate service signups you never made.

You lose the existence signal. With no bounce for wrong addresses, you cannot tell a correspondent their address book entry is stale, and you cannot enumerate which addresses are "real" without keeping that list yourself.

One more warning, and this one cost us. For a while our pipeline forwarded a copy of every inbound message onward to a Gmail mailbox by plain forwarding. Gmail was rejecting 73 percent of those forwards, silently, because forwarding breaks DMARC alignment: the mail arrives at Gmail claiming to be from the original sender but handed over by our server. Nothing errored on our side; copies just vanished. We diagnosed it in June 2026 and replaced the forward with an API insert into the mailbox. If your catch-all forwards onward to another provider, do not trust it until you have watched a test message arrive at the far end.

When to run one

Run a catch-all if you are a solo owner or a small team on your own domain, if you are migrating a domain with years of address history, or if you want address-per-purpose without administration. It suits a domain where one inbox or one team triages everything anyway.

Skip it when per-address accountability matters more than coverage: a larger org where info@ must be provably separate from legal@, or any domain where nobody will actually watch the default route. A catch-all nobody reads is worse than a bounce, because the sender believes they reached you. And on a dedicated cold-outreach domain a catch-all buys you nothing; that setup has different rules entirely.

Setup steps

At most hosts this is one setting. Three common paths:

Cloudflare (free, what we run): in the dashboard, pick the domain, then Email, then Email Routing. Enable it and let it install its MX and SPF records automatically. Under Routing rules, set the Catch-all address to Active, with an action of either "Send to an email" (any destination you verify) or, as in our stack, "Send to a Worker".

Google Workspace: in the Admin console, go to Apps, then Google Workspace, then Gmail, then Default routing. Add a rule matching unrecognized addresses and route them to a mailbox of your choice.

cPanel-style hosting: Email, then Default Address, then "Forward to email address" for all unrouted mail.

Whatever the host, finish with a test: send a message to an address you have never created, from an outside account, and confirm where it lands.

What ours actually sees

A production catch-all's diet, honestly described: our own canary probes arriving every two hours; newsletters and receipts still chasing addresses that stopped being printed anywhere long ago; steady dictionary spray against role names; the occasional backscatter burst; and, every so often, a genuinely mistyped message from a real person that would have bounced on a stricter domain. That last category is rare and worth all the rest, because each one is a conversation that survived a typo.

Turn the catch-all on, point it somewhere with a filter and a human behind it, and test the far end of any forward before you trust it. Ours has run that way since June, checked every two hours, and the silence has been the point.