What is SMTP verification?
SMTP verification confirms whether an email mailbox exists by opening a connection to the recipient's mail server and starting — but never completing — a message delivery. The server's response reveals whether it would accept mail for that address.
The SMTP handshake, step by step
The verifier looks up the domain's MX records to find the mail server, opens a connection, and issues the same commands a real sender would: HELO/EHLO to introduce itself, MAIL FROM to declare a sender, and RCPT TO with the address being checked. At the RCPT TO step the server either accepts (250) or rejects (550) the recipient.
Crucially, the verifier stops there. It never sends DATA, so no email is actually delivered. The recipient sees nothing; the check only reads the accept/reject signal from the handshake. Stopping short of delivery like this is what the industry informally calls an email ping.
What SMTP verification can and can't tell you
On a well-behaved domain, a 550 at RCPT TO is a reliable signal that the mailbox doesn't exist. This catches the largest category of bad addresses — typos and abandoned accounts — before they bounce.
It has limits. Catch-all domains accept everything, so a 250 doesn't prove the mailbox exists. Some servers use greylisting (temporary deferral) or deliberately accept-then-bounce to frustrate probing. Robust verification therefore combines SMTP with syntax, MX, disposable, and reputation checks rather than relying on the handshake alone.
Doing it safely at scale
Running SMTP probes from your own servers risks getting your IPs blocklisted, because mail providers treat repeated RCPT TO probing as abusive. A verification API distributes probes across reputable IPs, respects rate limits and backoff, and handles greylisting retries for you.
Mailbeam runs the SMTP check in parallel with its other checks and returns a structured result, including a distinct flag for servers that block probing, so you can tell 'mailbox rejected' apart from 'couldn't determine'.
A verification probe, in full
The whole technique is one SMTP conversation that stops before the message body. Nothing is ever sent.
<- 220 mx.example.com ESMTP
-> EHLO prober.invalid
<- 250-mx.example.com
<- 250 SIZE 35882577
-> MAIL FROM:<probe@prober.invalid>
<- 250 2.1.0 Ok
-> RCPT TO:<jdoe@example.com>
<- 550 5.1.1 User unknown <- the answer we came for
-> QUIT
<- 221 2.0.0 Bye
The session ends at QUIT. DATA is never issued, so no
message is transmitted and nothing arrives in any inbox.SMTP verification ends at QUIT without ever issuing DATA, so the recipient's server is asked about the mailbox but no message is transmitted.
Sources
Checked against these sources on .
In practice
Verifying sam@example.com, Mailbeam connects to example.com's MX server and issues RCPT TO: sam@example.com. The server replies 550 5.1.1 user unknown — the mailbox doesn't exist — so Mailbeam returns valid: false with reason: mailbox_not_found, all without sending an actual email.
Frequently asked questions
Does SMTP verification send an email?
No. It opens the SMTP conversation and reads the server's response to the RCPT TO command, then disconnects before the DATA step. No message is delivered and the recipient is never notified.
Is SMTP verification accurate?
It's highly accurate for ordinary domains that reject unknown recipients. It's inconclusive for catch-all domains and servers that block probing, which is why it should be combined with other checks.
Can SMTP probing hurt my sender reputation?
If you probe at volume from your own IPs, yes — providers may blocklist you. Using a verification API that spreads probes across managed IPs avoids this.
Verify emails with confidence
Mailbeam handles all of this for you — syntax, MX, SMTP, catch-all, and disposable checks in one API call. 1,000 free verifications/month, no credit card.