SMTP Validation: Technical Deep Dive

SMTP validation is the technique of verifying an email address by talking directly to its mail server — without actually sending a message. It's the single most accurate signal in any email verification pipeline. This deep dive walks through the protocol, what each SMTP response code means, and why a naive implementation fails in production.

The SMTP handshake, step by step

A full validation session looks like this (lines prefixed C: are client, S: server):

C: <opens TCP to mx1.recipient.com:25>
S: 220 mx1.recipient.com ESMTP ready
C: EHLO verifier.kaijuverifier.com
S: 250-mx1.recipient.com
S: 250-SIZE 157286400
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead
C: <TLS negotiation>
C: EHLO verifier.kaijuverifier.com
S: 250 OK
C: MAIL FROM:<probe@verifier.kaijuverifier.com>
S: 250 OK
C: RCPT TO:<target@recipient.com>
S: 250 OK                      ← address exists
C: QUIT
S: 221 Bye

We never send DATA — we just read the RCPT TO response. That response is the answer to "does this mailbox exist?".

Decoding the response codes

Detecting catch-all domains

A catch-all server replies 250 to any recipient — real or not — to avoid leaking which mailboxes exist. The standard detection probe:

1. Open SMTP to the target MX.
2. Send RCPT TO:<zzqx99notarealuser{timestamp}@domain.com>.
3. If the server answers 250 — it's catch-all. Your real target's 250 is therefore inconclusive.
4. Tag the verdict as accept-all / risky in the output.

Catch-all domains are roughly 15-20% of B2B lists. Enterprise mail systems (Exchange, Google Workspace) are common offenders.

Why naive SMTP validation fails at scale

1. Rate limiting. Gmail allows ~200 RCPT TO per IP per hour before greylisting. Run a 50k verification from one IP and you hit the wall in 10 minutes.
2. Blocklists. Persistent probing gets your IP on Spamhaus PBL or Barracuda's list. That poisons your sending reputation for weeks.
3. Reverse DNS. Servers that can't do an rDNS lookup on your IP often return 550 regardless of the target. You need a real hostname with matching PTR.
4. Greylisting. Some servers 450-defer every first attempt. Your verifier must retry with backoff (usually 3-15 min).
5. False 250s. Some providers (notably Yahoo and AOL) always say 250 at RCPT TO then 5xx-bounce the real send. You only find out when you actually mail.

What a production-grade SMTP validator looks like

• Pool of 1,000+ sending IPs with rotation per recipient domain.
• Heuristic fingerprint DB of MX servers (catch-all behaviour, Yahoo quirks, M365 throttling).
• Per-domain rate limiting and exponential back-off.
• Graceful handling of greylisting (queue + retry in 5-15 min).
• Abuse team contact setup so delisting requests are fast.
• Monitoring for blocklists on your entire IP pool.

This is why DIY rarely pays off under 50k emails/month — the infrastructure overhead eats any savings. See KaijuVerifier pricing for when outsourcing is the right call.

SMTP validation vs alternative methods

Frequently asked questions

What is SMTP validation?

Verifying an email address by opening an SMTP connection to the recipient's mail server and asking it — through the RCPT TO command — whether the mailbox exists, without sending an actual message.

Is SMTP validation legal?

Yes. You're using the protocol exactly as specified in RFC 5321. Issues arise only if you abuse volume and your IP ends up on a blocklist, which is a business consequence, not a legal one.

Can I do SMTP validation myself?

Technically yes, for small volumes (< 500/day) from a properly configured host. At scale you need IP rotation and throttling, which is why most teams outsource.

Why does the same address return different results?

Greylisting, temporary 4xx responses and IP reputation all cause non-determinism. A good verifier retries with backoff before calling a verdict.

How accurate is SMTP-based verification?

~96-98% when done correctly. The hard ceiling is catch-all domains and spam traps, which no external probe can detect.