If you run mail in production, a catch‑all mailbox looks like a tidy safety net: no email gets lost, nothing bounces, everyone’s happy.
Then your domain reputation tanks, real customer mail starts going to junk, and your helpdesk gets buried under “delivery failed” mysteries that aren’t actually failures.
Catch‑all is the email equivalent of telling your front desk to accept every package for “Any Name” and stack it in the lobby.
You’ll feel very helpful right up until the fire marshal arrives.
What a catch‑all mailbox really does
A catch‑all mailbox (sometimes “accept-all” or “default address”) is a mail routing rule that accepts messages for any recipient at your domain
— including recipients that don’t exist — and delivers them to a mailbox (or pipe) you control.
In practical terms, your SMTP server stops saying “550 5.1.1 user unknown” and starts saying “250 ok” for almost everything.
That changes the way the rest of the email ecosystem treats you.
Why teams enable catch‑all (the usual reasons)
- Fear of missing mail: “What if a customer types saless@domain.com instead of sales@domain.com?”
- Migration band-aid: old aliases, old departments, old app addresses.
- Legacy habit: someone set it up ten years ago and nobody wants to touch mail.
- “Deliverability” misunderstanding: they think fewer bounces equals higher reputation.
What catch‑all actually buys you
It buys you more accepted mail. Not more valuable mail.
It also buys you some very specific operational liabilities: spam amplification, silent policy failures, and a reputation profile that looks like a spam-friendly domain.
Why catch‑all ruins deliverability (mechanisms, not vibes)
1) You become a spam magnet, by design
Spammers don’t need to guess addresses when a domain accepts everything. They can spray random recipients at your domain and you’ll take it.
Once they learn (by testing) that your domain is accept-all, you get placed into a “high acceptance” bucket in their tooling.
It’s not personal; it’s economics.
Your inbound volume climbs. More importantly, your bad volume climbs: invalid recipients, bot-generated addresses, dictionary attacks, and forged sender domains.
This does not stay “inbound-only.” It affects your domain’s reputation in ways that show up later when you send mail out.
2) You break an important feedback loop: recipient validation
SMTP is supposed to be a filtering moment. If the user doesn’t exist, the correct thing is to reject at RCPT TO with a 5xx.
Catch‑all removes that. You accept the message, generate storage load, and then you’re stuck dealing with it downstream.
That downstream handling often becomes “mark as spam” or “delete.” That’s fine for your inbox, but it means you didn’t reject at the protocol layer
— the sender got a 250 OK and considers delivery successful.
3) You create “phantom deliverability”: fewer bounces, worse reputation
A common executive misunderstanding: “Bounces are bad, so let’s avoid them.” No.
Unnecessary bounces are bad. Accurate bounces are hygiene.
When you accept mail to nonexistent recipients, senders don’t learn their list is dirty. They keep sending.
Eventually, their system flags you as an address sink. Meanwhile your inbound filtering works harder, your users complain, and your mail stack looks noisy.
4) You make backscatter more likely (and annoy other mail operators)
Backscatter is when your system accepts an email and later generates a bounce to the (forged) MAIL FROM address.
If you accept spam to random recipients and then later decide you “can’t deliver it,” you may generate non-delivery reports to innocent third parties.
Many modern MTAs try to avoid this, but catch‑all configurations frequently come paired with sloppy routing rules and vacation/auto-reply behaviors.
Backscatter complaints can get your IP or domain reputation hammered.
5) You muddy your DMARC/SPF/DKIM enforcement story
DMARC is not just a checkbox. It’s a policy plus reporting channel that tells you who is spoofing you and how receivers treat your mail.
Catch‑all causes a lot of inbound junk to “successfully deliver” internally, which encourages bad workflows:
forwarding suspicious mail, auto-responding, or accidentally interacting with spoofing attempts.
You also lose clean signal in your DMARC aggregate reports because your inbound spam volume increases and your team starts ignoring the data.
Operationally: the dashboard turns into wallpaper.
6) Storage and reliability take a hit (yes, really)
Mail is storage. Mail is also unbounded user input.
A catch‑all mailbox is a classic path to:
- Mailbox quota overruns (then everything bounces, including legitimate mail).
- Indexing/search blowups (IMAP servers don’t love millions of messages in one folder).
- Backup growth and restore pain (that one mailbox becomes your worst dataset).
- Incident response confusion (“why is this mailbox 200GB?”).
Joke #1: A catch‑all inbox is like /dev/null, except it’s billable and occasionally sends angry replies.
7) You increase the chance of accidental data leakage
Misaddressed email sometimes contains invoices, contracts, credentials, or personal data.
With catch‑all, you silently accept mail intended for other organizations too — typo-squatted domains and all.
You just became a data sink for someone else’s mistakes.
8) You destroy the ability to make tight policy decisions
When everything routes to one place, everything looks the same. That ruins your ability to:
- Differentiate transactional vs human mail
- Set per-alias rate limits and filtering rules
- Implement mailbox-specific retention policies
- Apply least privilege (who can read what)
The catch‑all mailbox is an anti-pattern because it’s a single bucket for heterogeneous risk.
In reliability terms: you collapsed multiple failure domains into one.
Interesting facts & historical context
Email didn’t start life as a hardened global identity system. It grew into one. Catch‑all made more sense when everything was smaller, friendlier, and on the honor system.
Here are some short facts that explain how we got stuck with it:
- Early SMTP (1980s) assumed cooperative networks. Recipient verification was not a hostile battlefield problem; now it is.
- VRFY/EXPN commands once helped confirm recipients. They’re widely disabled today because they enable directory harvesting.
- “Accept then filter” was historically common because disk was cheaper than engineering time. Today, reputation is the expensive part.
- Spam exploded in the 1990s, and “dictionary attacks” (trying common names) became routine; catch‑all is basically permission for that attack.
- SPF showed up to limit spoofing by authorizing sending IPs, but it’s fragile with forwarding, so people leaned on DKIM/DMARC later.
- DKIM made content-level authentication practical, but didn’t solve “is this recipient real?” Catch‑all still breaks that signal.
- DMARC introduced alignment and policy, and reports. Those reports are valuable only when you don’t drown in junk.
- Modern mailbox providers score domains and IPs using engagement and complaint signals; accepting lots of junk increases the odds of bad interactions.
- Plus-addressing (user+tag@domain) became popular as a safe alternative for “unknown addresses” without accepting literally everything.
Fast diagnosis playbook
When deliverability or inbound spam gets ugly and catch‑all is in the picture, don’t start by debating philosophy. Triage like an operator.
Check the bottleneck first: protocol behavior, reputation indicators, and storage health.
First: confirm you are actually accepting unknown recipients
- Use SMTP tests against your MX: does it accept RCPT TO for a random user?
- Check MTA config for default transports, recipient maps, or “luser_relay”.
Second: quantify the damage (volume, sources, and failure modes)
- Log sample: how many distinct nonexistent recipients per hour?
- Top connecting IPs/ASNs, top HELO names, top envelope senders.
- Queue growth and bounce patterns (temporary failures vs permanent).
Third: check whether “catch‑all” is hiding a separate problem
- Mailbox quota full? IMAP timeouts? Storage latency?
- Misconfigured alias/forward rules causing loops?
- Outbound mail now landing in spam because your domain looks messy?
Fourth: decide on containment
- Immediate: reject unknown recipients at SMTP time.
- Short-term: add explicit aliases for known typos/business-critical addresses.
- Medium-term: implement structured inbound handling and security review for misaddressed mail.
Practical tasks: commands, outputs, and decisions
Below are concrete tasks you can run on a typical Linux MTA stack (Postfix examples, with some Exim/Dovecot/common tools sprinkled in).
Each task includes a command, what the output means, and the decision you make from it.
Task 1: Prove catch‑all behavior with a direct SMTP session
cr0x@server:~$ nc -v mx1.example.net 25
Connection to mx1.example.net 25 port [tcp/smtp] succeeded!
220 mx1.example.net ESMTP Postfix
ehlo testhost
250-mx1.example.net
250 PIPELINING
mail from:<probe@outside.test>
250 2.1.0 Ok
rcpt to:<this-user-should-not-exist-9f3a@example.net>
250 2.1.5 Ok
quit
221 2.0.0 Bye
Meaning: If you get “250 2.1.5 Ok” for a clearly random recipient, you are accepting unknown recipients (catch‑all or equivalent).
Decision: If this is not explicitly required for a controlled workflow, disable it. If it is required, put it behind a gate (rate limits, separate MX, or verified recipients list).
Task 2: Check Postfix for the classic catch‑all setting (luser_relay)
cr0x@server:~$ postconf -n | egrep 'luser_relay|local_recipient_maps|virtual_alias_maps|virtual_mailbox_maps|recipient_delimiter'
luser_relay = catchall
local_recipient_maps =
recipient_delimiter = +
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
Meaning: luser_relay routes unknown local recipients to a local address. An empty local_recipient_maps can also mean “accept anything.”
Decision: Remove luser_relay and restore recipient validation via local_recipient_maps or proper virtual mailbox maps.
Task 3: Confirm whether Postfix is validating recipients at RCPT time
cr0x@server:~$ postconf -n | egrep 'smtpd_recipient_restrictions|smtpd_relay_restrictions|smtpd_delay_reject'
smtpd_delay_reject = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
Meaning: Nothing here rejects unknown recipients. That’s not automatically wrong, but it’s a common gap.
Decision: Add a recipient validation mechanism (e.g., correct local_recipient_maps / virtual_mailbox_maps and reject_unlisted_recipient where appropriate).
Task 4: Find “accept-all” patterns in logs (nonexistent recipients)
cr0x@server:~$ sudo grep -R "to=<.*@example.net>" /var/log/mail.log | tail -n 5
Jan 4 09:14:31 mx1 postfix/qmgr[1123]: 9A2B13C4D: to=<xyqzqj@example.net>, relay=local, delay=0.2, status=sent (delivered to mailbox)
Jan 4 09:14:32 mx1 postfix/qmgr[1123]: 7D1E22F8A: to=<billingg@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Jan 4 09:14:33 mx1 postfix/qmgr[1123]: 1F3D9C0AA: to=<hr-dept@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Jan 4 09:14:35 mx1 postfix/qmgr[1123]: 4C0D22B19: to=<asdkjhasd@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Jan 4 09:14:36 mx1 postfix/qmgr[1123]: 55B9CC1E0: to=<customer.service@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Meaning: Random-looking recipients being “delivered to mailbox” is a strong indicator that recipient validation is not happening.
Decision: If more than a trivial fraction of recipients are garbage, disable catch‑all and add explicit aliases for legit variants.
Task 5: Identify top recipient names (to spot dictionary attacks)
cr0x@server:~$ sudo awk -F'to=<' '/postfix\/(qmgr|local)/ {for (i=1;i<=NF;i++) if ($i ~ /^to=</) {gsub(/^to=<|>,.*/,"",$i); print $i}}' /var/log/mail.log | \
cut -d@ -f1 | sort | uniq -c | sort -nr | head -n 10
418 info
377 admin
265 support
201 sales
188 contact
173 test
166 hr
144 billing
121 webmaster
110 noreply
Meaning: These are the most targeted local parts. “admin/info/support” being high is classic dictionary spam behavior.
Decision: Ensure those high-value aliases exist and route to monitored queues, but reject unknown recipients beyond your known list.
Task 6: Check queue depth (symptom of catch‑all + spam flood)
cr0x@server:~$ mailq | tail -n 3
-- 1245 Kbytes in 812 Requests.
Meaning: A growing queue suggests downstream bottlenecks (delivery, content scanning, disk I/O) or upstream abuse.
Decision: If queue grows during spam bursts and recipients are random, prioritize recipient rejection at SMTP time to stop feeding the queue.
Task 7: Verify whether you’re generating backscatter (outbound bounces)
cr0x@server:~$ sudo grep -E "status=bounced|mailer-daemon|postmaster" /var/log/mail.log | tail -n 8
Jan 4 09:22:18 mx1 postfix/bounce[2219]: 6A1F2C9D3: sender non-delivery notification: 1B3C0D9AA
Jan 4 09:22:18 mx1 postfix/qmgr[1123]: 1B3C0D9AA: from=<>, size=3120, nrcpt=1 (queue active)
Jan 4 09:22:19 mx1 postfix/smtp[2281]: 1B3C0D9AA: to=<innocent@victim.tld>, relay=mx.victim.tld[203.0.113.8]:25, delay=1.2, status=sent (250 OK)
Meaning: Your server is sending non-delivery notifications to third parties. If the original MAIL FROM was forged (very common in spam), this is backscatter.
Decision: Stop accepting mail you can’t deliver. Reject at SMTP time for invalid recipients and consider disabling out-of-band bounces for content policy failures.
Task 8: Inspect mailbox size and message counts (storage reality check)
cr0x@server:~$ sudo doveadm mailbox status -u catchall@example.net messages vsize INBOX
messages=284112
vsize=19748377291
Meaning: ~284k messages and ~19.7GB in a single inbox is where IMAP performance starts paying rent in incidents.
Decision: If you must keep a sink mailbox, rotate it (daily folders), enforce retention, and keep it out of user-facing IMAP. Prefer rejection instead.
Task 9: Check filesystem capacity and inode pressure
cr0x@server:~$ df -h /var/vmail
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 500G 456G 19G 97% /var/vmail
Meaning: At 97% used, you are one burst away from mail delivery failures. Catch‑all makes bursts normal.
Decision: Contain by rejecting unknown recipients and pruning catch‑all storage. Then fix capacity (expand, move, or enforce quotas/retention).
Task 10: Look for alias loops and misroutes (catch‑all can create them)
cr0x@server:~$ sudo postmap -q catchall /etc/aliases
catchall@example.net
Meaning: Here, catchall resolves to an address at the same domain. That’s not automatically a loop, but it’s a common foot-gun if combined with virtual alias rules.
Decision: Ensure the sink mailbox is a concrete mailbox map entry, not another alias that can bounce around. Better: eliminate it.
Task 11: Validate your virtual mailbox map behavior (Postfix)
cr0x@server:~$ sudo postmap -q realuser@example.net /etc/postfix/vmailbox
realuser@example.net example.net/realuser/
Meaning: This recipient exists as a mailbox destination.
Decision: Confirm that unknown users return empty results, and configure Postfix to reject unlisted recipients rather than routing them to a sink.
Task 12: Test unknown recipient rejection after configuration changes
cr0x@server:~$ nc -v mx1.example.net 25
Connection to mx1.example.net 25 port [tcp/smtp] succeeded!
220 mx1.example.net ESMTP Postfix
ehlo testhost
250-mx1.example.net
250 PIPELINING
mail from:<probe@outside.test>
250 2.1.0 Ok
rcpt to:<this-user-should-not-exist-9f3a@example.net>
550 5.1.1 <this-user-should-not-exist-9f3a@example.net>: Recipient address rejected: User unknown in local recipient table
quit
221 2.0.0 Bye
Meaning: This is the behavior you want. Reject at RCPT time with a clear 550.
Decision: Keep it. Then add explicit aliases for business-critical addresses that used to be “caught” by catch‑all.
Task 13: Confirm DKIM signing is applied to outbound mail (because you’re about to tighten policies)
cr0x@server:~$ sudo grep -R "DKIM-Signature" -n /var/log/mail.log | tail -n 3
Jan 4 09:40:01 mx1 opendkim[901]: 3F2AB19C0: DKIM-Signature field added (s=mail, d=example.net)
Jan 4 09:40:05 mx1 opendkim[901]: 8C1DA22A1: DKIM-Signature field added (s=mail, d=example.net)
Jan 4 09:40:07 mx1 opendkim[901]: 7A0BC11E2: DKIM-Signature field added (s=mail, d=example.net)
Meaning: Outbound mail is being DKIM-signed for your domain. Tightening recipient policy won’t fix outbound authentication, but it removes chaos from the system.
Decision: If DKIM signing isn’t present, fix that before you crank up DMARC enforcement, otherwise you’ll create your own deliverability incident.
Task 14: Check DMARC policy for your domain (quick DNS sanity)
cr0x@server:~$ dig +short TXT _dmarc.example.net
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.net; ruf=mailto:dmarc-forensic@example.net; fo=1"
Meaning: Policy is p=none (monitoring only). That’s common, but it means receivers are not asked to quarantine/reject spoofed mail.
Decision: Keep monitoring while you fix catch‑all. Once stable, move to p=quarantine then p=reject with a staged rollout.
Task 15: Detect mailbox quota enforcement (or lack of it)
cr0x@server:~$ sudo doveadm quota get -u catchall@example.net
Quota name=User quota Type=STORAGE Value=0 Limit=0
Quota name=User quota Type=MESSAGE Value=0 Limit=0
Meaning: No quota limits. A catch‑all mailbox without quotas is a slow-motion incident.
Decision: If you temporarily keep a sink mailbox, set hard quotas and alerting. But treat this as a transition state, not the destination.
Task 16: Rate-limit abusive senders at the edge (mitigation while you remove catch‑all)
cr0x@server:~$ sudo postconf -n | egrep 'smtpd_client_message_rate_limit|smtpd_client_connection_rate_limit'
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 60
Meaning: Basic rate limits are configured. If they’re absent, you’re relying on hope and CPU.
Decision: Add rate limits as a temporary shield. Permanent fix remains: stop accepting unknown recipients.
Three corporate mini-stories (all too real)
Mini-story 1: The incident caused by a wrong assumption
A mid-sized B2B company migrated from a hosted email provider to self-managed Postfix + Dovecot because “it’s just email.”
During the cutover, someone enabled catch‑all on the domain to avoid losing messages for decommissioned inboxes.
The assumption was simple: accept everything now, clean up later.
Two weeks later, Sales complained that prospects were “ghosting.” They weren’t. The outbound sequences were landing in spam at several big recipients.
Meanwhile, the inbound catch‑all mailbox was receiving a steady drip of spam and misaddressed mail… plus thousands of RCPT probes per day.
Nobody noticed because it was technically “working”: mail was being accepted and delivered somewhere.
The SRE on-call found the catch‑all inbox at tens of gigabytes and the IMAP service intermittently timing out during peak hours.
Support tickets showed missing legitimate inbound messages—actually they weren’t missing; they were buried under garbage and slow indexing.
The mail stack was healthy enough to not page, unhealthy enough to cost revenue.
Fixing it wasn’t glamorous. They removed catch‑all, added explicit aliases for the top mistyped addresses, and rejected unknown recipients at SMTP time.
The spam volume dropped immediately. IMAP stabilized. Deliverability improved over the next few weeks as their domain stopped behaving like an acceptance sink.
Lesson: “We’ll clean it up later” is not a plan when the internet is allowed to write into your storage.
Mini-story 2: The optimization that backfired
A global services firm wanted to reduce helpdesk workload from bounced messages during a reorg.
They had dozens of old department addresses that people still used. Instead of maintaining an alias map, someone proposed a “smart simplification”:
turn on catch‑all and use filters to route mail based on keywords.
It looked clever. It also changed their risk profile overnight.
Suddenly every random recipient string was accepted. Spam filters got hammered. The mail gateway CPU climbed.
The catch‑all mailbox became a dumping ground, and—here’s the part that hurt—keyword routing created false positives.
Legitimate invoices ended up in a general mailbox because they contained words matching an internal rule.
A few vendor messages were delayed because automated sorting caused contention and retries.
And because the system didn’t bounce unknown recipients, external senders didn’t correct addresses; the problem never naturally decayed.
They rolled it back and did the boring thing: maintain a proper alias map, keep a short-lived redirect list, and reject unknown recipients.
The “optimization” had reduced one form of noise (bounces) by creating a larger and more expensive form of noise (misdelivery and processing load).
Mini-story 3: The boring but correct practice that saved the day
A SaaS company ran email for several brands under one infrastructure.
They had a hard rule: no catch‑alls on primary domains. Any exceptions required a written justification and a time-bound expiry.
The justification usually failed because “we might miss something” isn’t an engineering requirement; it’s anxiety.
Instead, they used structured aliasing:
transactional mail used dedicated subdomains, human mail used role accounts with explicit aliases, and any “legacy” address got a temporary alias with an expiration date.
They also had recipient validation integrated with their directory—if the user didn’t exist, RCPT was rejected.
One day, a targeted spam campaign hit them: massive RCPT probing for admin/info/support variants.
Their gateways stayed calm. Unknown recipients were rejected immediately. Spam volume still existed, but it couldn’t expand into unbounded mailbox growth.
More importantly, their monitoring was clean: rejections were visible as rejections, not as “delivered to a mailbox nobody reads.”
The post-incident review was almost boring. That’s the compliment.
Their “correct but unexciting” policy prevented a bad day from turning into a quarter-long deliverability slump.
Safer alternatives: keep mail reliable without the catch‑all
Principle: reject unknown recipients, then make the known ones easy
You don’t need catch‑all to avoid losing legitimate email. You need three things:
(1) explicit aliases for what you actually want,
(2) safe handling for misaddressed messages,
(3) visibility into what people tried to send.
Alternative 1: Explicit alias maps (with ownership)
Maintain a controlled list of accepted role addresses: support@, sales@, billing@, security@, etc.
Add known typos (billingg@) if they’re truly high value, but treat them as temporary.
Ownership matters. Every alias should have an owner team and an SLA expectation, even if the SLA is “best effort.”
Alternative 2: Plus-addressing for users and systems
If you need flexibility (tracking, per-service addresses), use plus-addressing:
user+tag@example.net. You can accept infinite tags without accepting infinite recipients.
This gives you the “never lose mail” vibe for legitimate addresses while still rejecting random recipients.
Alternative 3: A controlled sink on a separate subdomain
If your business truly needs to accept misaddressed mail during a migration, do it on a dedicated subdomain:
legacy.example.net or oldmail.example.net.
- Separate MX and separate reputation boundary (as much as practical).
- Hard retention (e.g., 7–14 days).
- Strict access control and auditing.
- Rate limits and heavy filtering.
Keep the blast radius contained.
Alternative 4: SMTP recipient verification via directory integration
If you have a real user directory (LDAP/AD) or a source-of-truth database, integrate recipient validation.
For virtual domains, the authoritative source is your virtual_mailbox_maps or equivalent.
This is where operational hygiene shows up: automated provisioning/deprovisioning, no stale accounts, no zombie aliases.
Alternative 5: Use a ticketing system ingestion address (not a catch‑all)
Many teams enable catch‑all because they want “anything@domain goes to Support.”
Don’t do that. Set up a small set of intake addresses (support@, help@, billing@) and route them into a ticketing system.
For everything else: reject.
Alternative 6: “Unknown recipient” monitoring without accepting the mail
A legitimate worry is: “How will we know what people are trying to send?”
Answer: log and sample rejections.
Aggregate RCPT TO rejection counts and top recipient strings. You get intelligence without storing the payload.
The payload is untrusted input; you don’t need it to fix address hygiene.
Quote requirement (paraphrased idea): Werner Vogels often emphasizes that you should design for failure and automate recovery; email is no exception.
Common mistakes: symptom → root cause → fix
These are the patterns I see when catch‑all is involved. They’re not theoretical. They’re the “why is my pager screaming” list.
1) Symptom: Inbound spam volume suddenly doubles
Root cause: Your domain is detected as accept-all; spammers increase RCPT spraying.
Fix: Reject unknown recipients at RCPT time. Add rate limits. Keep explicit aliases for role accounts.
2) Symptom: Legitimate customer email “disappears”
Root cause: It’s not disappearing; it’s buried in a huge sink mailbox, or delayed by IMAP indexing / mailbox locks.
Fix: Remove catch‑all. If you must keep a sink temporarily, deliver to a non-IMAP processing pipeline with rotation and retention.
3) Symptom: Your outbound mail lands in spam more often
Root cause: Domain reputation degradation due to noisy behavior patterns, potential backscatter, and poor operational signals.
Fix: Stop accept-all, ensure DKIM is correct, publish sane DMARC policy, and stabilize inbound hygiene.
4) Symptom: Queue growth and high load during “random” periods
Root cause: Spam bursts get accepted, then pile into content scanning/AV/IMAP delivery, saturating CPU or disk.
Fix: Push rejection earlier (RCPT checks), rate-limit, and verify disk performance. Don’t store what you should reject.
5) Symptom: You receive complaints about bounce spam you “sent”
Root cause: Backscatter from accepting messages and later bouncing to forged senders.
Fix: Reject invalid recipients and content policy failures during SMTP, avoid generating NDRs to unauthenticated/forged senders.
6) Symptom: A single mailbox consumes absurd storage
Root cause: Catch‑all as unbounded sink, often with no quotas or retention.
Fix: Delete/rotate aggressively, set quotas, and remove the catch‑all route. Build a rejection monitoring pipeline instead.
7) Symptom: Security team finds sensitive third‑party data in your inbox
Root cause: Misaddressed mail from other domains (typos) got accepted quietly.
Fix: Stop accept-all. Add a process for handling misdirected mail (notify sender, delete securely, document).
8) Symptom: Internal teams rely on random addresses “because it works”
Root cause: Catch‑all creates bad internal contracts; people stop maintaining correct addresses.
Fix: Remove catch‑all and force explicit interface design: defined aliases, ownership, and change management.
Joke #2: Catch‑all is a great way to achieve “zero bounces” the same way turning off monitoring achieves “zero alerts.”
Checklists / step‑by‑step plan
Step-by-step: Removing catch‑all without breaking the business
-
Inventory what catch‑all currently catches.
Pull top recipients from logs (Task 5) and list the top 50–200 recipient local parts.
Decide which are legitimate aliases, which are typos worth saving, and which are garbage. -
Create explicit aliases for legitimate recipients.
Keep the list short and owned. Route to teams or ticketing systems, not personal inboxes by default. -
Implement recipient rejection.
Make unknown recipients fail at RCPT time (Task 12). This is the actual fix. -
Add monitoring for rejected recipients.
Alert on spikes. Sample rejected RCPT local parts. You want visibility without payload retention. -
Enforce quotas/retention on any remaining sink mailbox.
If you keep one temporarily, treat it as a hazardous waste bin. Small, sealed, and emptied on schedule. -
Communicate the change.
Tell internal teams: unknown addresses will bounce now; here are the supported addresses. This prevents “email roulette.” -
Run a migration grace period with targeted aliases.
For old addresses, create explicit redirects that expire. Put the expiration date in the ticket. -
Recheck outbound authentication.
Confirm DKIM signing and DMARC status (Tasks 13–14). Catch‑all removal often coincides with policy tightening. -
Measure results.
Track inbound spam volume, queue depth, mailbox growth, and ticket volume about missing mail.
Checklist: What “good” looks like after the change
- Random RCPT TO gets a 550 at SMTP time.
- Role addresses exist explicitly and are monitored.
- Inbound spam volume drops and stays lower.
- Queue depth correlates with real load, not random bursts.
- No backscatter patterns in logs.
- Catch‑all mailbox (if any) is small, rotated, and time-bound.
- DMARC reports are reviewed and actionable (not wallpaper).
Checklist: If you insist on keeping catch‑all (containment rules)
Sometimes the business insists. Fine. Then you treat it like a hazardous feature:
- Time-box it: expiry date, owner, and rollback plan.
- Separate it: ideally a separate subdomain and MX.
- Rate-limit aggressively: connection and message rates.
- Don’t put it on IMAP: deliver to a processing pipeline, not a human inbox.
- Retention: delete fast. You are not building an archive.
- Security review: access control, auditing, and incident handling for misdirected data.
FAQ
1) Is a catch‑all mailbox always bad?
In production on your primary domain: yes, it’s usually a net negative. The rare acceptable use is a tightly controlled, time-bound migration aid,
ideally on a separate subdomain with strict retention and rate limits.
2) Doesn’t rejecting unknown recipients help spammers enumerate valid users?
It can, but in practice spammers already try common names and role accounts. You mitigate enumeration with rate limits, tarpits, and not exposing directory commands (VRFY/EXPN).
Accept-all is worse: it guarantees acceptance and invites higher volume abuse.
3) We enabled catch‑all because customers mistype addresses. What should we do instead?
Create explicit aliases for high-value typos (billingg@, saless@) and expire them after you fix the source of the typo (website, PDFs, vendor records).
Use logs to find the real typos rather than guessing.
4) Will disabling catch‑all hurt deliverability because we’ll have more bounces?
You’ll have more accurate bounces, which is good. It forces list hygiene on senders and reduces garbage inbound volume.
The goal is not “zero bounces,” it’s “only bounce what should bounce.”
5) Is plus-addressing a security risk?
Not inherently. It can increase address surface area, but it’s still tied to a real mailbox and user.
It’s far safer than accepting any random local part because you still reject unknown users.
6) We’re on Microsoft 365 / Google Workspace. Does catch‑all still matter?
Yes. Even hosted platforms reflect the same reality: if you accept mail for nonexistent recipients, you’ll ingest more spam and create operational mess.
The platform may absorb some pain, but your users and your domain reputation still pay.
7) How do we keep visibility into misaddressed mail after we disable catch‑all?
Log RCPT rejections and aggregate the rejected local parts. You can alert on spikes and maintain a “top rejected recipients” report.
That gives you the intel without storing untrusted payloads.
8) What about a “catch‑all” that only catches certain patterns?
Pattern-based routing can be OK if it’s deterministic and narrow (e.g., user+tag), but “anything goes to support” is still a catch‑all in disguise.
If the pattern allows arbitrary recipient names, you’re back to accepting attacker-controlled input at scale.
9) We have many brand domains and need to receive everything because partners guess addresses. Any compromise?
Use role accounts and a well-advertised directory of addresses. If you must accept unknown recipients, do it on a dedicated intake subdomain with retention,
then require senders to correct the address after a short grace period. Don’t let it become permanent.
10) How quickly will deliverability recover after removing catch‑all?
Spam volume reduction is immediate. Reputation effects can take days to weeks depending on volume and how receivers score your domain/IP.
The key is consistency: stable behavior, authenticated outbound mail, and no backscatter.
Next steps
If you currently have a catch‑all on your primary domain, the practical next steps are straightforward:
- Run the SMTP test (Task 1) and confirm accept-all behavior.
- Pull top recipients from logs (Task 5) and create a short, owned alias list.
- Disable catch‑all / restore recipient validation (Tasks 2–3), then retest (Task 12).
- Contain any temporary sink mailbox with quotas and retention (Tasks 8 and 15).
- Watch queue depth, disk usage, and backscatter signs (Tasks 6, 9, 7).
Email reliability isn’t about heroics. It’s about refusing to accept nonsense, early, consistently, and with logs you can trust.
Catch‑all is the opposite of that. Remove it, and your mail system starts acting like an engineering system again.