---
title: "Unknown email verification result vs undeliverable - Emvero"
description: "Understand unknown versus undeliverable email results. Use the reason and recommended action to choose confirmation, retrying or holding an address aside."
url: https://emvero.io/compare/unknown-kept-apart/
language: en
updated: 2026-10-08
---

Compared

# Unknown versus undeliverable email results

An unknown email verification result leaves the address unsettled. Keep it separate from an undeliverable result so a failed lookup or inconclusive probe does not become an automatic rejection.

| What you want to know | Treat unknown as undeliverable | Keep unknown separate |
| --- | --- | --- |
| Meaning of the result | Treats missing evidence as a reason to reject | Preserves the difference between an inconclusive check and a deterministic failure |
| Greylisting or a timeout | Rejects an address without a mailbox conclusion | Retains unknown and considers a later check for a temporary reason |
| Policy or capability restriction | Marks the address bad even when the probe was restricted | Reads the reason; repeated probes may not resolve the limitation |
| Signup handling | Blocks the person because the check could not settle the address | Follows the action; asks for email confirmation when control matters |
| List handling | Deletes or suppresses an address as if failure were established | Holds it for a separate decision; neither proves delivery nor approves sending |
| Work still in progress | Can mistake pending for an unsuccessful check | Polls pending after the returned interval before handling the terminal result |

## What each result establishes

`unknown` means the available evidence could not settle the address. A timeout, greylisting or a server policy can leave that outcome. `undeliverable` reflects a deterministic reason to reject under Emvero’s current policy, such as invalid input, `DNS_NXDOMAIN` for the address domain or an explicit `NULL_MX` declaration that the domain accepts no mail.

A negative SMTP reply also needs interpretation. An observation classified as `SMTP_MAILBOX_NOT_FOUND` currently becomes `unknown` with `SMTP_RECIPIENT_REJECTED_AMBIGUOUS`. The service does not treat that probe as sufficient proof to reject the address. This is why the returned `status`, `action` and `reason_codes` need to stay together.

## Choose the next step from the reason

`SMTP_GREYLISTED` or `SMTP_CONNECT_TIMEOUT` can justify a later check. A [greylisting response](https://emvero.io/glossary/greylisting/) is temporary, but a retry still has no guaranteed outcome. `SMTP_POLICY_REJECTED` describes a restriction on the session; immediately repeating it may produce the same refusal. Unsupported extensions and blocked destinations need a different response, as the [unverifiable address definition](https://emvero.io/glossary/unverifiable-address/) explains.

At signup, `allow_with_email_confirmation` lets you continue with confirmation when mailbox control matters. Your application sends that confirmation email; Emvero’s verification sends none. An unknown result does not certify ownership, delivery or suitability for your service.

In a list workflow, keep unknown addresses in a separate group with their evidence. Decide whether to recheck a temporary condition or hold the address for review. Deleting the group loses addresses the verifier did not establish as bad; automatically sending to it assumes an answer the verifier did not obtain. Provider-level restrictions can affect several addresses together.

`pending` is work in progress, not a terminal `unknown`. Poll after the returned interval, then handle the completed result. See the [verification result guide](https://emvero.io/blog/reading-a-verification-result/) for the response fields, and the [score versus evidence comparison](https://emvero.io/compare/score-vs-evidence/) for why a numeric threshold cannot replace this distinction.

## Where this shows up in a result

Reason codes from the closed vocabulary in the API response. These are the exact strings an integration writes an `if` against.

|  |  |
| --- | --- |
| `SMTP_GREYLISTED` | Temporary SMTP deferral; a later check may help but does not guarantee a conclusive result. |
| `SMTP_CONNECT_TIMEOUT` | Mail server did not answer in time |
| `SMTP_MAILBOX_NOT_FOUND` | Recipient refusal observed by SMTP; current policy returns unknown with SMTP_RECIPIENT_REJECTED_AMBIGUOUS. |
| `SMTP_POLICY_REJECTED` | Session refused on policy |

## Related terms

### Greylisting

A receiving-server policy that temporarily defers an unfamiliar SMTP attempt; a later attempt may pass.

### Hard bounce and soft bounce

Common labels for permanent and temporary delivery failures; neither label alone explains the cause.

### Codes that describe us, not the address

Reasons that explain omitted or incomplete work within Emvero, without establishing a missing mailbox.

### Policy rejection

A receiving server refuses an SMTP operation under its security or policy rules; the refusal does not establish a missing mailbox.

[All comparisons](https://emvero.io/compare/)

## Read a verification result.

See an example of status, recommended action and check evidence. Sign in to check your own address.

See an example check

Start for free