What is a catch-all domain, and why can no one verify it?

Every email domain points to one or more mail servers through its MX records. When another server tries to deliver a message, the receiving server decides whether to accept it. A normal server checks the recipient: if jane@acme.com exists it accepts, and if jnae@acme.com does not, it rejects the address straight away.

A catch-all server (also called accept-all) skips that decision. It accepts mail for any local part at the domain. The message for jnae@acme.com is taken in, and then one of three things happens behind the scenes:

• It lands in a shared inbox that someone reads, or nobody reads.
• It is routed to a real person by rules the sender cannot see.
• It is quietly discarded, or bounced later as a separate message.

From the outside, all three look the same. The server said yes.

There are ordinary reasons. Small companies use catch-all so that a misspelt address still reaches someone, or so that one inbox can collect mail for sales@, billing@ and anything else people guess. Some security gateways sit in front of the real mail server and accept everything first, then filter later. That makes the domain look catch-all even if the server behind it would reject unknown users.

Others do it on purpose to make address harvesting harder. If every address looks valid, a list-builder cannot tell real people from guesses. Either way, the effect on verification is the same.

Verifiers check a mailbox by starting an SMTP conversation and asking the server whether it would accept a given recipient, without sending a message. That works because a normal server answers truthfully per address. On a catch-all domain the answer is always yes, so the question carries no information about the specific person.

A verifier detects catch-all by asking about an address that almost certainly does not exist, such as a long random string. If the server accepts that too, the domain is catch-all, and every other yes from that server is meaningless. Any tool that claims to confirm individual mailboxes on such domains is guessing, however confident the label.

Ravn is explicit about this. When validate_email sees a catch-all domain, it returns status: "risky" with reason: "catch_all_domain" and catch_all: true, never valid. The email verification API page lists every field.

Treat them as a separate bucket, not as good or bad. A sensible routine:

• Weigh the source. An address the person typed into your own sign-up form is far more likely to be real than one assembled from a name and a domain.
• Check the pattern. If the address follows the company's known pattern (for example first.last), it is more plausible. The email finder API returns the pattern and a confidence score, and marks catch-all results as risky.
• Send in small batches. Mail catch-all addresses separately, in small groups, and watch for later bounce messages and replies before sending more.
• Suppress fast. If an address bounces after acceptance, remove it at once and do not retry.
• Keep them out of cold first sends. If you are writing to people who have never heard of you, start with addresses you could actually verify.

None of this turns a catch-all address into a confirmed one. It only controls how much risk you take while you find out.

No. Plenty of real, healthy companies run catch-all mail. It is a sign that verification has reached its limit, not that the address is fake. The honest answer for any single address on that domain is "we cannot know from the outside", and the right response is to rely on other evidence and send carefully.

To check a few addresses by hand, use the free email verifier. To clean a whole list, the list verification playbook shows how to split catch-all rows out from the rest.