How SimpleVerifier grades catch-all addresses
A catch-all domain accepts every address, so no mailbox there can be confirmed by asking the server. We keep those rows risky and grade each one higher, medium or lower likelihood, with the reasons. In a back-test on 82,853 addresses, higher-graded addresses existed 69.0% of the time and lower-graded ones 1.4%. A grade is never a confirmation.
Measured by the SimpleVerifier Team on 24 October 2026 from results we already held. The grading opens no extra mail connection.
What you get on a catch-all row
catch_all_confidence: higher, medium or lower likelihood that the mailbox is real.catch_all_reasons: plain sentences, for example “Same first.last format as 3 confirmed addresses on this domain in this list”. Every row ends with “Still unconfirmed”.catch_all_signals: stable codes for filtering, such asmatches_confirmed_formatorname_guess_variants. They are in the CSV, the API and the MCP server.statusstaysriskyandsend_advicestayscare. Existing fields did not change.
The safe-to-send download has three choices: confirmed only (the default), confirmed plus higher-likelihood catch-alls (filter=safe_likely), or confirmed plus every catch-all except lower likelihood (filter=safe_not_lower).
How we measured it
Catch-all domains never tell us which addresses are real, so we measured on domains that do. We took the 94,877 addresses at 18,317 domains where the mail server gave a definite answer (mailbox exists or mailbox not found), leaving out catch-all domains and free providers. 15.0% of them existed; many came from lists of guessed name spellings. We kept at most 20 addresses per domain (82,853) so that no single company dominates, graded each one as if its domain were catch-all, with its own answer hidden and the other answers on the domain visible, and counted how often each grade turned out to exist.
| Grade | Addresses | Share | Existed |
|---|---|---|---|
| higher | 1,830 | 2.2% | 69.0% |
| medium | 21,279 | 25.7% | 49.7% |
| lower | 59,744 | 72.1% | 1.4% |
Signals the grade uses, each measured alone:
| Signal | Addresses | Existed | Effect |
|---|---|---|---|
| Same name format as confirmed addresses on the domain (first.last next to a confirmed first.last) | 1,830 | 69.0% | +2 |
| Same format as at least 80% of the other addresses on that domain in the list (5 or more) | 128 | 90.6% | +1 (small sample) |
| Single-word name (anna@) next to confirmed single-word addresses | 3,536 | 26.1% | +1 |
| A different name format from the domain's settled confirmed format | 406 | 4.4% | −2 |
| Two or more other spellings of the same name on the domain in the list (anna.lee, a.lee, alee...) | 59,699 | 1.4% | lower |
Limits
- The numbers come from domains that answer. We assume a person’s address format works the same way on a catch-all domain. We cannot check that without bounce data, and we hold none.
- The grade depends on the list. In the lists stored on our side, where 91.6% of answered addresses existed, the grades separated little (higher 88.7%, medium 91.8%). A list of real contacts is mostly real whatever the grade.
- Most catch-all rows carry no evidence either way and stay medium. Of 60,674 catch-all rows in our recent results, 3 were graded higher and 250 lower. Evidence appears when the same list or our recent checks hold confirmed addresses on the domain, or when a list holds guessed spellings.
- The figures are not a deliverability promise and not a per-row probability.
Signals we tested and do not use
| Signal | What we found | Decision |
|---|---|---|
| Mail host (Google Workspace, Microsoft 365, Proofpoint and other gateways) | Existed 3.3% on Google Workspace (2,396), 7.7% on Microsoft 365 (5,319), 6.7% on Proofpoint (697) and 50.2% on other hosts (2,467). That tracks which lists hold guessed addresses, not whether a mailbox is real. | Shown as context only |
| SPF and DMARC records | Existed 12.5% with both (8,439), 35.4% with SPF only (1,696), 17.4% with neither (547). Not in a useful order. | Not used |
| The exact address is published on the domain's own website | 10 of 10 such addresses existed, but only 14 of 2,161 catch-all rows (0.6%) on 350 sampled domains were published. | Too rare to build yet |
| How fast the server answers RCPT for a real versus a random address | 50 catch-all domains, 247 probes, postmaster@ (must exist) against random addresses. Google Workspace answered postmaster@ faster (median 53 ms against 82 ms), but postmaster@ is a special address there and other hosts showed noise-sized gaps. Microsoft 365 answered only the first recipient per connection. | Not used |
| Domain age | We hold no WHOIS data, so we cannot measure it. | Not used |
| Random-looking or placeholder names | Random-looking names existed 22.5% (71). mail@ and email@ existed 161 of 163 and 23 of 25, so they are no longer treated as placeholders. test@ and noreply@ stay lower because nobody reads them. | Context only, except test@/noreply@ |
We also checked again whether catch-all domains still accept random addresses. All 50 in the timing test did. A domain is only labelled catch-all after a random address we generate is accepted.
How other verifiers describe catch-alls
From their public documentation, read on 24 October 2026:
| Verifier | What the docs say | Source |
|---|---|---|
| ZeroBounce | Status catch-all. Addresses on its own accept-all list can come back valid with sub-status accept_all. A separate AI score (0 to 10) is sold for catch-alls, built from data it does not name. | docs |
| NeverBounce | Result catchall ("accept all / unverifiable"). No score on its verify reply. | docs |
| Bouncer | Status risky with reason low_deliverability and domain.acceptAll, plus a 0 to 100 score. Its docs do not explain how the score is computed. | docs |
| Hunter | Status accept_all with a score. Its docs do not say how the score is computed. | docs |
| MillionVerifier | Says it resolves part of catch-alls into valid or invalid with a proprietary method. Unresolved ones are risky. | docs |
We publish our signals, our numbers and what failed. Higher means we found evidence for the address. It does not mean confirmed, so we never call it valid.
Common questions
- Can any verifier confirm an address on a catch-all domain?
- Not by asking the mail server, because the server says yes to every address, real or made up. A verifier that marks a catch-all address valid is using some other evidence. SimpleVerifier keeps these rows risky and grades them higher, medium or lower likelihood with the reasons.
- How is the catch-all grade measured?
- On 82,853 addresses at domains that do answer (at most 20 per domain), each graded as if its domain were catch-all with its own answer hidden. Addresses graded higher existed 69.0% of the time, medium 49.7%, lower 1.4%. Results depend on the list: in lists where nearly every address is real, the grade separates little.
- Which signals did not work?
- The mail host (Google Workspace, Microsoft 365, gateways), SPF and DMARC records, and RCPT response timing did not separate real from non-existent addresses in our data, so they do not move the grade. Domain age is not used because we hold no WHOIS data.
- Should I send to catch-all addresses?
- Send higher-likelihood rows first, in small batches, and watch bounces. Drop lower-likelihood rows: most are guessed spellings of a name. The safe-to-send download lets you choose confirmed only, confirmed plus higher, or confirmed plus everything except lower.
See also: how a check works, catch-all checker, API docs.