Catch-all domains explained: why 'accept all' makes verification hard

A catch-all domain, also called an accept-all domain, is a domain whose mail server accepts mail for every address, whether or not the mailbox exists. Because the server says yes to everything, a verifier cannot tell a real mailbox from an invented one, so addresses at these domains are marked risky rather than deliverable. They can still be mailed, but they need to be handled with more care.

What a catch-all domain actually is

Normally a mail server checks the recipient during the SMTP conversation. When we send RCPT TO for a mailbox that does not exist, a well-behaved server answers 550 5.1.1 and the question is settled. See how SMTP verification works for the full exchange.

A catch-all server skips that check. It returns 250 for any local part at the domain, accepts the message, and decides later what to do with it: deliver it to a shared mailbox, forward it to an admin, or silently discard it. From the outside, every address at the domain looks deliverable.

Why companies configure it

Catch-all is rarely an accident. Organisations choose it for reasons that make sense from the inside:

• Never missing mail. A customer who writes to sale@ instead of sales@ or misspells an employee's name still gets through. For a small company the cost of a few junk messages is lower than the cost of a lost enquiry.
• Staff turnover. When someone leaves, their old address keeps working and lands with a manager rather than bouncing in front of a client.
• Legacy and migrations. Domains that have been through several mail systems often have forwarding rules nobody dares remove, and a catch-all is the simplest way to keep everything arriving.
• Anti-enumeration. Some administrators deliberately accept everything so that attackers cannot discover which addresses are real by probing the server.

The last one is worth remembering. Catch-all is sometimes a security setting, not laziness, and the domains that use it include large, legitimate businesses.

How we detect it

Detection is simple in principle. After we check the real address, we send a second RCPT TO with a random local part that could not possibly exist, something like a long string of letters and digits. If the server accepts that address too, it is accepting everything, and the earlier 250 for the real address meant nothing.

We run this probe on every domain we verify and cache the result for a short period, so a list of 5,000 contacts at the same company does not trigger 5,000 probes. You can test any domain yourself with the catch-all checker, and the MX lookup will show you which mail servers answered.

Two details matter in practice. First, the probe has to be sent in the same session or shortly afterwards, because some servers behave differently once they have seen a bad address. Second, some servers accept everything at the SMTP stage and bounce later from the mailbox system. That still counts as catch-all for verification purposes, and it is exactly the case that creates surprise bounces.

Why the result is "risky", not "deliverable"

People sometimes ask us to mark catch-all addresses as deliverable, since the server said 250. We do not, because the 250 was not about the address. It was about the domain.

A deliverable verdict means we confirmed a mailbox. A risky verdict means the address may well work, but we could not confirm it, and you are taking a measured risk by sending. On a typical B2B list a significant share of addresses sit at catch-all domains, and our experience is that a meaningful portion of those are old or invented. Scoring them honestly keeps your bounce rate predictable; the bounce rate calculator will show you what a bad batch of catch-alls does to the number.

The score helps here. A catch-all address with clean syntax, a corporate domain with proper SPF and DMARC, and a local part that follows the company's naming pattern will score higher than a catch-all address on a parked domain with no web presence.

How to treat catch-all addresses in a campaign

Risky does not mean never. It means segment and watch.

1. Separate them. Export the risky segment from your verification results and keep it apart from the confirmed list. Do not blend the two and hope.
2. Prefer the engaged ones. If an address has opened or clicked in the last few months, you already have proof that a human is behind it. Keep those.
3. Send in small batches first. Mail a few hundred catch-all addresses at a time, watch the bounce and complaint figures, and stop if the hard bounces climb. A bounce rate near 2% is where providers start throttling, so do not let one segment push you over the line.
4. Warm the sending domain. If the catch-all segment is large, spread it over several days rather than sending it in one go on top of your normal volume.
5. Let the data decide. After one or two sends, addresses that bounced are gone, addresses that engaged move to the confirmed list, and the rest can sit in a low-frequency segment until they prove themselves or get retired.

For cold outreach the calculation is slightly different: a catch-all address at the right company may be the only route to the person you want to reach, and a single bounce is a cheap price. For a newsletter with thousands of subscribers the maths flips, and we suggest suppressing catch-alls that have never engaged.

Microsoft 365 and Outlook.com behaviour

Microsoft's platforms deserve a specific note because so many corporate domains run on them.

Microsoft 365 tenants are not catch-all by default. An administrator can enable it through an accepted domain set to internal relay with a catch-all mail flow rule, and some tenants do. More commonly the tenant rejects unknown recipients, but only after a delay, or it accepts at the edge (through a third-party filtering service in front of Exchange Online) and bounces afterwards. The second pattern looks like catch-all to a verifier and produces bounces to the sender, so we treat it as risky.

Outlook.com, Hotmail and Live addresses are consumer mailboxes and are not catch-all. They do, however, reject unfamiliar verifiers aggressively, so a verification service without good sending reputation will get a lot of unknown results from them. We maintain the infrastructure to get real answers from those servers, which is one reason our unknown rate is low.

Google Workspace domains can also be configured as catch-all, through a catch-all address routing setting in the admin console. Gmail.com itself is not catch-all.

What to do next

Run your list through bulk list cleaning and look at the catch-all segment on its own. If you send to it, do it as described above. To stop catch-all addresses piling up in the first place, real-time verification flags them at signup so you can ask for a confirmation click before they join your list. You can read more about how we score these cases on the catch-all detection page.