News
Somebody types anything@yourdomain.com into a script, hits send, and watches what comes back. If you run a catch-all email address, every guess lands somewhere: the billing alias nobody monitors, the old newsletter address, the support inbox you retired two years ago. That convenience is the whole point of a catch-all, and it is also the reason attackers treat your domain like a phone book they can query for free.
Here is the uncomfortable part. Address enumeration does not require a breach, a leaked database, or social engineering. It runs over plain SMTP, the same protocol your mail server speaks to every sender on the internet. A catch-all widens the surface in a specific, measurable way: instead of one valid recipient, the server accepts thousands of invented ones, and the differences in how it accepts them still carry information. Whether you set this up through the cPanel Default Address, a Namecheap catch-all built on free email forwarding, or the GoDaddy catch-all toggle, the underlying mechanic is identical. One address absorbs the unrouted mail, and the response pattern around that address tells a patient prober which mailboxes are real.
What follows is a practitioner’s walk through that mechanic. We will look at how SMTP responses leak validity even when a catch-all is active, where email forwarding setup quietly exposes which addresses exist, and what you can actually change in your email hosting panel to shrink the disclosure. No panic, no talk of abandoning catch-alls outright. Just a clear view of the trade-off so you can decide where the convenience is worth the exposure.
What a Catch-All Mailbox Does and Why It Creates an Enumeration Surface
A catch-all email address accepts every message sent to your domain, whether or not the recipient exists. Send mail to anything@yourdomain.com and it lands in one designated mailbox instead of bouncing. That behavior is convenient when you sign up for services with throwaway addresses, but it also means your domain answers “yes” to every name an attacker invents. That single design decision is what turns an ordinary domain into a directory harvest target.
How the Major Panels Implement Catch-All
In cPanel, the feature lives under Mail and is called the Default Address. When the mail server cannot match a recipient to a real mailbox, alias, or forwarder, it hands the message to the Default Address, which forwards unrouted email to a specified mailbox, a domain-level forwarder, or a discard rule. cPanel is used by Namecheap shared hosting and GoDaddy cPanel hosting, so the same screen appears in both stacks with slightly different branding.
Namecheap offers catch-all via free email forwarding on domains that use its BasicDNS, and its Private Email product has a separate catch-all toggle in the admin panel. GoDaddy provides a catch-all toggle in its email hosting panel for Workspace Email and cPanel plans alike. Google Workspace is the outlier: it requires its own catch-all rule configured in the admin console under routing settings, and it does not inherit anything from registrar-level forwarding.
One detail trips up a lot of admins: the catch-all must be set where the MX records point. If your MX records resolve to a third-party mail provider but you toggle catch-all in the registrar’s panel, nothing happens. The setting only takes effect on the server that actually receives the SMTP connection.
There is also an ordering rule worth knowing. Domain-level forwarders override the Default Address. If you create a forwarder for sales@yourdomain.com, mail to that address goes to the forwarder’s destination and never touches the catch-all. Addresses with real mailboxes behave the same way. The catch-all is strictly the fallback for everything else.
That fallback is the problem. A normal mail server rejects unknown recipients at the SMTP layer with a 550 response, which tells a sender the address does not exist. A catch-all server accepts them all with a 250. To an automated prober sending thousands of RCPT TO commands, your domain now looks like it has an infinite supply of valid addresses. Spammers may cause large amounts of spam at the default address simply because every guessed name, every typo-squatted variant, and every scraped pattern resolves to a live inbox.
The trade-off is real but lopsided. The upside is never losing mail sent to a misspelled or retired address. The downside is that you have effectively published a wildcard recipient, and attackers know that wildcard recipients are cheap to abuse. A mailbox that accepts everything cannot tell a legitimate sender from a harvester, and that is precisely the enumeration surface the rest of this article digs into.
How Attackers Read SMTP Responses to Enumerate Valid Addresses
The entire enumeration game happens in the SMTP conversation, before a single message body is transmitted. An attacker opens a TCP connection to port 25 on the MX host, sends EHLO, then MAIL FROM, and starts issuing RCPT TO commands one after another. Each response code is a data point: 250 means the server accepted the recipient, 550 or 551 means it rejected it, 450 or 451 means it deferred, and 5xx variants like 553 tell the prober the address syntax was refused. When a catch-all is active, every recipient returns 250, so the raw accept/reject signal collapses. That is the theory. In practice, the collapse is rarely complete, and the gaps are what attackers harvest.
Start with the recipient override layer. A cPanel server with a Default Address set to catch everything still routes mail through its local delivery logic first. Real mailboxes, aliases, and forwarders are resolved before unrouted mail falls through to the default. If the panel is configured to reject unknown recipients at SMTP time for some domains but not others, or if a specific domain has the catch-all disabled while a sibling domain does not, the prober sees different response codes per domain and per address. A single 550 among a sea of 250s is a confirmed mailbox. Attackers run dictionaries of tens of thousands of names precisely to find those outliers.
Timing and banner behavior leak too. A RCPT TO that resolves to a local mailbox may take measurably longer than one that falls through to a catch-all forwarder, because the server performs a disk or directory lookup before handing off. On a loaded server the difference can be tens of milliseconds, which is enough for statistical probing across repeated attempts. Some mail servers also append recipient-specific text to the greeting or to the MAIL FROM acknowledgment, and a few emit different queue IDs or enhanced status codes depending on the delivery path.
Then there is the deferral path. If a catch-all forwards to an upstream provider and that provider throttles or greylists, the MX returns 450 or 451 for the forwarded recipient while local mailboxes return 250 immediately. The attacker now knows which addresses are local and which are forwarded, which is almost as useful as knowing which are real.
Silent drops are the other common setup. A catch-all that accepts at SMTP and then discards the message looks safe from the outside, but the accept itself confirms nothing while the absence of a bounce confirms plenty. GoDaddy catch-all email covers this in more depth. Attackers send a probe, wait for a DSN, and treat non-delivery reports as a signal that the address exists but the mailbox is full or the forwarder is broken. A 550 at the RCPT stage is clean; a 250 followed by a 5.1.1 bounce three minutes later is a fingerprint.
Finally, consider the VRFY and EXPN commands. Most modern MTAs disable them or return 252, but a misconfigured cPanel or a legacy sendmail install may still answer, handing the attacker a direct lookup that bypasses the RCPT game entirely. Run an MX record lookup, connect to each host, and check what your own server says when asked. The responses your MX gives to a stranger are the same responses it gives to a harvester, and the harvester is patient.
Where Catch-All and Email Forwarding Setup Leak Signals
A catch-all is supposed to make every address look alive. In practice, the machinery around it often does the opposite. The leak rarely comes from the catch-all rule itself. It comes from everything layered on top: specific mailboxes, forwarders, autoresponders, and the way each of those behaves when a stranger knocks on the door.
Start with the override problem. In cPanel, the Default Address handles unrouted mail, but any real mailbox or forwarder on the domain takes priority. When an attacker sends to a guessed address, the catch-all answers only if nothing else claims that name. A mailbox that exists responds from its own delivery path, often with a different banner, a different queue time, or a different bounce signature than the Default Address. Compare the two responses side by side and the attacker learns which guessed addresses are real. The same logic applies at the registrar level: Namecheap catch-all via free email forwarding and the GoDaddy catch-all toggle both sit behind per-address forwarders, and those domain-level forwarders override the catch-all every time. A forwarder pointing to a Gmail inbox behaves nothing like the fallback, and that difference is the tell.
Autoresponders are the loudest signal of all. A vacation reply, an out-of-office notice, or a “thanks for subscribing” auto-reply fires only from a configured address, never from the catch-all. Send 500 probes, get 3 autoresponders, and the attacker has three confirmed live addresses plus a working format to extrapolate from. Worse, autoresponders often include the original subject line and a signature with a real name, job title, and phone number, which turns a simple existence check into a profile.
Bounce behavior leaks in the other direction. A well-configured catch-all accepts everything, so nothing bounces. But forwarding chains break that promise. When a forwarder sends mail to a destination mailbox that no longer exists, the downstream server generates a bounce, and that bounce frequently names the original recipient address in the quoted headers. The attacker never needed to guess correctly; the forwarder confirmed the address for them. Greylisting and rate limits add their own fingerprints: an address that gets deferred twice before acceptance is probably passing through a real forwarding hop, while the catch-all often accepts on the first RCPT TO.
Watch for these specific leak points when you audit a domain:
- Per-address mailboxes and forwarders that respond differently from the Default Address, including different SMTP banners, queue delays, or rejection codes.
- Active autoresponders on real addresses, which confirm existence and often disclose names, titles, and alternate contact details.
- Forwarding chains to dead downstream mailboxes, where the resulting bounce quotes the original recipient back to the sender.
- Aliases that point to a system account or pipe to a program, which may return a delivery failure the catch-all never would.
- Discard email rules that silently drop mail, producing a timeout instead of an accept and flagging the address as configured.
Each of these is defensible on its own. Together they hand an attacker a map. The fix is consistency: make every address on the domain answer the same way, whether it exists or not, and route the confirmation signals through a channel the sender cannot observe. That means auditing forwarders and autoresponders as carefully as the catch-all itself, because a catch-all only hides addresses that nothing else is willing to expose.
Hardening Catch-All Configuration to Limit Address Disclosure
The first hardening step is deciding whether the catch-all needs to exist at all. Most domains do not need one. If your mailboxes are named, documented, and handed out deliberately, a catch-all mostly collects abuse. Turning it off in the email hosting panel, whether that is a cPanel Default Address set to discard or a registrar toggle in Namecheap or GoDaddy, removes the enumeration surface entirely. Keep a written list of every address you actually use, then verify nothing legitimately depends on the wildcard. Alias addresses for signups, support queues, and old business cards are the usual surprises.
If you keep the catch-all, make the SMTP conversation boring. An attacker learns from differences: a 250 for a real mailbox, a 550 for an unknown one, a 451 for a greylisted one, and a silent drop for a blackholed one are four distinct answers. Configure the MTA so that RCPT TO returns the same response whether the recipient is a real mailbox, an alias, or the catch-all. Set the catch-all to discard, not to forward, so there is no downstream bounce that reveals the address was bogus. Verify with a manual session using something like swaks –to random-string@yourdomain.tld and compare the transcript against a known-good address. If the two dialogs differ, the leak is still open.
Rate limiting and tarpitting blunt the harvest even when responses are identical. A sender that issues hundreds of RCPT TO commands in one session is not a mail server delivering mail. Cap recipients per transaction, cap connections per IP per hour, and add a short delay after each rejected or discarded recipient. Postfix users can lean on postscreen and smtpd_client_rate_limit; Exim has similar controls through acl ratelimit. The goal is not to stop a determined attacker but to make a full dictionary sweep slow and noisy enough that you notice it in the logs.
Monitoring matters more than any single rule. Watch for spikes in RCPT TO volume from a small set of IPs, for random-looking local parts hitting the default address, and for delivery attempts to names that appear in leaked address lists. Alert on the ratio of accepted to rejected recipients per client. A sudden run of alphabetically sequential probes, aaron, abby, adam, is a directory harvest in progress. Block the source, and check whether any of those addresses later received mail, which tells you whether the sweep succeeded.
Audit the configuration on a schedule, because catch-alls get re-enabled by accident during migrations. Check the cPanel Default Address under the domain’s mail settings, confirm the registrar-level forwarder in Namecheap or GoDaddy still matches your intent, and remember that domain-level forwarders override the Default Address. If you run Google Workspace, its catch-all is a separate rule in the admin console and is not governed by the MX-level settings you just reviewed. Keep the audit in a calendar with a named owner, and log the result, including the date and the person who checked. A quarterly ten-minute review is cheap next to cleaning up after a spam flood aimed at an address you forgot existed.
If there is one thing to do this week, it is this: pull up your email hosting panel and look at the catch-all setting with fresh eyes. In cPanel, open Default Address under the Mail section and see where unrouted mail actually lands. On Namecheap, check the catch-all option inside Free Email Forwarding for each domain, and on GoDaddy, find the catch-all toggle in the email settings for the domain. Write down the current destination for every domain you own, then ask a blunt question: does this address need to accept mail for recipients that do not exist? For parked domains, brand-protection domains, and domains used only for outbound, the honest answer is usually no. Switching the catch-all to discard, or to a single monitored mailbox you check deliberately rather than a personal inbox, removes the directory surface almost entirely.
For the domains where you keep the catch-all, add a second layer before the weekend is out. Run an MX record lookup to confirm mail flows through the provider you think it does, since a leftover MX entry pointing at an old host can quietly bypass the filtering you configured. Then test from an external account: send a message to an address you know exists and one you know does not, and compare the SMTP responses and any bounce that comes back. If the two behave differently, you have a leak. Ask your host about rate limiting on inbound connections and whether they tarpit repeated RCPT TO probes. Finally, set a reminder to review the cPanel Default Address and registrar catch-all settings quarterly, because these toggles get flipped during migrations and rarely get flipped back.