---
title: "What Is Email Verification? The Checks Behind a Result | Emvero"
description: "Email verification checks an address before you use it. See how syntax, DNS, mail routing and SMTP evidence shape the result, and where certainty ends."
url: https://emvero.io/blog/how-email-verification-works/
language: en
updated: 2026-10-14
---

Blog

# What is email verification and how does it work?

Follow an address through syntax, DNS, routing and recipient checks, then see why a completed verification can still leave a mailbox unresolved.

Published 2026-09-11

Email verification checks whether an email address is usable before you depend on it. It examines the address format, domain and mail route, then may ask the receiving server about the recipient. Each answer adds evidence; none guarantees that a future message will arrive. Some checks finish with uncertainty because the server will not disclose enough.

That distinction matters when you are deciding whether to accept a signup, use a contact record or send to an existing list. A plausible address is only the beginning of the investigation.

## Three questions people call “validation”

The terms often overlap in product copy, but the underlying questions are different.

| Question | Method | What you learn |
| --- | --- | --- |
| Is the address well formed? | Syntax validation | Whether its local part and domain follow the accepted structure. No domain or mailbox existence is established. |
| Can this address receive mail? | Pre-send email verification | What DNS, routing and, when available, the receiving server reveal. The answer can remain inconclusive. |
| Does this person control the mailbox? | Email confirmation | Someone acted on a link or code sent to the address at that moment. |

