Compared
SMTP verification versus syntax validation
Syntax validation checks the shape of an email address without network contact. SMTP verification can collect a server’s recipient response, but acceptance still cannot guarantee delivery or mailbox control.
| What you want to know | Syntax validation | A full check with possible SMTP evidence |
|---|---|---|
| What it examines | The input’s supported structure and length | Domain and routing evidence, then recipient replies where probing is possible |
| Well-formed but wrong address | Can pass even when the person entered the wrong recipient or domain | Domain failures or typo signals may help; no check can infer the person’s intended address |
| Mailbox existence | Does not contact the destination | Acceptance is evidence; catch-all or an inconclusive refusal can leave the mailbox unsettled |
| Plus tags and Unicode | Depends on the parser’s supported grammar and policy | Preserves the address; non-ASCII local parts also need destination SMTPUTF8 support |
| Network work | Can run locally without DNS or SMTP | Requires domain evidence; SMTP may run, be skipped, or remain pending |
| Application decision | Rejects malformed input, without proving delivery for valid input | Reads status, action and reason codes; unknown remains separate from undeliverable |
Choose the check for the question
A format check can catch a missing @ or a malformed local part while the person is still entering the address. It cannot establish that a domain exists or a mailbox receives mail. alex@example.com is well formed whether or not a mailbox named Alex exists. The email syntax definition describes the input rules.
A full verification checks domain and mail-routing evidence and may open an SMTP session. At RCPT TO, the receiving server responds to the named recipient. Emvero stops before DATA and sends no message. The SMTP handshake definition and RFC 5321 explain those stages. A full check can also skip SMTP under policy or return pending; its name describes depth, not a promise that a session always runs.
Interpret failures and acceptance carefully
A syntax parser does not look up the domain. A later domain check can establish DNS_NXDOMAIN, while LIKELY_DOMAIN_TYPO is a suggestion rather than proof of the intended spelling. A domain can exist even when the person typed the wrong one.
SMTP adds an observation about the transaction. A catch-all server may accept arbitrary recipients and lead to risky. A refusal classified as SMTP_MAILBOX_NOT_FOUND is currently returned as unknown with SMTP_RECIPIENT_REJECTED_AMBIGUOUS. Timeouts and server restrictions can also leave the result inconclusive. Neither acceptance nor refusal from a probe is a guarantee about a later message.
Combine the stages in a signup flow
Check supported syntax locally, preserve the submitted local part, then ask your server to verify the address when network evidence matters. The guide to addresses with a plus sign explains why removing a tag can change the recipient. A non-ASCII local part also depends on the destination’s SMTPUTF8 support.
For completed checks, use the returned action together with status and reason_codes. Poll pending rather than turning it into unknown; use confirmation when mailbox control matters. The signup validation guide shows how to apply allow_with_email_confirmation without making an inconclusive probe an automatic rejection.
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.
INVALID_SYNTAX | Address is not well formed |
DNS_NXDOMAIN | Domain does not exist |
SMTP_MAILBOX_NOT_FOUND | Recipient refusal observed by SMTP; current policy returns unknown with SMTP_RECIPIENT_REJECTED_AMBIGUOUS. |
LIKELY_DOMAIN_TYPO | Domain looks like a typo |
Read a verification result.
See an example of status, recommended action and check evidence. Sign in to check your own address.