SMTP Handshake

We open millions of SMTP handshakes a day to verify email addresses, and the handshake is the part of the conversation that actually decides whether a mailbox is real. It is easy to treat SMTP as a black box that either “sends the email” or doesn’t, but the handshake is where the two servers negotiate, step by step, whether the message should proceed at all, and that negotiation is exactly what a verification check reads and stops at.

The command sequence, step by step

An SMTP handshake is a short, ordered exchange of plain-text commands, each answered with a three-digit code before the sender moves to the next line. It runs the same way whether the eventual recipient is a real inbox or a decoy:

• Connect. The sending server opens a TCP connection to the receiving server’s mail exchange, and the receiver answers first with a 220 greeting, signaling it is ready to talk.
• EHLO / HELO. The sender introduces itself by name. EHLO is the modern Extended SMTP greeting, which also asks the receiver to list the extensions it supports, like STARTTLS and authentication. HELO is the older, bare-bones version of the same introduction.
• MAIL FROM. The sender declares the envelope sender, the address a bounce notice would go to if the message fails later. The receiver typically replies 250 OK and waits for the next line.
• RCPT TO. The sender names the intended recipient. This is the single most important line in the handshake: the receiving server’s reply here states whether it will accept mail for that exact address.
• DATA (and QUIT). Only once RCPT TO has been accepted does the sender transmit headers and body, ending on a line with a single dot, then close the session with QUIT.

You can watch this exact sequence unfold, command by command, against any domain with the SMTP test tool.

What the response codes mean during the handshake

Each reply in the handshake is a three-digit code, and the first digit tells you the class of answer before you even read the rest. A 2xx code, almost always 250, means the previous command succeeded and the sender should continue. A 3xx code shows up exactly once, in reply to DATA, inviting the sender to start transmitting the message body.

The two codes that matter most for anyone reading a handshake from the outside are the failure classes. A 4xx code is a temporary failure: “this didn’t work right now, but try again.” That is the exact mechanism behind greylisting, where a server deliberately stalls an unfamiliar sender at RCPT TO to see whether it retries like a real mail server would. A 5xx code is permanent, most commonly 550, meaning the mailbox does not exist and no retry will change that, which is the usual root cause of a hard bounce.

How email verifiers exploit the handshake

The handshake has a property that makes it useful for far more than sending mail: the server reveals whether a mailbox exists at RCPT TO, a step that comes entirely before DATA, the point where a message body is actually transmitted. That ordering is the whole trick behind SMTP-based verification.

To check an address, a verifier runs the handshake up through RCPT TO and then simply stops. It connects to the domain’s mail server, greets with EHLO, issues MAIL FROM with a neutral sender address, and issues RCPT TO for the address in question. Whatever code comes back — 250 for accepted, 550 for rejected — is read as the verdict, and the session closes with QUIT instead of proceeding to DATA. No message body is ever sent, so the recipient’s mailbox never receives anything, yet the check walks away knowing whether the address is real.

That is a meaningfully different use of the protocol than sending mail. A real send needs the whole handshake to complete, including DATA. A verification probe only needs the handshake to get as far as one reply code, which is why verification can run at a scale and speed that actually sending a test message never could.

Why greylisting and catch-all behavior complicate the read

Reading a handshake correctly is harder than it looks, because two common server behaviors distort the reply to RCPT TO in opposite directions. A catch-all domain is configured to accept mail for any address at all, so it answers 250 OK even for a mailbox that was never created. A naive check reads that 250 as confirmation and reports the address as valid, when in fact the handshake never distinguished it from a typo.

Greylisting distorts the read the other way. Instead of a direct accept or reject, an unfamiliar sender gets a temporary 4xx at RCPT TO, which looks like a failure but is really the server asking for a retry it expects a real mail server to make. A check that treats every 4xx as a dead end will misreport a perfectly good address as unknown or invalid, purely because it stopped the handshake one attempt too early.

Our engine handles both cases inside the same handshake logic rather than trusting the raw code at face value: it detects catch-all behavior and runs an AI-confidence pass instead of accepting every 250, and it honors a greylist deferral with a measured re-probe instead of giving up at the first 4xx. That is the same handshake logic behind the free email checker and the verification API, so what you get back is a resolved verdict, not a misread reply code. For teams verifying at scale, the volume tiers are on the pricing page.