To decide whether an address check can replace a confirmation link, compare [email verification and email confirmation](https://emvero.io/blog/email-verification-vs-email-confirmation/).

“Email validation” can mean the whole pre-send process. If a tool checks only format, though, it cannot answer the second question. The [SMTP versus syntax comparison](https://emvero.io/compare/smtp-vs-syntax-validation/) looks at that narrower choice.

## The five checks, in the order they can happen

Emvero proceeds only as far as the evidence allows. A clear failure early on need not become a network or mailbox check; a full check can reach the last stage and still return `unknown`.

### 1. Syntax: can this be an address?

The parser checks the local part before `@`, the domain after it and the complete address. It can reject malformed input locally. Passing says nothing about whether the domain exists. See the [email syntax reference](https://emvero.io/glossary/email-syntax/) for the format rules.

For a browser implementation of this first step, see the [JavaScript email-validation example](https://emvero.io/blog/email-validation-javascript/).

### 2. Domain: does DNS know it?

The next question goes to DNS. A clear non-existent-domain response is useful negative evidence. A domain that exists may host a website yet accept no mail, so a positive DNS answer is a reason to continue, not a mailbox verdict.

### 3. Routing: where would mail go?

MX records normally identify the destination for a domain’s mail. A null MX explicitly advertises that the domain accepts no mail. No MX record alone is not a failure: SMTP permits an implicit route through the domain host. The [MX record guide](https://emvero.io/glossary/mx-record/) covers these cases. Even a working route describes the domain, not the named mailbox. [RFC 5321, section 5.1](https://www.rfc-editor.org/rfc/rfc5321.html) defines the routing fallback; [RFC 7505](https://www.rfc-editor.org/rfc/rfc7505.html) defines null MX.

A domain check ends here and opens no SMTP session. Recipient evidence requires a full check.

### 4. Recipient: what does the mail server say?

Where the destination permits it, a full check opens an SMTP conversation and names the recipient. The server may accept that name, reject it, temporarily defer a decision or conceal its recipient policy. Even a reply classified as “mailbox not found” remains `unknown` under Emvero’s current policy; it does not automatically reject the address. Clear domain failures, such as a non-existent domain or null MX, can justify `undeliverable` before SMTP. Acceptance is useful, but may describe a catch-all rule or a decision deferred until later in delivery.

The probe uses the envelope, then stops before message content:

```
EHLO verifier.example
MAIL FROM:<probe@verifier.example>
RCPT TO:<person@example.com>
RSET
QUIT
```

`DATA` would start the message body; Emvero does not issue it during verification. No verification email is sent. [RFC 5321, section 3.3](https://www.rfc-editor.org/rfc/rfc5321.html#section-3.3) specifies the transaction and notes that some servers defer recipient validation. The [SMTP handshake reference](https://emvero.io/glossary/smtp-handshake/) explains the exchange in more detail.

### 5. Classification: what should the evidence mean?

Emvero combines the observations with address signals: catch-all behaviour, a disposable provider, a likely domain typo or a role account such as `support@`. These are different findings. A disposable or role mailbox may work perfectly well; its suitability depends on your policy. At a catch-all domain, acceptance of the requested name may reflect a domain-wide rule rather than that mailbox’s existence.

## Why the answer may stay open

A receiving server can throttle a probe, temporarily defer it or hide recipient information. A connection may time out. None of these events establishes a permanent failure. The check should report the evidence it has, rather than turn a lack of evidence into a rejection.

The same applies to catch-all behaviour. If a server accepts arbitrary names, a positive `RCPT TO` reply alone cannot identify which mailboxes exist. A completed check can therefore be `risky` or `unknown` even when the address and domain look sound.

## Read the response before setting a rule

The four terminal `status` values answer what the technical evidence supports:

| `status` | Reading |
| --- | --- |
| `deliverable` | Available routing and recipient evidence support acceptance; future delivery is still unproven. |
| `risky` | Mail may be accepted, but a specific signal needs attention. |
| `undeliverable` | A permanent technical finding supports rejection. |
| `unknown` | The check cannot settle the address from the evidence available. |

`pending` means recipient work is still queued or running. It is a transport state, not a fifth verdict; retrieve the result after the returned retry interval.

The response also separates observation from recommendation. `checks` records stage findings, `reason_codes` names the relevant signals, and `freshness` dates DNS and SMTP evidence. `confidence` is an evidence score, not a probability of delivery. `action` recommends `allow`, `allow_with_email_confirmation` or `reject`. It does not follow mechanically from `status`: `risky` can carry `allow` or `allow_with_email_confirmation`, depending on the cause. The [result-reading article](https://emvero.io/blog/reading-a-verification-result/) explains these fields; the [email verification API](https://emvero.io/email-verification-api/) shows their response shape.

## Put the result to work

For **one address**, inspect its reason codes alongside its status before deciding to use it. An `unknown` answer invites another source of evidence, not an automatic invalid label. You can [run a single-address check](https://emvero.io/email-verification/) to see that distinction in the result.

At **signup or checkout**, a clear technical rejection can justify asking for a correction. A likely typo can be fixed while the person is present. When mailbox control matters and the technical result is `risky` or `unknown`, email confirmation can be a sensible next step. The [signup-form guide](https://emvero.io/guides/signup-form-validation/) maps evidence to form decisions.

For **an existing list**, keep established failures, risk signals and inconclusive records separate. Retain `freshness` so old DNS or recipient observations are not treated as permanent facts. A role or disposable address is a policy question even when it is technically reachable.

Verification does not establish identity, consent, engagement, inbox placement or future delivery. Confirmation shows mailbox control at the time someone acts on a message; it does not supply the other answers either. Use the technical evidence for the decision it can support, and keep the remaining questions with the systems that actually answer them.

## Terms used here

### Email address syntax

The format rules for an email address; passing them does not establish that the domain or mailbox exists.

### MX record

An MX record is a DNS record that names a domain’s incoming mail server and its preference; it does not establish a mailbox.

### SMTP handshake

The command-and-reply exchange with a mail server; a mailbox check uses it to observe the server’s recipient response.

## Situations this applies to

### Validating an address in a signup form

Somebody is waiting on the other side of the request, so latency decides the design and a wrong rejection costs you the customer.

[All articles](https://emvero.io/blog/)

## Choose what to check next.

Run a check from your account and inspect the evidence in its result.

Start for free