How SMTP RCPT validation works (without sending a test email)

By Andrej Užušienis · June 29, 2026 · 8 min read

When you put an email address into a verification tool and get back a verdict — "valid," "invalid," "catch-all" — there is a non-obvious thing happening: the tool is talking to the recipient's actual mail server in real time. It is not sending a message. It is not generating any "did this arrive" round-trip. It is using a small piece of the SMTP protocol that exists for exactly this purpose, and stopping before any mail is delivered.

This article walks through what that looks like at the protocol level, why it works, the four edge cases that make naive implementations wrong, and what to do about each one.

The four checks before SMTP even matters

SMTP RCPT validation is the slowest and most expensive of the checks a verifier runs, so it sits at the bottom of the funnel. The faster checks happen first because they kill most invalid addresses for free.

1. Syntax (RFC 5322). Is the local part well-formed? Is the domain a registrable label? This catches typos like name@@company.com or name@.com.
2. MX record lookup. Does the domain have a usable MX record at all? A domain with no MX cannot receive mail. (Strictly, fallback to A is allowed in the RFC but receivers ignore it; treat no-MX as no-mail.)
3. Disposable detection. Is the domain on a list of known disposable-mail providers (1mail, Mailinator, Guerrilla, Temp-Mail, and 648 more)? Disposable addresses are real and accept mail — they are just not useful to you.
4. Role-account check. Is the local part a generic mailbox (info@, admin@, sales@)? These are technically valid but tend to be black holes for cold outreach.

By the time we reach SMTP RCPT, most bad addresses are already gone. What is left is a syntactically clean address at a domain that actually receives mail. The remaining question — does this specific mailbox exist? — is what SMTP RCPT answers.

The protocol exchange, end to end

Here is what the wire looks like when our validator checks jane@example.com. The >> lines are what we send. The << lines are what the remote server says.

>> (open TCP connection to MX of example.com on port 25)
<< 220 mail.example.com ESMTP ready
>> EHLO mailcheq.com
<< 250-mail.example.com Hello mailcheq.com
<< 250-SIZE 52428800
<< 250 STARTTLS
>> MAIL FROM:<probe@mailcheq.com>
<< 250 2.1.0 Sender OK
>> RCPT TO:<jane@example.com>
<< 250 2.1.5 Recipient OK
>> QUIT
<< 221 2.0.0 Bye

The verdict is in line 9. The remote server returned 250 for the RCPT command — meaning "yes, I will accept mail for this address." We send QUIT before the DATA command, so no message body is ever transferred, no inbox is touched, no recipient sees anything.

If the address did not exist, the same exchange would end like this:

>> RCPT TO:<nonexistent@example.com>
<< 550 5.1.1 No such user here

The 550 response is the signal. The address is invalid.

Edge case #1: catch-all domains

Some domains are configured to accept mail to any local part — typical at agencies, schools, and most small business hosting. The mailbox random-string-no-one-uses@catchalldomain.com will be answered with 250 OK even though it does not exist.

The standard detection: send a RCPT for a guaranteed-nonexistent address (a long random string) before the real check. If that succeeds, the domain is a catch-all and an SMTP "valid" response means nothing.

A well-behaved verifier marks catch-all domains explicitly so you can decide whether to send to them. They are not invalid — mail will arrive — but you will not know if a human reads it.

Edge case #2: greylisting

Greylisting is a spam-defense technique: the receiving server deliberately returns a temporary failure (4xx) on first contact from an unknown sender. Legitimate mail servers retry; spammers usually do not. The address may be perfectly valid but our probe gets back 451 4.7.1 Greylisted, try again later.

You cannot wait. Validation calls happen synchronously and have a budget of a few hundred milliseconds. The correct response is to return a "deferred / unknown" verdict — not "invalid" — and let the user decide whether to re-check or to ship.

Edge case #3: anti-validation defences

Larger providers — Microsoft 365 in particular, Yahoo to a lesser extent — have begun returning 250 OK to every RCPT regardless of whether the address exists. It is an explicit anti-validation measure. Their position is: you should not be able to enumerate our user base by probing.

This means SMTP RCPT validation against Microsoft-hosted domains is not reliable as a binary verdict. The address might exist or might not; the protocol tells you nothing. Good verifiers detect Microsoft-hosted recipients (by MX pattern: anything ending in protection.outlook.com) and downgrade the verdict to "risky" or "unknown" rather than reporting false confidence.

Google Workspace does the opposite — they answer truthfully — which makes Google-hosted addresses much more reliably verifiable than Microsoft-hosted ones.

Edge case #4: rate limits and IP reputation

If you check a few hundred addresses an hour from a single IP, every major receiver will start rate-limiting you, then graylisting you, then blocking you. Eventually the IP gets onto Spamhaus and your validation service becomes useless for everyone.

Production verifiers solve this with a rotating pool of IPs, throttling per destination domain, and persistent connection reuse for batches to the same MX. This is the part you cannot do well with a single Node process and a fresh socket per check — it is also why hosted email verification is a business at all.

If you are running this for yourself, the simple version: cap to 30 RCPTs per minute per destination domain, and never probe the same address twice in a 24-hour window.

What "valid" actually means

Putting it together, a "valid" verdict from a well-implemented verifier means: the syntax is correct, the domain has MX, the domain is not disposable, the local part is not generic, the remote MX accepted a RCPT for this exact address, and the domain is not a catch-all and not a known anti-validation provider.

If any of those soft failures is present, the responsible verdict is risky, not valid. A verifier that returns "valid" on a Microsoft-hosted address it cannot really verify is selling you false confidence.

Why we cap the SMTP step at 4 seconds

The 95th-percentile time for an SMTP RCPT round-trip across the public internet is around 800ms. The long tail is much worse — slow MX servers in Africa or Asia, TLS handshakes through congested links, deliberate slow-responses. We cap the SMTP step at 4 seconds and return "unknown" on timeout. That is consistent with how the other major verifiers behave, and it keeps the user-facing latency below one second for the 90% case.

Where to use this

If you are sending a one-off email, do not bother. The fastest validation is just sending it; bounces are cheap on a low-volume sender.

If you are sending cold outreach at scale, validation matters enormously: bounces above 2% will trigger rate limiting at Google and Microsoft, above 5% will get you flagged, above 10% will get you blocked. Validation is the difference between a working sending domain and a burned one.

If you are running a signup form, validation cuts your bot rate and protects future deliverability — the worst thing a sender can do is collect a year of fake addresses and then send a newsletter to all of them at once.

Spotted an error in this article? Email hello@mailcheq.com and we will fix it.