Email verification statuses explained: valid, invalid, risky and unknown
· 4 min read · Email validation
An email verification status tells you what the recipient's mail server said about an address, compressed into one word. Valid means the mailbox exists and the domain isn't accepting everything. Invalid means it can't receive mail: bad syntax, no such domain or mailbox, or a disposable domain. Risky means it might work but sending is a gamble (catch-all domains, role addresses, full mailboxes). Unknown means the server wouldn't give a definitive answer. The reason code attached to each status tells you why, and that's what you should build rules on.
The names below are pingutil's, from the /v1/verify response. Other verifiers use similar buckets with different labels, so the actions carry over.
The four statuses at a glance
| Status | What it means | Default action |
|---|---|---|
valid |
The server accepted this address and rejected a random one on the same domain. | Send. |
invalid |
The address can't receive mail, or is disposable. | Suppress. Ask the person to fix it if they're in front of you. |
risky |
It may exist, but delivery or value is uncertain. | Keep, segment, mail with care. |
unknown |
No definitive answer from the server. | Retry later. Don't suppress. |
Each result also carries a score from 0 to 100: an estimate of how likely a message is to reach a person. valid results score 95, invalid ones score in the single digits, and risky and unknown sit in between. Use the status for decisions and the score for sorting within a bucket.
Every reason code and what to do with it
| Status | Reason | What happened | What to do |
|---|---|---|---|
| valid | mailbox_exists |
Server accepted the recipient and rejected the catch-all probe. | Send. |
| invalid | invalid_syntax |
Not a well-formed address. | Ask the user to retype it. |
| invalid | disposable_domain |
Domain is on the disposable-email list. | Block at signup; suppress on lists. |
| invalid | no_domain |
The domain doesn't exist in DNS. | Suppress. Check did_you_mean for a typo. |
| invalid | no_mx |
Domain exists but can't receive mail. | Suppress. |
| invalid | null_mx |
Domain publishes that it accepts no mail (RFC 7505). | Suppress. |
| invalid | mailbox_not_found |
Server permanently rejected this recipient. | Suppress. |
| invalid | mailbox_disabled |
Mailbox exists but is disabled or inactive. | Suppress; often a person who left the company. |
| risky | accept_all |
Server accepted a random address too (catch-all). | Keep, but don't count as verified. See catch-all domains. |
| risky | role_based |
Mailbox exists but is a shared address like info@ or sales@. |
Fine for some uses, poor for 1:1 outreach. See role-based addresses. |
| risky | mailbox_full |
Server reported the mailbox over quota. | Hold and re-check later. |
| risky | randomized_local_part |
Local part looks machine-generated. | Review at signup; low priority on lists. |
| unknown | greylisted |
Server deferred the check on purpose. | Retry in an hour or more. |
| unknown | rate_limited |
Server limited how fast it answers. | Retry later. |
| unknown | blocked |
Rejection aimed at the checking server, not the mailbox. | Retry later; treat as risky meanwhile. |
| unknown | timeout |
Server didn't answer in time. | Retry. |
| unknown | connection_failed |
Couldn't connect to the mail server. | Retry. |
| unknown | smtp_error |
Server returned an error with no recognisable meaning. | Treat as risky. |
| unknown | dns_error |
DNS lookup failed temporarily. | Retry. |
| unknown | smtp_unavailable |
Mailbox check wasn't run; DNS checks passed. | Treat as unverified; retry later. |
A few of these need more context.
Why blocked is unknown and not invalid
Some servers reject a check because of who's asking: the checking server's IP, its sender address, or a sender-verification callout. RFC 3463 has separate codes for "the mailbox doesn't exist" (X.1.1) and "the sender isn't authorised" (X.7.1). pingutil reads that difference and reports the second kind as blocked, so a rejection aimed at the checker is never recorded as a missing mailbox.
Why catch-all is risky, never valid
On a catch-all domain, every address gets the same "yes". Calling those addresses valid would inflate your verified count with guesses. It's also one reason two verifiers can disagree on the same list: one reports catch-all addresses as valid, the other as risky. Email verification accuracy explained goes into this.
Why role addresses are risky even when they exist
sales@company.com usually exists and usually delivers. It's risky for a different reason: nobody in particular owns it, so personalised outreach lands with whoever happens to triage the inbox. For a support ticket form it's fine.
Turning statuses into rules
Most teams end up with three buckets:
- Send:
valid. - Hold or segment:
riskyandunknown, reviewed by reason. Retry the unknowns once before deciding. - Suppress:
invalid.
At signup, block only on reasons you can be sure of (invalid_syntax, no_domain, no_mx, null_mx, disposable_domain) and ask the user to correct mailbox_not_found. For when to re-run checks on an existing list, see how often to clean your email list.
Every pingutil result includes status, reason, score, did_you_mean, and the individual checks behind the decision, plus mx_host and the raw smtp reply when there was one. The field reference is at /api#verify-status, and the verification demo shows the full response for any address you try.
Questions people ask
- What does accept_all mean in email verification?
- The domain's mail server accepted a made-up random address as well as the one you asked about, so it accepts everything at that stage. The real address may or may not exist, and mail to a nonexistent one would bounce later. Treat it as risky, not valid.
- Should I delete email addresses marked unknown?
- No. Unknown means the mail server wouldn't give a definitive answer, often because of greylisting, rate limiting or a temporary block. Re-check later, and if it stays unknown, treat it like a risky address rather than an invalid one.
- Is a valid result a guarantee of delivery?
- No. Valid means the recipient's server accepted that address during the SMTP conversation and rejected a random one, so the mailbox very likely exists. Spam filtering, later bounces and full inboxes can still stop a message.