What is an SMTP handshake?

The sequence is fixed. Open TCP on port 25, read the server's banner, send EHLO and read the capability list, send MAIL FROM, send RCPT TO, read the decisive reply, send QUIT.

Content would come next, after a DATA command. Because the recipient decision happens before that point, there is a clean boundary where a verifier can learn the answer and leave.

Timing carries information of its own. A server that answers instantly to everything is often not checking a user database, while a measured pause before a 550 suggests a real lookup happened.

Every step can fail for reasons unrelated to the address: a connection refused, a banner that never arrives, a greeting rejected on reputation. An honest verifier distinguishes those failures from an answer about the mailbox.

Here's a plausible timeline for one verification against a responsive server. At 0 ms the TCP connection opens. By 180 ms the server's 220 banner arrives, the EHLO exchange is finished by 310 ms, and MAIL FROM gets its 250 at 420 ms. The recipient command goes out, and at 870 ms the reply comes back: 550 5.1.1. QUIT and the server's 221 close things out by 900 ms.

The longest gap came before the 550, and that's typical when the server looks the user up in a directory. Most of the rest is network round trips.

Pay attention to the first step, because impatient clients get it wrong. The client must wait for the 220 banner before it sends anything. Some servers hold that banner back for several seconds on purpose, since spam software tends to start talking at once. A client that speaks early is marked as suspect for the rest of the session, and the answers it gets are worth less.

Many servers won't discuss recipients over a plain connection. Send MAIL FROM to one of them without encrypting first and you get 530 5.7.0 Must issue a STARTTLS command first. It refuses the session as it stands and tells you nothing about any mailbox.

The longer sequence goes like this. After the first EHLO the client sends STARTTLS, the server answers 220, and the two sides negotiate TLS. Then the client sends EHLO a second time, as the standard requires, and carries on with the sender and recipient commands inside the encrypted channel. That adds a few round trips and some processing time, and the 900 ms handshake becomes something closer to 1.3 seconds.

Patience is the other variable. The SMTP standard suggests clients wait as long as five minutes for some replies. No verifier working through a large file can afford that, so each one picks a shorter timeout. When a slow server runs past it, the accurate result is unknown with a timeout reason.