How SMTP Email Verification Works

Email verification tools often describe what they do — "we check if the address is real" — without explaining how. For developers and technically curious marketers, the mechanics are worth understanding. The most powerful verification check, SMTP handshake verification, is elegant in its simplicity.

The layers of email verification

Email verification works in stages, each catching a different class of problem. They run in sequence, and each step only matters if the previous one passed.

Layer 1: Syntax validation

Before anything hits the network, the address is checked against the email format rules defined in RFC 5321 and RFC 5322. This catches structural problems: missing @ symbols, double @, spaces in the local part, or invalid characters.

Most email addresses fail syntax checks only because of typos — user@gmial.com passes syntax (it's structurally valid) but would fail at the domain layer.

Layer 2: DNS MX record lookup

Every domain that wants to receive email must publish MX records in DNS. These records point to the mail servers responsible for handling that domain's incoming messages.

The verifier performs a DNS lookup for the MX records of the email's domain. If no MX records exist, the domain can't receive email — any message sent there will fail delivery. This catches:

• Deleted or expired domains
• Domains that exist as websites but have no mail infrastructure
• Typos in the domain that resolve to nothing (@gmai.com, @outloook.com)

If MX records are found, the verifier has the address of the mail servers to talk to.

Layer 3: SMTP handshake

This is the core of email verification, and it's where the real work happens.

The SMTP handshake in detail

SMTP (Simple Mail Transfer Protocol) is the protocol used to send email between servers. It's a text-based conversation — literally a series of commands and responses. An email verification tool uses this conversation to probe whether a mailbox exists, without sending an actual message.

Here's what a typical verification exchange looks like:

Verifier → Server:   HELO verify.example.com
Server → Verifier:   220 mail.domain.com ESMTP ready

Verifier → Server:   MAIL FROM: <probe@verify.example.com>
Server → Verifier:   250 OK

Verifier → Server:   RCPT TO: <user@domain.com>
Server → Verifier:   250 OK  ← address exists
                     (or)
                     550 No such user  ← address doesn't exist

Verifier → Server:   QUIT
Server → Verifier:   221 Bye

The critical exchange is RCPT TO. The verifier provides the address it wants to check, and the mail server responds:

• 250 OK — the server accepts the address, meaning the mailbox exists
• 550 / 551 / 553 — the server rejects the address with a permanent failure code, meaning the mailbox doesn't exist
• 421 / 450 / 451 — temporary failure codes; the server is busy or rate-limiting; try again later
• 252 — the server can't confirm whether the mailbox exists (a deliberately ambiguous response some servers send)

The verifier sends QUIT immediately after the RCPT TO response — no email is ever sent. This is what makes the technique non-intrusive.

The complications

The theory is straightforward. The practice has several wrinkles.

Catch-all servers

Some mail servers are configured to accept every RCPT TO with a 250 response, regardless of whether the specific mailbox exists. This is the catch-all configuration. When a verifier encounters a catch-all server, it gets a 250 for any address on that domain — including completely made-up ones. There's no way to determine via SMTP whether a specific mailbox exists on a catch-all domain.

Good verification tools detect catch-all behaviour by testing a randomly generated address against the domain. If that address gets a 250, the verifier knows it's dealing with a catch-all and marks all addresses on that domain as unknown.

Rate limiting and IP blocking

Large mail providers — particularly Gmail, Yahoo, and Outlook — rate-limit or block SMTP connections from IP addresses that make too many verification probes. This is intentional: these providers don't want their infrastructure used as a free email list validation service.

Verification services handle this by distributing requests across large pools of IP addresses, rotating senders, and pacing requests carefully. The quality of this infrastructure significantly affects how accurate the verification results are.

Greylisting

Greylisting is a spam-prevention technique where a mail server temporarily rejects a first delivery attempt from an unknown sender (with a 451 response) and expects the sending server to retry. Legitimate mail servers retry; many spam tools don't.

A verification tool encountering greylisting will receive a temporary failure code — neither a confirmation nor a rejection. It typically marks these addresses as unknown and moves on.

Server-side suppression of VRFY

The SMTP protocol includes a VRFY command specifically designed to verify whether a mailbox exists. Essentially every public mail server disables it, because it was historically abused for harvesting email addresses. This is why modern verification uses RCPT TO instead.

What the results mean

After running through these checks, a verification service will classify each address:

• Valid — Syntax passed, MX records found, mail server responded 250 to RCPT TO (and is not a catch-all)
• Invalid — Syntax failed, no MX records, or mail server responded with a permanent failure code
• Unknown — Catch-all domain, temporary server failure, greylisting, or any other condition where a definitive result couldn't be obtained

Why this matters in practice

Understanding how SMTP verification works helps you interpret results correctly. An unknown result doesn't mean the address is bad — it means the check couldn't determine either way. A valid result is a strong positive signal but not a guarantee (the mailbox could still be unmaintained, inactive, or managed by someone who will never open your email).

Verification is a filter, not a guarantee. But applied before a send, it removes the addresses most likely to generate hard bounces and most likely to hurt your sender reputation.

StopBouncing runs all three layers of verification — syntax, DNS, and SMTP — against every address in your list, returning clear results you can act on.