Domain Catch All: Route Everything Without Losing Control

You enable a domain catch all to stop missing leads when someone types saels@ instead of sales@. Makes sense. But the moment you flip that switch, your mail server stops rejecting unknown recipients and starts accepting everything — including probe messages from spammers running Directory Harvest Attacks. Backscatter. Auto-reply loops. Silent mail loss from forwarding. These aren't edge cases — they're the default outcome when you turn on a domain catch all without the architecture to support it.

Most guides stop at "enable catch all, route to inbox." That's where the problems start. This guide covers actual implementation: quarantine sinks, Postfix regex routing, loop prevention, and the forwarding trap that silently drops authenticated mail. Read the email forwarding setup guide first if you need the foundation — this article goes deeper on domain catch all specifically.

What Is a Domain Catch All?

A domain catch all is an MTA rule that accepts email sent to any address at your domain that doesn't match a known mailbox. Instead of returning 550 User Unknown, the server returns 250 OK and routes the message to a fallback destination. It modifies behavior at the SMTP envelope layer — not the header layer — and that gap is where authentication failures, backscatter, and mail loops originate.

Envelope vs. Header: Why the Protocol Gap Matters

Every domain catch all problem traces back to the distinction between two email layers defined in IETF standards. Miss this and you'll spend days debugging delivery failures that have a two-minute fix once you understand the cause.

RFC 5321 defines the SMTP envelope — the RCPT TO and MAIL FROM commands exchanged during the SMTP handshake. RFC 5322 defines the message header — the To: and From: fields your email client displays.

When you enable a domain catch all, the MTA ignores the envelope destination if it doesn't match a local user, rewrites the envelope to a fallback address, and leaves the header intact. SPF, DKIM, and DMARC authenticate the envelope path — not the header. So when you forward catch all traffic, you rewrite the envelope, and authentication breaks.

The Forwarding Failure Mode

Forwarding a domain catch all to an external provider like Gmail or Outlook.com creates a "New Hop" failure that silently drops authenticated mail:

1. Original sender: client@bank.com (IP: 1.2.3.4)
2. Your server accepts typo@yourdomain.com and forwards to you@gmail.com
3. Gmail sees a connection from your server's IP claiming to be from bank.com
4. SPF fails because your IP isn't authorized by bank.com's SPF record
5. If bank.com has DMARC p=reject, the email is silently dropped — no bounce, no error

You enabled the domain catch all to ensure delivery. The forwarding killed it. If you must forward, use SRS (Sender Rewriting Scheme) or a host that handles rewriting at the infrastructure level. TrekMail's email alias forwarding handles this so you don't have to configure SRS manually.

Three Ways a Domain Catch All Fails

Domain catch all configurations fail in three predictable ways: backscatter blacklisting, auto-reply loops, and silent mail loss from SPF/DMARC failures during forwarding. Understand all three before touching your config — fixing one while causing another is how a five-minute task turns into a week of cleanup.

1. Backscatter — Reputation Suicide

Backscatter happens when your server accepts a catch all message (250 OK), then your spam filter rejects it after the SMTP session closes. Your server generates a Non-Delivery Report (NDR) addressed to whatever was in MAIL FROM — almost always a spoofed innocent address. You're now sending spam to people who never emailed you. Your IP ends up on backscatter blocklists within days.

The fix is binary: reject invalid recipients at the SMTP edge during the connection (before 250 OK), or accept and silently quarantine. Never generate outbound NDRs for catch all traffic. Post-accept bouncing makes you the spammer.

2. The Loop of Death (Exchange Error 5.4.14)

A domain catch all routes everything to a fallback user. That user has Out of Office (OOF) enabled. A spammer sends to random@yourdomain.com. The catch all delivers it. OOF auto-replies to the spoofed sender. The reply bounces. The bounce lands at random@yourdomain.com. The domain catch all accepts it again. Exchange eventually throws 550 5.4.14 Hop count exceeded — possible mail loop.

Fix: Apply X-Auto-Response-Suppress: All to all catch all traffic without exception. This stops OOF replies, delivery receipts, and read receipts from triggering on wildcard-routed mail.

3. Directory Harvest Attacks (DHA)

When every address at your domain returns 250 OK, spammers run automated scripts blasting thousands of combinations — admin@, hr@, ceo@, invoice@ — to build verified address lists. A global domain catch all confirms every address as valid. They sell the list. You get targeted spam for years.

The solution is partial wildcards instead of a global catch all, covered in Strategy 2 below.

Strategy 1: The Quarantine Sink Architecture

If you need a domain catch all, treat all wildcard traffic as hostile by default. Don't route it to a primary inbox — build a quarantine sink. This accepts mail (satisfying the business requirement) while isolating it from daily operations (protecting your sending reputation).

Implementation logic:

1. Accept: Server accepts *@domain.com
2. Tag: Identify the recipient as unknown (not a provisioned mailbox)
3. Isolate: Route to a dedicated shared mailbox such as catchall_sink@domain.com
4. Suppress: Set Spam Confidence Level to 9, apply X-Auto-Response-Suppress: All

