What a catch-all domain is
A catch-all mail server is configured to accept mail for every possible recipient on its domain, whether or not the mailbox exists. Mail to a real person arrives normally. Mail to an address nobody has ever used is also accepted, and then it is forwarded to a shared inbox, filed somewhere, or silently discarded.
Companies configure this for reasonable reasons. They do not want mail lost when someone mistypes a name. They want mail to a departed employee to reach whoever took over. They run several brands on one domain and do not want to maintain the full list of valid recipients on the public server.
The side effect is that the domain stops answering the only question a verifier can ask from outside.
Why verification cannot confirm one mailbox there
Verification works by opening the conversation a sending server would open and asking the receiving server whether it will accept mail for a specific recipient. On a normal domain the answer is meaningful: accepted means the mailbox exists, rejected means it does not.
On a catch-all domain the server accepts every recipient it is asked about. Asking whether dana.ellis exists returns yes. Asking whether an address made of random characters exists also returns yes. The answer carries no information about the specific mailbox, and no amount of retrying changes that.
This is not a limitation of one tool. It is a property of the receiving server, and it applies identically to every verifier in existence. The only real difference between tools is whether they tell you.
How detection works
Detecting a catch-all is straightforward, which is why there is no excuse for reporting one as confirmed.
-
Read the domain's MX records and open the conversation with the receiving server.
-
Ask about the address you actually care about and record the answer.
-
Ask about an address that cannot plausibly exist on that domain.
-
If the server accepts that second address too, it accepts everything, and the domain is catch-all.
Some servers go further and accept every recipient during the conversation on purpose, specifically to defeat this kind of checking, then bounce the message afterwards. The observable behaviour is the same as catch-all and the honest treatment is the same.
What a catch-all row is worth
A catch-all row is not a failure and it is not a confirmation. It sits in the middle, and it deserves a decision rather than a default.
| Situation | What to do with catch-all rows |
|---|---|
| Cold outreach at volume from a normal domain | Keep them out of the main send, or hold them for a second wave |
| Cold outreach from a new or recently warmed sending domain | Leave them out entirely until the domain has history |
| A named person you have other evidence for | Send, with the other evidence carrying the risk |
| Re-engaging people who already replied to you | Send, because prior contact is stronger evidence than any check |
| A list where catch-all rows are most of the list | Fix the list, not the send. A high catch-all share usually means one large domain dominates it |
The evidence that carries a catch-all row is the finding side, not the verification side. How many independent sources agreed on the address, whether the company's naming pattern is well established, whether a colleague at the same domain is confirmed. That is why every result here includes the evidence behind it and not just a status.
The billing trap
This is where catch-all stops being a technical curiosity and starts costing money.
If a tool charges per attempt, a catch-all row costs the same as a confirmed mailbox. You pay full price for a row that nobody could verify, and you carry the bounce risk as well. If the same tool also reports catch-all as valid, its accuracy claim looks excellent while your bounce rate climbs, and the two facts are related.
The check to run on any verifier you are evaluating is simple. Give it an address on a domain you know is catch-all, and see whether it says catch-all or says valid. That one answer tells you what the vendor thinks its job is.
On this service a catch-all result does not count against your monthly limit, because we did not answer your question. The rule is described on the pricing page and it applies to every plan.
What to do about your own catch-all rows
-
Segment them out. They should be their own list, not mixed into a verified send.
-
Look at which domains produce them. Often a small number of large domains account for most of the rows.
-
Check what other evidence you have for each address, particularly the source count and the domain's naming pattern.
-
Send to the strongest of them from a domain with an established sending history, in small volumes, and watch what bounces.
-
Feed what bounces into your suppression list so those addresses never come back.
That sequence turns an unknown into a measured risk you took on purpose, which is the most anyone can do with a server that answers yes to everything.