A catch-all email address accepts every message sent to a domain, including mail for local parts that were never provisioned. That sounds generous until you watch what happens to a domain that has one enabled and no filtering: within weeks, the mailbox fills with probes aimed at names like info, sales, billing and thousands of random strings. The real problem is not the junk volume. It is that a catch-all gives an attacker a reliable oracle for mapping which addresses exist, which feeds every downstream spam and phishing campaign. This guide covers how directory harvesting works against a catch-all domain and the concrete server-side controls that blunt it.
Why a catch-all turns your domain into an address directory
A standard mail server replies with 550 no such user when no mailbox matches the recipient. That single response is the attacker’s signal. When a domain runs a catch-all, the catch-all rule replaces the failed address lookup branch, so every recipient the SMTP session offers gets a 250 acceptance. The attacker sends RCPT TO for jsmith, john.smith, j.smith and a thousand permutations, and the server says yes to all of them. That alone does not prove the addresses are real, but it removes the negative signal the attacker would otherwise rely on. The harvesting shifts to subtler channels: response timing and bounce behavior.
Response times leak information even when the status code does not. A real mailbox lookup hits the local user database or a directory service and returns in a few milliseconds. A catch-all fallback typically takes a different path, sometimes a database write to a shared mailbox, sometimes a queue insertion, and the delta is measurable across enough samples. Attackers average thousands of RCPT TO responses over a connection and cluster them into two populations: addresses that behave like provisioned mailboxes and addresses that behave like fallbacks. Bounces leak too. If the catch-all forwards to an external destination and that destination rejects the message, the bounce message goes back to the envelope sender, and the attacker learns which forwarded addresses were genuinely deliverable. Every one of these side channels is a directory-harvesting primitive.
The scale is what makes this dangerous. A single SMTP connection can issue thousands of RCPT TO commands before the server enforces a limit, and a botnet can run that against a domain for days. The output is a verified list of real addresses plus a large set of invented ones, all harvested from a domain that thought it was being helpful. That list gets sold, and the catch-all mailbox becomes the funnel through which every future message to those addresses arrives.
Hardening the catch-all at the SMTP layer
The first fix is architectural: make the catch-all indistinguishable from a real mailbox at the SMTP layer. Do not accept and then bounce. Do not accept and then silently drop with a different timing profile. Accept into the same delivery path a provisioned mailbox uses, with the same database lookup, the same queue insertion and the same response latency. In Postfix this means routing unmatched recipients through a transport or virtual alias map that resolves to a real local delivery, not a separate relay. read the guide offers additional context worth reviewing. In Exim it means keeping the router chain identical up to the point of final delivery. The goal is that a timing histogram of RCPT TO responses shows one population, not two. If you run Dovecot for IMAP and POP3 delivery, the catch-all mailbox should be a genuine account reachable over IMAP like any other, so its existence does not stand out in later behavior either.
The second fix is rate limiting RCPT TO per connection and per source IP. Most MTAs expose this through a policy service or built-in limits. Postfix has smtpd_client_recipient_rate_limit and smtpd_recipient_limit; Exim has smtp_ratelimit conditions in its ACLs. Set a threshold that a legitimate sender will never hit, something like 50 recipients per connection and 200 per hour per IP, then reject or tarpit beyond it. Pair this with recipient address filters that inspect the local part for obvious enumeration patterns, such as very long random strings or sequential numeric prefixes. These filters are cheap and they cut the harvest volume sharply before it reaches the catch-all. Also enforce smtpd_helo_required and reject connections that fail reverse DNS, since harvesters rarely bother with proper HELO names.
The third fix is to stop the catch-all from amplifying outbound risk. SPF, DKIM and DMARC govern outbound mail authentication only, but a catch-all that forwards to a third party can break alignment if the forwarding host rewrites the envelope. Set a strict DMARC policy with p=reject and make sure the catch-all mailbox itself sends through an authenticated path. The catch-all domain should also have a null MX record or an explicit reject policy if it never legitimately receives mail, because an open catch-all with no sending infrastructure is a magnet for backscatter and spoofing. If you need the mailbox, keep it, but lock the sending side down.
Finally, treat the catch-all as a monitoring surface rather than a convenience. Route unmatched addresses into a single mailbox collection you can query, tag messages by recipient local part, and alert when the volume of distinct local parts spikes. A sudden jump in unique recipients is the signature of an active harvest. AllMail and similar mail platforms expose these logs if you need a hosted view, but any Postfix or Exim setup can log RCPT TO values to a separate file and count uniques per hour. The catch-all differs from an alias, forwarding or disposable addresses here: those are targeted and finite, while a catch-all accepts an unbounded namespace, so it needs unbounded monitoring. Keep the catch-all setup tight by pointing DNS at the right MX host, confirming the server accepts unknown recipients only through the hardened path, and auditing the mailbox monthly for harvested names you can then block outright.
Run the catch-all only if you have a reason, and harden it before you enable it. Make the SMTP response identical to a real mailbox, rate limit RCPT TO per connection and per IP, filter enumeration patterns at the recipient stage, and alert on distinct local part volume. Those four controls turn a directory-harvesting oracle into a slow, noisy, unprofitable target, and they cost less than the cleanup after your address list circulates.