Email Verification Results: Valid, Invalid, Risky and Unknown

Every email verifier sorts addresses into roughly four outcomes: valid (the mail server confirmed the mailbox), invalid (rejected, no mail server, or broken syntax), risky (reachable but unconfirmable, usually catch-all) and unknown (no usable answer). The words differ by vendor. The decisions behind them do not, and that is what this guide maps.

If you have ever moved a list from one tool to another and found the columns do not line up, this is why. We read the result documentation of eight verification services on 1 October 2026 and lined their labels up against each other.

The four outcomes underneath every label

Each status is really an answer to one question: what did the recipient's mail server say, if anything? Verification works by opening an SMTP conversation with the server and asking about the mailbox at the RCPT TO step, without sending a message. We covered the mechanics in how to check an email without sending.

Outcome	What the server did	Typical cause
Valid	Accepted the address, and rejected a made-up address on the same domain	A real, working mailbox
Invalid	Rejected the address, or there was no server to ask	Typo, deleted mailbox, dead domain, bad syntax
Risky	Accepted the address, but also accepted a made-up one	Catch-all domain, full mailbox, disposable provider (vendor-dependent)
Unknown	Gave no usable answer	Timeout, greylisting, connection refused, anti-spam system

The key distinction people miss is between the last two. Risky means the verifier got an answer and the answer was meaningless. Unknown means it got no answer at all. One is a property of the domain and will not change if you check again tomorrow. The other is a failed attempt and often will.

How eight vendors name the same results

The same four outcomes appear under at least five different vocabularies. This table maps each vendor's own labels, taken from their API documentation (sources linked below the table).

Vendor	Valid	Invalid	Catch-all	Unknown	Other top-level labels
ZeroBounce	valid	invalid	catch-all	unknown	spamtrap, abuse, do_not_mail
NeverBounce	valid	invalid	catchall	unknown	disposable
Kickbox	deliverable	undeliverable	risky (with accept_all flag)	unknown	none
Bouncer	deliverable	undeliverable	risky (reason low_deliverability)	unknown	none
Hunter	valid	invalid	accept_all	unknown	webmail, disposable
Clearout	valid	invalid	catch_all	unknown	safe_to_send flag: yes / risky / no / unknown
DeBounce	5 Valid	6 Invalid	4 Accept-All	7 Unknown	1 Syntax, 2 Spam Trap, 3 Disposable, 8 Role
EmailListVerify	ok	email_disabled, dead_server, invalid_mx, invalid_syntax	ok_for_all	unknown	antispam_system, smtp_protocol, disposable, spamtrap

Sources: ZeroBounce status codes, NeverBounce single check, Kickbox's own Ruby SDK README, Bouncer terminology, Hunter API reference, Clearout overview, DeBounce result codes, and EmailListVerify's published OpenAPI spec at api.emaillistverify.com/api-doc.

Where the vendors genuinely disagree

Most labels translate one-to-one, but three categories land in different buckets depending on the tool. If you compare two verifiers' summary percentages without knowing this, you will draw the wrong conclusion.

Disposable addresses

A disposable address, such as one at Mailinator, usually has a working mailbox. Nobody will read it.

• NeverBounce, Hunter, DeBounce and EmailListVerify give it its own top-level status.
• ZeroBounce files it under do_not_mail with the sub-status disposable.
• Bouncer files it under risky, reason low_quality.
• Kickbox returns it with a disposable flag alongside the main result.

So a list cleaned in Bouncer will show a higher risky share than the same list in NeverBounce, with no difference in the underlying data. You can check any domain yourself with the disposable email checker.

Role addresses

info@, sales@ and support@ are real mailboxes, so most tools return the mailbox verdict and add a role flag. Two do not: DeBounce gives role accounts their own code (8, which it labels "Maybe, Not recommended"), and ZeroBounce moves them into do_not_mail with sub-status role_based. Whether you should send to them is a separate question, covered in should you send to info@ and sales@.

