Catch-All, Risky, Unknown, Accept-All: What Email Verification Statuses Actually Mean

Short answer: behind the vendor vocabulary there are only four real outcomes — the address is deliverable, it is undeliverable, the check was ambiguous, or the check did not complete. Everything else is labelling. The bucket that actually costs you money is the ambiguous one, and most of it is catch-all.

If you have ever compared two verification reports on the same list and found they disagree, this is why. This guide maps the labels to what they actually mean, what causes each one, and what to do with the contacts underneath.

The four real outcomes

Strip away the marketing and every verification result reduces to one of these:

Everything below is detail on those four rows.

Valid / deliverable

The verifier established that the mailbox exists and the receiving server will accept mail for it. This is the status you are paying for.

Two caveats worth internalising:

• Valid is a snapshot, not a guarantee. People leave jobs and mailboxes get closed. A verdict from eight months ago is a historical record, not a current fact. Re-verify before significant sends.
• Valid says nothing about engagement. A mailbox can exist, accept your mail, and be read by nobody. Verification protects deliverability; it does not manufacture interest.

Invalid / undeliverable

The address cannot receive mail. Usual causes: the mailbox does not exist, the domain has no mail servers, the domain has expired, or the syntax is malformed in a way no server will accept.

These belong on a permanent suppression list. Sending to known-invalid addresses produces hard bounces, and hard bounce rate is one of the clearest negative signals a mailbox provider watches.

One thing to insist on from any verifier: a false invalid is the most expensive error in the category. If a tool marks a real customer invalid, you suppress a live human being and never find out. That is why VeriMailX returns "risky" on genuinely ambiguous signals rather than guessing "invalid" to make a report look decisive.

Risky — the bin, not a category

"Risky" is where most confusion lives, because it is not one condition. It is a container. Depending on the vendor it may hold:

• Catch-all / accept-all domains — the domain accepts every recipient, so mailbox-level acceptance proves nothing
• Role-based addresses — `info@`, `sales@`, `admin@`, `support@`
• Low-confidence results — the check reached a conclusion, but not a firm one
• Known complainers or suppression-list matches — sometimes folded in as "do not mail"
• Full mailboxes — currently over quota, may recover

Two verifiers can both return "risky" on the same address for completely different reasons. So the first rule of working with risky: never write a suppression rule against the word "risky" alone. Always split it by the underlying reason your provider exposes. A role-based address and an unresolved catch-all need opposite treatment.

Catch-all inside the risky bucket

In most B2B lists, catch-all is the largest single contributor to risky. It is also the only part of the bucket that a tool can genuinely resolve rather than merely re-describe. If you are not clear on why catch-all defeats normal verification, What Is a Catch-All (Accept-All) Email Address? covers it end to end.

Accept-all / catch-all as an explicit status

Some providers surface accept-all as its own top-level status instead of folding it into risky. This is more honest and more useful, because it tells you exactly why the address is unresolved.

What it means precisely: the receiving domain accepts mail for every address offered to it. What it does not mean: that the address is valid, that the address is invalid, or that the domain is untrustworthy. Catch-all is commonly a sign of a well-administered domain that deliberately refuses to leak which mailboxes exist.

Treat an accept-all result as "not yet answered", not as "answered badly."

Unknown / unverifiable

Unknown means the check did not reach a conclusion. Typical causes:

• Greylisting — the receiving server defers unfamiliar senders on first contact by design
• Rate limiting — the server throttled the checking traffic
• Timeouts — the server was slow or briefly unreachable
• Defensive configurations — some servers deliberately refuse to answer verification traffic at all

The important distinction from risky: unknown is often *transient*. Re-checking an unknown a day later frequently produces a real verdict. Re-checking a catch-all produces the same catch-all forever, because nothing about the situation has changed.

A high unknown rate across an entire list usually points at the checking infrastructure rather than at your data.

Role-based, disposable and other flags

These are usually flags layered on top of a status rather than statuses themselves.

• Role-based — reaches a function, not a person. Fine for support, billing and transactional mail. Higher complaint risk for cold outreach, because whoever is on rota that day did not ask to hear from you.
• Disposable / temporary — burner domains used to get past signup gates. Almost always worth blocking at the form.
• Free provider — a consumer mailbox. Not a quality signal; relevant only if your product is strictly B2B.
• Full mailbox — over quota right now. Recheck later rather than suppressing.
• Toxic / spam trap risk — suppress immediately and do not test.

How the major verifiers label things

At a general level, the mapping between well-known vendors looks roughly like this. Always confirm against your provider's current documentation, since labels change.

The structural difference is in the third column. For most vendors, catch-all is a terminal answer — the report ends there. VeriMailX treats catch-all as a question to be resolved, and returns a definitive valid or invalid on those addresses, live, without sending an email to the recipient, using proprietary multi-signal resolution. What remains in our risky bucket is only the genuinely ambiguous residue, not every accept-all domain on the internet.

Turning statuses into rules

A workable policy, in order of confidence:

• Valid — send.
• Invalid — permanent suppression. Never retry.
• Unknown — re-check once after 24 to 48 hours. If it stays unknown, hold it out of large sends.
• Accept-all / catch-all — resolve it. Do not send blind, and do not delete it either.
• Role-based — allow for transactional and support flows, exclude from cold outreach.
• Disposable — block at capture.
• Spam trap risk — suppress, and do not test whether the flag is right.

And one rule that overrides the rest: record the status and the date on the contact record. Verification without an audit trail means every future argument about a deliverability incident becomes guesswork.

Where to go next

If your ambiguous bucket is mostly catch-all — which for B2B lists it almost certainly is — the practical playbook is in How to Verify Catch-All Emails Without Bouncing Your List.

You can also just test the labels yourself. Run an address your current tool calls "risky" through the free email checker — no signup for single checks — and compare. Plans and credit packs are on the pricing page.