You review the sink weekly. Legitimate mail gets moved to the correct inbox. Everything else stays quarantined. This is the only domain catch all configuration that doesn't steadily damage your sender reputation.

Microsoft 365 / Exchange Online Transport Rule

Default M365 settings won't work here. First, set your domain to Internal Relay — this disables Directory Based Edge Blocking (DBEB), which is required for catch all to function. Then configure this Transport Rule:

Enable the Transport Rule before you switch to Internal Relay. Reverse the order and you're briefly accepting everything with no filtering in place.

Strategy 2: Partial Wildcards with Postfix PCRE

A partial wildcard lets you capture specific address patterns without opening your domain to every dictionary-attack variant. Instead of accepting anything at your domain, you define a regex that matches only the patterns you expect — and hard-rejects everything else. This blocks the majority of Directory Harvest Attacks without giving up typo coverage on addresses that matter.

In Postfix, use a PCRE (Perl Compatible Regular Expression) virtual alias map:

# /etc/postfix/virtual_pcre

# Catch any address starting with "sales-" (sales-q1, sales-webinar, etc.)
/^sales-.*@yourdomain\.com$/    sales-team@yourdomain.com

# Catch common "support" typos (suport, supprt)
/^supp?o?rt@yourdomain\.com$/   support@yourdomain.com

# No wildcard below = hard 550 reject for everything else

Activate in /etc/postfix/main.cf:

virtual_alias_maps = pcre:/etc/postfix/virtual_pcre

Then reload: postfix reload

If you need broader coverage, add conservative patterns for common addresses rather than a full domain catch all:

/^(info|contact|hello|team)@yourdomain\.com$/    info@yourdomain.com

You get typo protection where it matters, without exposing every address at your domain as valid to anyone who asks.

When a Domain Catch All Is Actually the Right Call

A domain catch all fits specific, bounded situations — not as a permanent routing strategy. Three cases where it makes sense, and one where it definitely doesn't.

Legitimate uses:

• Short-lived campaign addresses — Running promo-jan@, promo-feb@, promo-mar@ and don't want to provision each one manually
• Client onboarding — Accepting mail for addresses before formal provisioning is complete
• Legacy migration — You don't have a complete list of active addresses yet and can't risk missing mail during cutover

In all three cases, the domain catch all is temporary. Once you know which addresses are real, create the actual mailboxes and retire the catch all. If you're unsure whether you need an alias or a full mailbox, read domain email alias vs mailbox — the trade-offs matter more than most guides acknowledge.

Wrong use: Running a domain catch all because you don't want to pay $6/user/month for three aliases. That's a pricing problem. Solve the pricing problem — don't paper over it with architecture you'll regret in six months.

TrekMail: Architecture Instead of Workarounds

Most catch all setups exist because per-user pricing makes proper address management expensive. TrekMail uses pooled storage — you pay per domain, not per mailbox. That changes the math and eliminates the main financial reason to use a domain catch all as a substitute for real aliases.

On TrekMail's Starter plan ($3.50/mo), you can create the actual addresses you need instead of routing everything through a domain catch all and sorting the wreckage later. If you do need a catch all, configure it from your domain settings — then pair it with real mailboxes for addresses you actively use. Getting everything wired up from scratch? The guide to setting up email on your domain covers DNS, SPF/DKIM/DMARC, and mailbox setup in the right order.

Domain Catch All Pre-Flight Checklist

Before you enable a domain catch all, verify every item on this list. One gap is enough to cause days of cleanup:

1. SMTP-edge rejection active — Unknown addresses rejected during the SMTP connection, not after. Zero post-accept bounces.
2. Auto-reply suppression set — X-Auto-Response-Suppress: All applied to all wildcard-routed traffic. OOF loops will happen without it.
3. Quarantine sink ready — Dedicated mailbox for catch all traffic, separate from every operational inbox.
4. Spam confidence high — All domain catch all traffic defaults to junk classification. You review it deliberately, not by accident in your primary inbox.
5. SPF/DMARC verified — If forwarding anywhere, SRS is in place and the forwarding IP is listed in your SPF record.
6. PCRE map over global wildcard — Use partial wildcards if your MTA supports regex. Never expose all addresses as valid unless you have to.
7. NDR generation disabled — Silent drop beats bouncing catch all traffic to spoofed senders every time.

Conclusion

A domain catch all is a legitimate tool when it's implemented as architecture — quarantine sink, SMTP-edge rejection, loop suppression, no post-accept bouncing. Treat it as a toggle and you'll have backscatter, loops, and DMARC failures within weeks. The failure modes are predictable. The fixes are specific. Build it right or don't enable it.

If you're using a domain catch all to avoid per-user pricing, that's the real problem to solve. TrekMail's flat-rate hosting lets you create the actual mailboxes and aliases you need — so the domain catch all becomes a deliberate choice instead of a workaround. Start a free trial and configure your domain catch all the right way from day one.