Understanding the SMTP Handshake: What Happens Before a Single Message Is Sent

Every email you send begins with a conversation. Before a single character of your message is transmitted, two mail servers exchange a structured series of commands and responses — a protocol handshake that establishes identity, negotiates capabilities, and verifies that both parties are ready to exchange mail. Understanding the SMTP handshake isn't just academic: it directly explains why emails fail, what error messages mean, and how authentication fits into the delivery process.

The First Contact: The SMTP Greeting

When a sending mail server connects to a receiving server on port 25 (or 587 for client submission), the receiving server speaks first. It sends a 220 status code followed by its hostname:

220 mail.example.com ESMTP Postfix

The 220 response means "I'm ready." The sending server reads this, confirms it's talking to a live SMTP server, and proceeds. If the receiving server is unavailable or overloaded, it might return a 421 instead, telling the sender to try again later.

EHLO vs HELO

The sending server introduces itself with either HELO or EHLO, followed by its own hostname:

EHLO mail.sendingdomain.com

HELO is the older command from the original SMTP specification. EHLO (Extended HELO) is the modern version, introduced with ESMTP. The difference matters: when you send EHLO, the receiving server responds with a list of extensions it supports. When you send HELO, you get no capability list and commit to basic SMTP only.

A typical EHLO response looks like this:

250-mail.example.com Hello
250-STARTTLS
250-AUTH PLAIN LOGIN
250-SIZE 52428800
250 HELP

Each line declares a capability the server supports — STARTTLS for encrypted connections, AUTH for authentication, and SIZE indicating the maximum message size accepted.

STARTTLS: Upgrading to Encrypted

If the receiving server advertises STARTTLS support, the sending server can issue the upgrade command:

STARTTLS
220 Ready to start TLS

Both servers complete a TLS handshake, after which all further communication is encrypted. Importantly, after STARTTLS completes, the sending server typically sends EHLO again — because it needs to re-negotiate capabilities over the now-encrypted channel. Some capabilities (like AUTH) may only be advertised over TLS for security reasons.

The SMTP ports guide explains how port 465 (implicit TLS) differs from this upgrade approach.

Authentication

For client-to-server connections (your application or mail client connecting to an SMTP relay), the next step after encryption is authentication. The AUTH command tells the server who you are:

AUTH PLAIN
334
[base64-encoded credentials]
235 Authentication successful

The AUTH mechanism varies — PLAIN sends credentials directly (safe only over TLS), LOGIN uses a challenge-response exchange. The server validates your credentials and either returns 235 (success) or 535 (authentication failed).

If you're troubleshooting authentication failures, the SMTP authentication troubleshooting guide covers the most common causes and fixes.

The Envelope: MAIL FROM and RCPT TO

Once authenticated, the sending server defines the message envelope — the routing information that's separate from the email headers inside the message.

MAIL FROM:<sender@sendingdomain.com>
250 OK
RCPT TO:<recipient@example.com>
250 OK

The MAIL FROM address is the envelope sender — this is what SPF validates against. It can differ from the From: header inside the email body, which is what recipients actually see. This distinction is central to how email authentication works, and how forwarding software sometimes breaks SPF alignment.

The RCPT TO command can be issued multiple times for multiple recipients. A 550 response to RCPT TO typically means the address doesn't exist — that's a hard bounce.

DATA: Transmitting the Message

Once the envelope is accepted, the sending server issues the DATA command:

DATA
354 End data with <CR><LF>.<CR><LF>

The receiving server responds with 354, telling the sender to start transmitting. The sending server sends the full email — headers first, then a blank line, then the body. The transmission ends with a single period on its own line:

[email headers]

[email body]
.
250 Message accepted for delivery

The 250 response confirms delivery. At this point, the receiving server has accepted responsibility for the message. DKIM signatures are embedded in the email headers during this DATA phase — they're part of the message itself, not part of the SMTP envelope conversation.

QUIT

After the message is accepted, the sending server closes the session:

QUIT
221 Bye

That's the complete handshake. What looks like a simple "sending an email" involves this entire exchange every single time.

When the Handshake Fails

Most email delivery problems trace back to a specific point in this handshake. Common failure points:

• Connection refused: the receiving server isn't listening on that port, or a firewall is blocking it
• TLS handshake failure: certificate issues or unsupported cipher suites
• Authentication failure: wrong credentials or wrong AUTH mechanism
• MAIL FROM rejection: the sending domain is blocked or the IP is on a blocklist
• RCPT TO rejection: the recipient address doesn't exist or the domain isn't hosted there

The specific SMTP error codes returned at each stage tell you exactly where the failure occurred. A 4xx error is temporary; a 5xx is permanent.

If you're connecting through MailDog's SMTP relay, the documentation covers the specific connection requirements and authentication setup in full detail.