An email verifier can support one narrow decision: whether an address is eligible for the next sending action under a defined policy. Read the provider's status, reason field, and retained uncertainty together. Keep catch-all and unknown separate. Here, send means address-level eligibility only; it does not establish consent or desire, legal compliance, inbox placement, or sender reputation, and it does not predict future delivery.
A Valid Label Is Not a Sending Policy
What has an email verifier actually told you? The reviewed products return an address state plus varying detail about why that state was assigned. That can inform whether the address enters your next-action queue. It cannot decide whether the person wanted the message, whether your use is lawful, where a message will land, or what will happen to sender reputation. Keep that narrower question in view before any label becomes an action.
Why Address Status and Sending Confidence Are Different Judgments
A positive result answers a bounded address question under one provider's method. A sending decision also depends on audience policy, permission or another lawful basis where required, message context, and operational controls. If you call the verifier result a complete confidence judgment, those separate considerations disappear. Use send as a workflow label only: this address has cleared the verifier portion of eligibility, subject to every other requirement your organization applies.
What an Email Verifier Can Observe Without Proving Future Delivery
The documents expose combinations of syntax, domain or DNS information, mail-server response, mailbox signals, catch-all behavior, and provider-specific risk attributes. Ask which checks ran and which did not. A syntactically correct address with an MX record is not the same as a confirmed mailbox; a server response today is not a promise about delivery tomorrow. If a check or result field is absent from the documentation, record it as not documented, not as passed.
Read Result Semantics Before Choosing an Action
The first trap is translation by familiar words. ZeroBounce publishes valid, invalid, catch-all, unknown, and additional provider-specific risk classes. Bouncer and Emailable use deliverable, risky, undeliverable, and unknown, while exposing accept-all information beside the main result. You therefore need the definition and reason, not just a normalized label. A shared word can hide different evidence; different words can describe a comparable operational state.
How Valid, Invalid, Disposable, and Blocked States Change the Default Action
Start with the reason that produced the state. A documented positive mailbox result can clear the address check. A failed syntax, invalid domain, or rejected mailbox supports suppression. Disposable or blocked categories need your local policy because providers group them differently. Don't translate every positive-sounding label to send or every risk label to suppress. Read the provider's reason and any domain or account flags, then apply the action definition you control.
Why Catch-All and Unknown Preserve Different Kinds of Uncertainty
Catch-all describes domain behavior: the server may accept probes without confirming that this specific mailbox exists. Unknown describes an incomplete determination, often because the service could not get a usable response within the available check. Those are not interchangeable. With catch-all, you know something about the domain response but not the mailbox. With unknown, you may not even have a stable domain or server conclusion. Preserve both states so you can choose a different next step.
Which Documented Checks Produced the State and Which Uncertainty Remains
Build your review record from fields, not assumptions. Keep the raw status, the reason or sub-status, catch-all or accept-all information, the check time, and the provider name. ZeroBounce warns that some unknown and invalid results may lack a sub-status; in that case the reason is unknown. Bouncer and Emailable document reason vocabularies, but you still shouldn't invent a value when the returned field is blank. Missing detail is itself a reason to avoid automatic translation.
Map Uncertainty to Send, Suppress, Recheck, or Manual Review
Now turn semantics into an action without overstating what the action means. The following crosswalk is an operating framework, not a claim that every provider recommends the same treatment. Send means only that the address is eligible for the next sending action after it clears the verifier rule. Your separate permission, legal, content, and sending controls still apply. If status and reason disagree or documentation is silent, keep the exception visible. OKKI Go's documented human-confirmed outreach workflow illustrates a separate control: after a user selects recipients and supplies company context or product material, it drafts the outreach and requires confirmation of the recipients, subject, and body before sending. That workflow does not verify the address or turn send into permission, compliance, inbox placement, or sender-reputation assurance.
- Send: use only for address-level eligibility when the documented positive state and reason contain no unresolved or locally suppressible condition.
- Suppress: use for deterministic negative reasons such as failed syntax, invalid domain, or rejected mailbox, plus any explicitly excluded category in your own policy.
- Recheck: use when the reason is time-sensitive or transient, such as timeout, greylisting, temporary server error, or unavailable SMTP.
- Manual review: use for catch-all behavior, ambiguous risky results, conflicting fields, a missing reason, or any provider-specific state your policy has not mapped.
When a Result Can Support Send and When It Should Be Suppressed
For automation, require a state-and-reason pair you can explain. A documented positive state with a matching accepted reason may support send at the address layer. A deterministic negative reason supports suppress. But what if the main state looks positive while a risk attribute remains? Route by your written exception rule instead of silently choosing the friendlier field. The goal is reproducibility: another operator should reach the same address action from the same returned fields.
When Freshness or Ambiguity Makes Rechecking More Useful Than Sending
Recheck is useful when the returned reason suggests that the observation may change: a timeout, greylisting response, temporary server problem, or unavailable SMTP service. Store the original state and reason before you retry so the second result does not erase the first. A later positive result can update address eligibility; it cannot retroactively prove that the earlier unknown was invalid. If no retry guidance or transient reason is documented, mark the timing rule as not documented and avoid inventing one.
Which Exceptions Deserve Manual Review Instead of a Forced Binary Label
Manual review is the honest destination when your crosswalk cannot preserve meaning automatically. Send catch-all there if mailbox existence remains unresolved. Send a risky result there when the reason mixes deliverability and quality concerns your policy treats differently. Send blank reasons and contradictory fields there too. Review doesn't mean guessing from the person's role or the attractiveness of the account. It means deciding whether to recheck, suppress, or keep the address unresolved while retaining the evidence that made automation stop.
Compare Status Taxonomies by Operational Meaning
A useful vendor comparison asks three field-level questions. Is each top-level status defined clearly enough to support an action? Does the result include a documented reason that explains the state? Does the model retain uncertainty, or force an unresolved address into positive or negative? Those questions produce a crosswalk you can audit. They do not produce a universal winner, because the reviewed documents do not establish comparative accuracy, pricing, or outcomes under the same test conditions.
- ZeroBounce: catch-all and unknown are separate top-level statuses. sub_status explains many negative or unresolved causes, although the documentation says it is not populated for every unknown or invalid result.
- Bouncer: deliverable, risky, undeliverable, and unknown are the main statuses. reason explains the result, while acceptAll and several account or domain attributes retain yes, no, or unknown values.
- Emailable: deliverable, risky, undeliverable, unknown, and duplicate are documented states. reason describes state causes, unknown stays separate from undeliverable, and accept-all appears as a separate attribute in its API model.
How to Normalize Provider Labels Without Assuming They Are Equivalent
Normalize to an action only after you store the raw provider values. Map a positive state plus accepted reason to your eligible bucket; deterministic negatives to suppress; transient unknown reasons to recheck; and unresolved catch-all, ambiguous risky, or missing-reason cases to manual review. Keep the original status beside your normalized action. If a provider does not document a reason or field you need, write not documented. That prevents a tidy internal label from pretending the source supplied more certainty than it did.
The Decision Rule for Retaining an Explicit Uncertainty State
Here is the durable rule: automate only when the documented state and reason jointly justify the same address action. If either one preserves uncertainty, your normalized result must preserve it too. Catch-all remains a mailbox-existence exception; unknown remains an incomplete determination; a transient reason can become recheck; and an unexplained result stays in review. That discipline is more useful than a binary valid rate because it tells you what the system may do next and exactly where its authority stops.
Keep the provider's raw status, reason, uncertainty signal, and check time beside your normalized action. If that record cannot explain why an address was sent, suppressed, rechecked, or reviewed, the crosswalk is hiding uncertainty instead of governing it. Address eligibility is the end of the verifier's decision, not the end of yours.
Frequently asked questions
Does a valid email verifier result give permission to contact someone?
No. A positive result may clear the address-verification portion of your workflow. It does not establish recipient consent or desire, legal compliance, or permission for a particular message.
Are catch-all and unknown verifier results the same?
No. Catch-all records domain acceptance behavior without confirming the specific mailbox. Unknown records an incomplete determination, often with a reason such as timeout or unavailable server. Keep them as separate policy states.
When should an unknown email result be rechecked?
Recheck when the documented reason is plausibly transient, such as greylisting, timeout, temporary server error, or unavailable SMTP. Preserve the first result and do not assume a later result was true earlier.
What should you do when a verifier does not document a reason field?
Record the reason as not documented and avoid an automatic positive or negative translation. Keep the raw result, provider, and check time, then route the address to manual review or a documented recheck rule.
