Key Takeaways
- Email verification returns a verdict with nuance, not a simple true or false. The four core statuses are valid, invalid, risky, and unknown.
- Valid means the mailbox was confirmed and is safe to send; invalid means the server rejected it and it should be suppressed.
- Risky and unknown are where decisions get made: catch-all, role, and disposable flags need a policy, and unknown often just needs a retry.
- The sub-status field tells you why an address landed in its bucket, which is what turns a status into an actual send-or-suppress decision.
Verification is only half the job. The other half is knowing what to do with the answer, and that is where most teams either bounce campaigns or throw away real prospects. Email verification results do not come back as a simple yes or no. They come back as a status with nuance, and understanding that nuance is what determines whether you protect your sender reputation or damage it. This guide explains what each verdict means and how to turn it into a decision.
Start with the mental model: every verified address lands in one of four buckets, and each bucket has a default action. The art is in handling the buckets that are not obvious.
Valid: The Green Light
A valid result means the mail server confirmed the mailbox exists and is accepting messages. On a well-maintained business list, roughly 70 to 80 percent of addresses return valid. The corresponding sub-status is typically mailboxExists, and the action is simple: send with confidence.
There is one nuance worth noting even here. Valid confirms the mailbox is real and reachable today; it does not guarantee the person will engage, and it does not stop the address from decaying later. Valid is a deliverability verdict, not an engagement prediction.
Invalid: The Clear Suppress
An invalid result means the server explicitly rejected the address. The mailbox does not exist, the domain has no MX records, or the syntax is broken. The sub-status makes the reason precise: mailboxDoesNotExist, domainDoesNotExist, mxServerDoesNotExist, or invalidSyntax.
The action is equally clear: suppress these permanently. Sending to invalid addresses is the fastest way to spike your bounce rate, which is exactly the signal that damages sender reputation with Gmail, Yahoo, and Microsoft. There is no upside to keeping them and real downside to mailing them. Remove them with a bulk email verifier pass before every major send.
Risky: Where Teams Lose Money
The risky bucket is the one that costs people money, because both easy answers are wrong. If you treat all of it as valid, you bounce. If you delete all of it, you throw away real prospects, because plenty of legitimate contacts land here. Risky is a signal to look at the sub-status and apply a policy, not a verdict to blindly send or delete.
The common risky flags each need their own handling:
- isCatchall means the domain accepts every address at the SMTP stage, so existence cannot be confirmed. Many are real; send in small, monitored batches rather than all at once.
- isRoleAccount flags addresses like info@ and sales@ that belong to a team. These carry higher bounce and complaint risk and many ESPs restrict them.
- isDisposable marks temporary-mail domains. For marketing, suppress; for a one-time transactional message, it may be acceptable.
The right move is to route risky addresses by flag rather than treating the bucket as one thing. The email verification API documentation lists every flag so you can build the routing logic that fits your risk tolerance.
Unknown: Usually a Retry
An unknown result means the verifier could not get a definitive answer. The most common causes are greylisting, where the server deliberately defers a first contact (sub-status isGreylisting), or a transient error (transientError). These are temporary conditions, not permanent verdicts.
The action is usually to retry after a delay rather than to suppress. A well-built verifier handles much of this automatically, but when unknown persists, treat the address with caution and confirm before adding it to a high-volume send. Do not mistake unknown for invalid; deleting every unknown address discards a meaningful number of reachable mailboxes that were simply greylisted at the moment of the check.
Turning Results Into a Workflow
A clean workflow sends valid, suppresses invalid, routes risky by flag, and retries unknown. Wired into your stack, that logic runs automatically: verify at signup with the free email verification tool or the API for real-time decisions, and run periodic bulk passes to re-sort a list that decays over time. New accounts can see the full result set on their own data with 100 free email verification credits.
Frequently Asked Questions
What does a risky email verification result mean?
Risky means the address is real or plausibly real but carries elevated deliverability risk, usually because it is a catch-all domain, a role-based address like info@, or a disposable address. It is not a verdict to blindly send or delete; check the sub-status flag and apply a policy, such as sending catch-alls in small monitored batches.
Should I delete unknown email addresses?
Not automatically. Unknown usually means a temporary condition like greylisting or a transient server error, not that the mailbox is invalid. The better move is to retry after a delay. Deleting every unknown address discards reachable mailboxes that were simply deferred at the moment of the check.
What is the difference between status and sub-status?
The status is the top-level verdict (valid, invalid, risky, or unknown), while the sub-status explains why, such as mailboxDoesNotExist, isCatchall, or isGreylisting. The status tells you the bucket; the sub-status gives you the reason, which is what lets you build precise send-or-suppress rules.
What percentage of a list is usually valid?
On a well-maintained business list, roughly 70 to 80 percent of addresses return valid, with the rest split across invalid, risky, and unknown. A much lower valid rate usually signals an aging list or a data-sourcing problem worth investigating before you send.