Catch-all marked as valid

This is the one to watch. ZeroBounce's valid status has a sub-status called accept_all, which its documentation describes as addresses that "belong to domains on the ZeroBounce accept_all list". That is distinct from its top-level catch-all status, which it describes as "impossible to validate without sending a real email and waiting for a bounce". If you filter on the top-level status alone, some accept-all addresses travel with your valid ones. Read the sub-status column before you import.

Hunter has a quieter version of the same issue. Its webmail status covers addresses at providers like Gmail and Outlook, and its documentation says that for webmail and disposable addresses "we provide an arbitrary score of 50". webmail tells you who hosts the mailbox, not whether it exists.

What to do with each result

Send to valid, delete invalid, hold back risky, and re-check unknown. That is the whole policy, with a few refinements.

Result	Action	Why
Valid	Send	The server confirmed the mailbox
Invalid	Delete, and suppress so it is never re-imported	It will hard bounce
Disposable	Delete from marketing lists	No human will read it
Spam trap (where flagged)	Delete	Hitting one damages sender reputation far more than a bounce
Risky / catch-all	Send separately, small batches, only if the address came from a reliable source	Unconfirmable, not necessarily bad
Unknown	Re-verify after 24 to 48 hours	Often a temporary failure such as greylisting
Role	Your decision, based on use case	Real mailbox, higher complaint risk

Two notes on that table.

Valid has a shelf life. Clearout's documentation says its "safe to send" guarantee applies only if you send "within 24 hours of the verification time", and ZeroBounce describes valid addresses as having "a very low bounce rate of under 2%". Both are the vendors' own claims, not independently audited, but they agree on the useful point: a valid result describes the mailbox on the day you checked. See how often to re-verify your list.

Catch-all needs its own policy. It is often the largest non-valid bucket on a B2B list, and deleting it outright throws away real people. We wrote a decision framework for emailing catch-all addresses.

Unknown is a retry, not a verdict

Unknown means the check failed to complete, so the right response is to run it again, not to decide. The sub-statuses vendors publish make the causes clear. ZeroBounce lists greylisted, timeout_exceeded, mail_server_did_not_respond, failed_smtp_connection and antispam_system. Bouncer lists timeout, unavailable_smtp, dns_error and unsupported. Kickbox lists no_connect, timeout and unavailable_smtp.

Most of those are temporary. A greylisting server rejects the first attempt from an unfamiliar sender with a temporary 4xx code and accepts a later one. A busy server times out once and answers the next time.

There is one cause of unknown that is the verifier's fault rather than the recipient's: the verifier's own network cannot reach port 25. We measured that on our own infrastructure in cloud providers block port 25. A verifier in that position should return unknown or risky for everything it could not check. A verifier that returns valid instead is the failure described in how to tell if your email verifier is lying.

How SimpleVerifier's three statuses map

We return three statuses rather than four, and it is worth being explicit about where things go:

• valid: the recipient's mail server confirmed the mailbox.
• invalid: the server rejected the mailbox, the syntax is wrong, the domain has no mail server, or the domain is on our list of 8,740 disposable providers.
• risky: the domain works but the mailbox could not be confirmed. That covers catch-all domains and servers that would not answer, so both "risky" and "unknown" in the vendor table above land here.

Role addresses are flagged alongside the status rather than replacing it. Anything we could not confirm is returned as risky, never as valid. Transient failures are retried rather than cached as a verdict.

Practical takeaway

When you open a results file, do three things before importing anything:

1. Translate the labels into valid / invalid / risky / unknown using the table above, so you are not comparing two vendors' categories as if they matched.
2. Read the sub-status or reason column, not just the headline status. Catch-all inside valid, and disposable inside risky, both hide there.
3. Re-run the unknowns a day later before deciding anything about them.

If you want to see how a single address resolves before running a whole file, the free single email checker shows the status and the reason.