How email verification works — without sending an email

The short version: verification runs an address through a pipeline — syntax check → MX lookup → live SMTP RCPT TO probe → catch-all, disposable and role classification — and every stage is a chance to reject or flag the address before you ever send a real campaign. The trick that makes it non-intrusive is that the SMTP probe stops after the recipient step and issues RSET/QUIT; it never sends the DATA command that would deliver an actual message. Here is what happens at each stage, and why a few addresses can never be resolved to a clean yes or no.

Stage 1 — Syntax validation (is this even an address?)

First, cheap and local: does the string obey the rules for an email address? The local part and domain must conform to RFC 5321 and RFC 5322 — one @, a valid domain, no illegal characters or stray spaces. This catches gmail.con, missing @ signs and truncated imports instantly, at zero network cost. But note what it does not prove: a perfectly-formed address like notarealperson@gmail.com passes syntax and still doesn't exist. That's the whole reason verification can't stop here — and why syntax validation and full verification are not the same thing. You can try syntax alone with the Email Syntax Validator.

Stage 2 — Domain & MX lookup (can this domain receive mail at all?)

Next, verification checks DNS for the domain's MX (Mail Exchanger) records — the servers that accept mail for that domain. No MX (and no usable A-record fallback) means the domain can't receive email, so the address is undeliverable regardless of how it's spelled. A special case worth knowing: a domain can publish a "Null MX" record (MX 0 .) to declare explicitly that it accepts no mail. You can inspect any domain's records with the MX Lookup. Passing this stage tells you the domain is reachable; it still says nothing about the specific mailbox.

Stage 3 — The live SMTP probe (does this mailbox exist?)

This is the core of verification. The verifier connects to the domain's MX server on port 25 and begins an SMTP conversation exactly like a real sender: HELO/EHLO, then MAIL FROM, then RCPT TO:<the address>. The receiving server's response to that RCPT TO is the signal — a 250 means it would accept mail for that mailbox, a 550 means no such user. Then the verifier issues QUIT and hangs up. Crucially, it never sends DATA — the command that would transmit the actual message body — so no email is delivered. You're asking the server a question, not sending a letter. You can watch a raw SMTP handshake yourself with the SMTP Test.

> EHLO verifier.example > MAIL FROM:<probe@verifier.example> > RCPT TO:<real.person@example.com> < 250 2.1.5 Recipient OK        ← mailbox accepts mail > RCPT TO:<no.such.user@example.com> < 550 5.1.1 User unknown         ← mailbox does not exist > QUIT                            ← no DATA, no message sent

Stage 4 — Classification (catch-all, disposable, role)

A clean 250 isn't always the end of the story, so verification adds context:

• Catch-all / accept-all: some domains are configured to return 250 for every address, real or not. So a "yes" from a catch-all domain doesn't confirm the individual mailbox — the server would say yes to gibberish too. These are reported as risky/unknown. Detect them with the Catch-All Checker.
• Disposable: the address is on a known throwaway/temporary-mail domain. It's deliverable right now but worthless — flagged by the Disposable Checker.
• Role-based: info@, support@, admin@ route to shared inboxes with higher complaint risk — surfaced by the Role-Based Checker.

The verifier folds all of this into a single status. What each status means, and what to do with it, is covered in verification results explained.

Why some servers return "unknown" — and it's not a bug

Real mail servers actively resist being probed, so a verifier can't always get a definitive answer:

• Greylisting: the server deliberately returns a temporary 4xx "try again later" to unfamiliar senders, betting spammers won't retry. A first-pass probe sees a soft failure, not a clear yes/no.
• Tarpitting / rate-limiting: the server slows the conversation to a crawl or throttles connections, so the probe times out.
• Accept-then-bounce: some providers (notably parts of Microsoft 365) accept every RCPT TO and only decide validity after the message would have been queued — which a non-sending probe can never observe.
• Catch-all, as above — the server answers yes indiscriminately.

In all of these the honest result is unknown, not a guess. A good verifier retries with backoff to clear transient greylisting, but it won't manufacture certainty that the protocol can't provide.

Why "100% accuracy on every address" is a myth

Because of catch-all domains, greylisting and accept-then-bounce behaviour, no verifier can be 100% certain about every address — and any vendor promising that is describing marketing, not SMTP. What good verification does is different and honestly achievable: it removes the addresses that are definitely bad (bad syntax, dead domains, 550 mailboxes, known disposables) and clearly flags the ones that are genuinely uncertain, so you can decide how to treat them. That's the realistic goal — dramatically fewer bounces and a truthful risk label on the rest, not a fictional perfect score.

Verify it yourself

Run a real address end-to-end through the Email Verifier and read the returned status against the stages above — you'll see the MX result, the SMTP outcome and any catch-all/role/disposable flags. To watch the underlying protocol, the SMTP Test shows the live handshake, and the MX Lookup shows the DNS layer. Put together, they demystify the whole pipeline. When you're ready to apply it to a whole file, the list-cleaning workflow shows where verification fits in a pre-campaign clean.