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.
“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 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 for the format rules.
For a browser implementation of this first step, see the JavaScript email-validation example.
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 covers these cases. Even a working route describes the domain, not the named mailbox. RFC 5321, section 5.1 defines the routing fallback; RFC 7505 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 specifies the transaction and notes that some servers defer recipient validation. The SMTP handshake reference 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 explains these fields; the 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 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 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.