Why Single-Engine Verifiers Fail at Catch-All Domains
In short
A verifier establishes a mailbox by offering it to the server and reading the response. On a catch-all domain the server is configured to accept every recipient, so the acceptance carries no information and a single probe has nothing left to try.
Verifier documentation tends to describe catch-all handling as a limitation, in the tone reserved for things that are nobody’s fault. It is more specific than that. There is an exact point in the SMTP exchange where the available information runs out, and understanding where it happens explains both why single-pass tools stop there and what a second pass has to do differently.
The single-probe model
Underneath the syntax and DNS checks, a verifier establishes mailbox existence one way: it begins delivering a message and stops before sending it. The server is asked to accept a recipient, its answer is recorded, and the connection closes. Nothing is transmitted.
The technique depends entirely on the server being willing to discriminate. It works because a correctly configured server knows which mailboxes it hosts and will decline the ones it does not. The verifier is not inspecting the mailbox, it is reading a decision the server made on its behalf.
The exchange against a normal server
Here is the conversation, with the client lines marked. The verifier identifies itself, states a return path, then offers the recipient it is asking about.
> HELO verifier.example
< 250 mail.company.com
> MAIL FROM: <probe@verifier.example>
< 250 2.1.0 Sender OK
> RCPT TO: <sarah.chen@company.com>
< 250 2.1.5 Recipient OK ← mailbox exists
> RSET
> RCPT TO: <qz8x2mvk4t@company.com>
< 550 5.1.1 User unknown ← mailbox does not exist
> QUITTwo recipients, two different answers. The server distinguished between them, which is exactly the information the verifier needs. Both results are trustworthy because the server demonstrated it was willing to refuse.
The same exchange against a catch-all server
Now the identical sequence against a domain configured to accept unmatched recipients.
> HELO verifier.example
< 250 mail.company.com
> MAIL FROM: <probe@verifier.example>
< 250 2.1.0 Sender OK
> RCPT TO: <sarah.chen@company.com>
< 250 2.1.5 Recipient OK ← accepted
> RSET
> RCPT TO: <qz8x2mvk4t@company.com>
< 250 2.1.5 Recipient OK ← accepted, and nobody has this address
> QUITThe second recipient is a random string that certainly belongs to no one, and it was accepted on identical terms. This is the whole problem in six lines.
Why one probe cannot settle it
The acceptance is not a lie. The server genuinely will take delivery of mail for that recipient, and what happens afterwards, whether it reaches a person, an administrator or a discard rule, is an internal matter the protocol never exposes.
What the acceptance cannot do is discriminate. A response that is returned for every possible input carries no information about any particular input. The verifier learns something real about the domain and nothing at all about the mailbox, and no amount of care in conducting the same exchange changes that, because the limitation is in what the server is prepared to reveal rather than in how the question was asked.
There is no follow-up move available within a single probe. The protocol offers no second question that separates a real recipient from an accepted one, and the command that was designed for exactly this purpose has been switched off across the internet for security reasons. A tool committed to one probe per address has genuinely exhausted its options at this point, and reporting the condition is the honest thing left to do.
What detection actually detects
It follows that catch-all detection is a statement about configuration, not about people. When a verifier reports catch-all, accept-all or unknown, the finding is: this domain accepted a recipient it had no reason to accept, therefore its acceptances are uninformative.
That is a real and useful finding, and it is routinely misread as a property of the address. Most mailboxes on a catch-all domain belong to actual people. The configuration exists to catch exceptions, misspellings and departed staff, not because the organisation is fictional. The segment is uncertain rather than bad, which is why deleting it wholesale is such an expensive response. The buyer-facing guide to catch-all domains covers what to do about that segment once you have it.
This also explains why the random-string test is decisive rather than merely suggestive. Offering a server a recipient that certainly belongs to nobody is a controlled experiment: acceptance can only mean the server does not discriminate, because there is no alternative explanation for accepting a string nobody has ever used. One probe establishes the domain’s behaviour conclusively while being unable to establish any individual mailbox at all.
Two things that make it worse
Greylisting
Some servers temporarily refuse mail from senders they do not recognise, on the theory that a legitimate sender retries and a spam run does not. The verifier gets a temporary refusal in the 4xx range rather than a verdict:
> RCPT TO: <sarah.chen@company.com>
< 451 4.7.1 Greylisted, try again in 300 secondsRecording that as undeliverable would discard a valid address, so it has to be carried as unresolved. A single-probe tool that does not return later simply never finds out, and the address joins the same unknown pile as the catch-alls for an entirely different reason.
Response behaviour that varies by asker
Mail servers are not obliged to answer consistently. Some rate-limit aggressively once a source has asked several times in succession. Some vary their response according to the reputation of the connecting infrastructure, so the same question from a different source gets a different answer. Some large providers deliberately obscure mailbox existence, on the reasonable view that answering freely assists anyone assembling a spam list. A single probe from a single source gets one sample of a system that does not behave the same way for everyone.
What a second pass does differently
If the limitation is that one probe from one vantage point cannot discriminate, the response is to stop relying on one probe from one vantage point. That is the entire idea behind a second pass, and it is why it is a separate stage rather than a longer first one.
- Waterfall routing. Approach the same mailbox by a different route, so the exchange is not a repeat of the one that produced the ambiguity. A server that behaves uniformly toward one source does not necessarily behave uniformly toward all of them.
- Provider-aware probing. Different mail platforms expose different behaviour under different conditions. Knowing which platform is answering shapes what is worth attempting rather than applying one script everywhere.
- Signal aggregation. Combine what several observations imply rather than treating any single response as the answer, and attach a confidence score so the strength of the conclusion travels with it.
None of this is free, which is why it belongs in a second stage. It is slower and costlier per address than a first pass, and it can afford to be because it runs only on the minority of a list that needs it. The two-pass model covers how the two stages divide the work.
What it recovers
On a 10,000-address B2B list, a first pass settles about 7,500 addresses and returns 2,500 as catch-all. A second pass returns a definitive verdict on roughly 72 percent of that segment, about 1,800 addresses, which is 18 percent of the whole list moving from a status to an answer.
Those addresses were never invalid. They were unfalsifiable under a method that had run out of questions to ask. If you want to watch the mechanism in action, take a domain you know accepts everything and run a real address at it through the free checker, then run a random string at the same domain. The difference between the two results is the second pass doing its work. The features page covers the pipeline, and a free account includes 100 credits to try it across a real segment.
Frequently asked questions
Could a verifier just send the message and check for a bounce?
It would answer the question and destroy the reason for asking it. Delivering to a mailbox that does not exist is exactly the event verification exists to prevent, and on a catch-all domain the server accepts first regardless, so any bounce arrives later as a delayed notification against the sending domain. The technique converts an information problem into a reputation problem.
Does the VRFY command solve this?
No. VRFY was designed to ask a server whether a mailbox exists, which is precisely what is needed here, and it has been disabled almost everywhere for decades because it hands mailbox enumeration to anyone who asks. Encountering a server with VRFY enabled today is rare enough that it cannot be the basis of a verification strategy.
Why not probe the same server several times?
Repetition does not help when the response is deterministic. A catch-all server is configured to accept every recipient, so asking ten times produces ten identical acceptances. Repeated probing from the same source also looks like enumeration and tends to attract rate limiting, which degrades the answer rather than improving it.
Is a catch-all address always risky to send to?
No, and that is the frustrating part. Most addresses on a catch-all domain belong to real people, since the configuration exists to catch the exceptions rather than because the mailboxes are fictional. The problem is that a single probe cannot tell you which ones, so the whole segment inherits the uncertainty of its worst members until something resolves it.