Valid
The available evidence supports a positive mailbox result at the time of checking.
Read email verificationRead the result.
Keep the uncertainty.
RefreshList separates the core verification outcome from additional signals and provider reasons. This guide explains what each status says, what it does not say, and what to do next.
Plain-language reference · Statuses describe checking evidence, not a delivery promiseTHE SHORT ANSWER
How should you read a verification result?
Start with the core outcome: valid, invalid, or unknown. Then read the provider code and reason. Finally, check for additional signals such as catch-all, role-based, or disposable classification. Never treat a missing signal as a confirmed negative finding, and never convert unknown into invalid or valid.
01 / OUTCOMEWhat the available evidence supports
02 / REASONWhy the provider returned that outcome
03 / SIGNALAdditional context, when supported
01 / THE THREE OUTCOMES
Outcome first. Action second.
Unknown
The evidence is inconclusive. Keep the row visible and preserve the reason instead of guessing.
Understand unknown email resultsInvalid
The available evidence supports a conclusive failure for the checked address. Keep the provider reason attached.
Understand invalid email results02 / COMMON STATUS CODES
What the provider reason is telling you.
OKThe server says it is ready to receive a message and no verification tricks were detected.Ready according to the response.
UNKNOWN_EMAILThe server says delivery failed and the email does not exist.Review this address before sending.
ANTISPAM_SYSTEMAn antispam system blocked verification progress.Verification was blocked.
DOMAIN_ERRORThe domain mail server or DNS is missing or incorrect, so email is not deliverable.Review the domain configuration.
OK_FOR_ALLThe server is ready to accept a message for any address on this domain.Individual mailbox existence is not confirmed.
DEAD_SERVERThe mail server did not respond and appears unavailable.The address cannot be confirmed.
SYNTAX_ERRORThe email address has a syntax error.Correct the source value before checking again.
UNKNOWNDelivery failed without a reason that identifies the cause.Keep the response visible.
IMPORTANTOK is not a send instruction.
A provider response can indicate that a server accepted the verification conversation. It cannot establish permission, monitoring, sender reputation, or future delivery.
Read the methodology03 / FULL STATUS REFERENCE
Search the exact code in your export.
These provider codes remain attached to result rows so your team can review the evidence without reconstructing the job.
CODEMEANINGNEXT ACTION
OKThe server says it is ready to receive a message and no verification tricks were detected.Ready according to the response.
ERRORThe server says delivery failed, but gave no information about email existence or availability.Review the response as unresolved.
SMTP_ERRORThe SMTP server returned an invalid response or an internal error.The response was not reliable enough for a conclusion.
SMTP_PROTOCOLThe SMTP server allowed a connection but closed the session before verification finished.Treat the check as incomplete.
UNKNOWN_EMAILThe server says delivery failed and the email does not exist.Review this address before sending.
ATTEMPT_REJECTEDDelivery failed with a rejection-style response.Keep the response reason with the row.
RELAY_ERRORDelivery failed because of a mail-relaying problem.The failure points to routing.
ANTISPAM_SYSTEMAn antispam system blocked verification progress.Verification was blocked.
EMAIL_DISABLEDThe email account is suspended, disabled, or limited and cannot receive messages.Do not treat it as ready.
DOMAIN_ERRORThe domain mail server or DNS is missing or incorrect, so email is not deliverable.Review the domain configuration.
OK_FOR_ALLThe server is ready to accept a message for any address on this domain.Individual mailbox existence is not confirmed.
DEAD_SERVERThe mail server did not respond and appears unavailable.The address cannot be confirmed.
SYNTAX_ERRORThe email address has a syntax error.Correct the source value before checking again.
UNKNOWNDelivery failed without a reason that identifies the cause.Keep the response visible.
EMAIL_EXISTSThe email appears to exist, but deliverability information is unavailable.Use the response with safeguards.
SIGNALS ARE CONTEXT
One label cannot answer every question.
A role-based address can be valid. A catch-all domain can accept a recipient without proving the mailbox. A disposable flag can describe a dataset match without proving intent. Read each signal alongside the outcome and coverage.
Read the verification guideUnknown stays unknown.
RefreshList does not add a confidence percentage to make an inconclusive answer look precise. The reason and checking context remain visible.
COMMON QUESTIONS
Status questions, answered.
What is the difference between a result and a signal?+
A result is the core verification conclusion, such as valid, invalid, or unknown. A signal describes additional context, such as role-based, catch-all, or disposable, when supported. A signal does not replace the core outcome.
Does unknown mean invalid?+
No. Unknown means the available evidence was not conclusive. Keep it separate, retain the provider reason, and decide whether a later first-party interaction or a controlled recheck is appropriate.
What does OK_FOR_ALL mean?+
It indicates domain-level acceptance for many recipient names. It does not prove that the individual mailbox exists or is monitored. Treat it as a catch-all signal, not as a guaranteed valid inbox.
Are status labels delivery guarantees?+
No. Statuses describe available evidence at the checking moment. Sender reputation, consent, content, policy, timing, and later mailbox changes can still affect delivery.
Do all statuses use a credit?+
Completed unique checks use one credit, including conclusive and unknown outcomes. Rows skipped during local preflight and duplicate rows are excluded before provider verification.
OUTCOME.
REASON.
LIMITATION.
Keep the evidence together before deciding what happens next.