Catch-all email

How catch-all email works

An email verifier checks an address by asking the domain's mail server about it, without sending a message. In SMTP, the sender names each recipient with a RCPT TO command and reads the server's reply 1. RFC 5321 defines the replies 1. An accepted recipient gets 250 OK 1. A recipient the server knows is undeliverable gets a 550 reply, often with text such as no such user 1.

A catch-all server breaks that test. Administrators set one up so that mail sent to incorrect or non-existent addresses at their domain still arrives in one mailbox instead of being lost 2. The server therefore accepts every address at the domain at the SMTP handshake, real or invented, so the replies for a real employee and for a random string look the same 3. The reply carries no signal about the person.

Some servers weaken the test in a different way. RFC 5321 notes that some servers do not verify recipients until after the message text is received 1. A verifier that stops before the message text never sees their rejection.

A verifier that meets a catch-all domain has to report uncertainty. RichAPI Email verifier returns a status label for catch-all domains next to three flags, valid, disposable and mxFound, where mxFound shows whether the domain has a mail exchanger at all 3. The reference advises branching on status rather than on valid alone 3.

Catch-all handling is part of email verification, and it sits next to the other verification statuses. You may also see the same setup called an accept-all domain.

Why catch-all email matters for outbound

Catch-all domains create a group of addresses that are neither proven good nor proven bad. You can send to them and accept some bounces, drop them and lose real prospects, or treat them as their own segment.

Dropping every catch-all row can remove real people, because a catch-all domain may still hold a working mailbox for each person you want to reach. Sending to all of them at full volume has a different cost. On a catch-all domain, a message to an invented name lands in a shared mailbox, such as the info mailbox in Google's example, and not with the person you meant 2. Some servers also accept at the handshake and reject the message only after its text arrives 1. Those rejections show up in your bounce rate.

The middle path is a separate track. The RichAPI verifier reference recommends sending catch-alls from a warmer sending domain with a tighter volume cap, rather than treating them as either safe or dead 3. The RichAPI catch-all handling playbook gives two other branches, trying a personal address or dropping the row. A matching email format at the company raises confidence in an address, though it does not prove the mailbox exists.

Example of catch-all email

Google Workspace documents how an administrator sets up a catch-all 2. The admin first picks the mailbox that will receive the mail, which can be an existing user account, a new user account or a Google Group 2. Then, in the Admin console under Gmail routing, the admin adds a setting for inbound messages, changes the envelope recipient to the catch-all address, and applies it to all inactive and unrecognized accounts 2. Google's own example routes mail for help and support addresses at a sample company domain into one info mailbox 2.

Seen from outside, mail to any unknown name at that domain is accepted and delivered to the chosen mailbox. A verifier that asks about a made-up name gets the same acceptance as for a real employee 3.

The RichAPI Email verifier reference sets out how to use a result from such a domain 3. First drop rows where mxFound is false, because that domain cannot receive mail. Then drop disposable addresses if you are doing B2B 3. Then route on status, and keep catch-all rows on their own track 3.

The billing follows the same logic. A verifier call that returns a verdict costs 2 credits, and the catalog counts a catch-all verdict as a delivered result that bills normally 4. Only a call where no source reached any verdict costs zero 4.

Catch-all vs no verdict

Both outcomes mean the verifier could not confirm the mailbox, for different reasons. A catch-all result means the server answered and accepted everything. No verdict means the sources ran and none could reach a conclusion. At RichAPI they also bill differently 4. The next step differs too. A catch-all row has a domain that accepts mail, so the open question is whether a person reads that address. A row with no verdict has no evidence either way, so you can retry later or look for another address for the same person. Keeping the two in one bucket hides that difference and mixes two costs in one report.