--- title: "Email Verification Result Status Guide | Refresh List" description: "Understand Refresh List email verification statuses, provider reasons, unknown outcomes, catch-all signals, and the right next action for each result." url: https://refreshlist.net/result-status-guide last_updated: 2026-09-25 --- [Refresh List](/) › Result status guide REFERENCE / RESULT STATUS GUIDE # Read the result. Keep the uncertainty. Refresh List 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 promise THE 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 / OUTCOME What the available evidence supports 02 / REASON Why the provider returned that outcome 03 / SIGNAL Additional context, when supported 01 / THE THREE OUTCOMES ## Outcome first. Action second. ### Valid The available evidence supports a positive mailbox result at the time of checking. [Read email verification](/email-verification) ### Unknown The evidence is inconclusive. Keep the row visible and preserve the reason instead of guessing. [Understand unknown email results](/unknown-email) ### Invalid The available evidence supports a conclusive failure for the checked address. Keep the provider reason attached. [Understand invalid email results](/invalid-email) 02 / COMMON STATUS CODES ## What the provider reason is telling you. OK The server says it is ready to receive a message and no verification tricks were detected. Ready according to the response. UNKNOWN_EMAIL The server says delivery failed and the email does not exist. Review this address before sending. ANTISPAM_SYSTEM An antispam system blocked verification progress. Verification was blocked. DOMAIN_ERROR The domain mail server or DNS is missing or incorrect, so email is not deliverable. Review the domain configuration. OK_FOR_ALL The server is ready to accept a message for any address on this domain. Individual mailbox existence is not confirmed. DEAD_SERVER The mail server did not respond and appears unavailable. The address cannot be confirmed. SYNTAX_ERROR The email address has a syntax error. Correct the source value before checking again. UNKNOWN Delivery failed without a reason that identifies the cause. Keep the response visible. IMPORTANT OK 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 methodology](/verification-methodology) 03 / 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. CODE MEANING NEXT ACTION OK The server says it is ready to receive a message and no verification tricks were detected. Ready according to the response. ERROR The server says delivery failed, but gave no information about email existence or availability. Review the response as unresolved. SMTP_ERROR The SMTP server returned an invalid response or an internal error. The response was not reliable enough for a conclusion. SMTP_PROTOCOL The SMTP server allowed a connection but closed the session before verification finished. Treat the check as incomplete. UNKNOWN_EMAIL The server says delivery failed and the email does not exist. Review this address before sending. ATTEMPT_REJECTED Delivery failed with a rejection-style response. Keep the response reason with the row. RELAY_ERROR Delivery failed because of a mail-relaying problem. The failure points to routing. ANTISPAM_SYSTEM An antispam system blocked verification progress. Verification was blocked. EMAIL_DISABLED The email account is suspended, disabled, or limited and cannot receive messages. Do not treat it as ready. DOMAIN_ERROR The domain mail server or DNS is missing or incorrect, so email is not deliverable. Review the domain configuration. OK_FOR_ALL The server is ready to accept a message for any address on this domain. Individual mailbox existence is not confirmed. DEAD_SERVER The mail server did not respond and appears unavailable. The address cannot be confirmed. SYNTAX_ERROR The email address has a syntax error. Correct the source value before checking again. UNKNOWN Delivery failed without a reason that identifies the cause. Keep the response visible. EMAIL_EXISTS The 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 guide](/email-verification) Unknown stays unknown. Refresh List 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. THE READING RULE ## OUTCOME. REASON. LIMITATION. Keep the evidence together before deciding what happens next. [READ THE METHODOLOGY](/verification-methodology) [Review the trust center](/trust) ## Sitemap - [All Public Pages](https://refreshlist.net/sitemap.md) - [Email Glossary](https://refreshlist.net/glossary) - [Read This Page And Use Interactive Features](https://refreshlist.net/result-status-guide)