The test is simple enough to run by hand. Ask the server about a local part nobody could have registered, something like q7x4zz-nobody@theirdomain.com. A normal server answers 550. A catch-all server answers 250, and the 250 you got for your real address turns out to have carried no information at all.
Roughly 28% of addresses on a typical business list sit on domains configured this way. That is not a rounding error, it is more than a quarter of your data, and how a verifier reports that quarter changes the headline accuracy figure more than the quality of its engine does.
Vendors handle it in three ways. Some report it honestly as its own state. Some fold it into a risky bucket. Some resolve it to valid, which raises the published accuracy number while making it meaningless, because the addresses where all the difficulty lives were quietly removed from the denominator.
A few services attempt resolution using other data: whether the address pattern matches known employees, whether it appears in public sources, whether similar addresses at that domain have engaged. Those are inferences, and some of them are good ones. None is a protocol answer, and a service presenting an inference as a verdict has changed what the word means.
What to do with them is a separate question from whether they can be checked. Most catch-all addresses at real companies are real. Send to them in a separate batch, keep them out of your main campaign so any bounces do not sit inside it, and let the engagement data decide.
What 2,800 unproven addresses do to one send
Say your list holds 10,000 business addresses. A careful check finds 6,200 valid, 1,000 invalid and 2,800 on catch-all domains. Some vendors fold catch-all into valid, and one of those hands you a tidy report: 9,000 good, 1,000 bad. You mail the 9,000.
Now suppose one in ten of those catch-all addresses is dead, which isn't a wild guess for data that came from a pattern tool. That's 280 hard bounces on a send of 9,000, or 3.1%. You're over the 2% line on that group alone, and your report said the list was clean.
With the honest report you'd have mailed 6,200 first, then the 2,800 as a test group. The same 280 bounces would land in a send you were watching, and your main campaign would stay clear of them.
Five questions to put to a vendor about catch-all
Ask whether they run the random-address test on every domain, or only on some. A vendor that skips it can't know which of its valid verdicts are real.
Find out what label the result gets. If it's called risky, or it's folded into a score, ask which other findings share that label. You want catch-all in a pile of its own, so you can count it.
When a vendor says it resolves catch-all addresses, press for the method and for how often it's wrong. An honest answer names the data behind the guess and gives the guess its own label.
Put the billing question plainly, since you'll pay for a lot of these on a business list. And ask to see the raw server reply on each row. With a 250 for your address and a 250 for a made-up one in front of you, nobody has to take anyone's word for it.
Related questions
Does any verifier resolve catch-all addresses?
Some attempt it using pattern data and public sources, and Clearout is the best known. Those are inferences rather than protocol answers, and they should be labeled as such.
Should I delete catch-all addresses from my list?
Usually not. Many belong to real people at companies whose IT department configured a wildcard. Mail them separately and let engagement decide.
What share of a B2B list is catch-all?
Around 28% on a typical business list. Consumer lists carry far fewer, because the large free providers do not behave this way.
Why do vendors report catch-all so differently?
Because the catch-all bucket is where an accuracy percentage is made. Excluding it from the denominator raises the published number without improving the check.