What Does an Unknown Email Verification Result Mean?
An unknown result means the check genuinely couldn't reach a confident answer — it's not a soft pass and not a rejection. It's the honest outcome whenever the evidence doesn't clearly support either accepted or rejected: SMTP verification wasn't run at all, the mail server gave an ambiguous or non-committal response, the domain is catch-all, or the check timed out.
Why a three-outcome model, not just pass/fail
A verification system that only ever says valid or invalid is forced to guess whenever the evidence is genuinely ambiguous — and a wrong guess reported with false confidence is worse than an honest "we don't know." Every status field in this API — smtp_check, verification.status, deliverability.status — supports an explicit unknown outcome specifically so ambiguous cases are reported as ambiguous, not silently resolved in either direction.
The specific things that produce an unknown result
| Cause | What's happening |
|---|---|
| SMTP verification never ran | Mode was fast or standard, not full — no SMTP attempt was made at all, so there's simply no mailbox-level evidence yet |
| Catch-all domain detected | The server accepts any address, so an accepted response no longer distinguishes real from fake — see How Catch-All Email Domains Work |
| 4xx / ambiguous SMTP response | The server responded, but not with a clear accept (2xx) or reject (5xx) — often temporary issues or greylisting |
| Timeout | No response arrived within the time budget — the server may be slow, unreachable, or deliberately non-responsive to probes |
| Circuit breaker open for the domain | Recent repeated failures against this domain paused further probing to avoid hammering a struggling server |
| No MX record to connect to | There's no mail server to even attempt SMTP verification against |
How to treat an unknown result in practice
Don't treat it as either "probably fine" or "probably bad" — treat it as exactly what it is: undetermined. In a risk-scoring context, unknown SMTP results contribute a small, low-severity signal (reflecting mild uncertainty) rather than nothing and rather than a large penalty (which would incorrectly treat inconclusive as suspicious). Where the decision matters enough, the practical fix isn't to guess harder — it's to gather more evidence: run full mode if you only ran standard, or fall back to a confirmation email for the cases pre-send checks genuinely can't resolve.
Look at confidence alongside status
Every relevant field returns its own confidence value alongside the status. A likely_valid verification with high confidence and one with low confidence both say "probably valid," but they warrant different handling — high confidence is fine to act on directly, low confidence is a candidate for a secondary check before you rely on it for something costly.
FAQ
Generally no, not on that basis alone. Unknown reflects insufficient evidence, not a negative result. Combine it with the overall risk score and decision rather than treating it as a standalone block reason.
No. It specifically means the check couldn't confirm existence either way — the mailbox could be perfectly real.
Sometimes — full mode adds live SMTP verification, which can turn an unknown into a confident accepted or rejected. It can't help in the catch-all or persistent-timeout cases, where the ambiguity is structural.
It means the mail server responded with a 2xx code to RCPT TO for that specific address, and the domain wasn't detected as catch-all — strong evidence the mailbox exists, though see Why Valid Emails Can Still Bounce for why even this isn't an absolute, permanent guarantee.