Catch-all (accept-all) domain: what it is and why it breaks email verification

Mark AvrilovPublished June 7, 2026updated September 17, 2026

A catch-all (accept-all) domain is a domain whose mail server accepts messages for any address, including mailboxes that do not exist.

For list validation that means one thing: the server's SMTP answer tells you nothing about a particular address, so a validator gives it a status of its own instead of “valid” or “does not exist”.

What happens in the SMTP session

The sender names each recipient with the RCPT TO command. A normal server checks its mailbox list and replies 250 for a real address and 550 (User unknown) for a missing one. A catch-all server replies 250 to anything, asdfgh@domain.com and test123@domain.com alike. The message then lands in a shared inbox, gets dropped quietly, or comes back hours later as a delayed bounce.

It is a mail server setting. In Postfix a single line such as @example.com inbox@example.com in the virtual alias table does it: that form has the lowest precedence and catches every address at the domain that is not listed above it. Google Workspace does the same with a routing rule for unrecognized addresses.

Why domains are set up this way

Mostly out of fear of losing mail. A customer writes to slaes@company.com instead of sales@, or has j.smith@ in the address book when the real mailbox is john.smith@. Without catch-all the message bounces, while with it the message reaches a shared inbox and somebody deals with it.

The other reason is simplicity, since a small business funnels everything into one mailbox and makes up addresses per channel (promo@, webinar@, partner@) on the fly instead of creating them.

The downside is that spam sent to invented addresses gets in too. Explicit aliases for named people solve the same problem without it.

False positives in validation

SMTP verification relies on the RCPT TO reply: the validator asks the server about a mailbox without sending an actual message. On a catch-all domain the reply is always yes, and if you take it at face value an invented address passes as deliverable.

A real send can go either way. A live mailbox gets the message. A missing one either swallows it or, some time later, returns a delivery status notification (DSN), and your sending platform records a hard bounce.

How validators detect catch-all

You cannot confirm a specific mailbox on such a domain, but you can detect the configuration. The validator asks about a deliberately random address like a7f3k9x@domain. Accepted? Then the domain takes everything, and every address on it gets the catch-all flag.

Some cases sit in between. A few servers accept RCPT TO and reject the message only after the data is transferred. Others answer the first attempt with a temporary 451 error (greylisting). The honest move is to mark those as unknown and check again later.

uChecker gives addresses on catch-all domains a separate status, so the report shows how much of your list sits on them.

Sending to catch-all addresses

Throwing them all away is wasteful, since catch-all is common on corporate domains, which is where the contacts you want tend to be. Sending to them blindly is no better, though.

What works: move catch-all addresses into their own segment, send to it in small batches, and count bounces for that segment separately. Amazon SES gives a usable yardstick. It recommends keeping bounces below 2%, puts an account under review at 5% and may pause sending at 10%. If the segment creeps up, keep only the people who have opened or clicked.

Where the address came from matters a lot. Double opt-in means the person confirmed from that very mailbox, so the catch-all flag is not a worry. An address from a bought list or an unconfirmed form is better dropped. Two or three sends with opens and clicks will tell you more about the segment than any one-off check.