What is an SMTP handshake?

An SMTP handshake is the conversation your mail server has with the receiving server before it can deliver a message. Think of it as the receiving server's bouncer checking IDs before letting your email through the door.

But Here's how it works. Your server connects to the receiving server and says hello (literally, with a command called HELO or EHLO). The receiving server responds with its name and capabilities. Then your server announces who the email is from (MAIL FROM), who it's going to (RCPT TO), and finally sends the message content (DATA). At each step, the receiving server responds with a status code that says whether to continue or stop.

Why this matters for deliverability: the handshake is where the receiving server decides whether to accept your email at all. If your sending domain doesn't have proper authentication (no SPF, no DKIM), or if your server's IP is blocklisted, or if your HELO hostname doesn't match your reverse DNS, the handshake fails. The receiving server rejects the message before it even looks at the content. You get back an SMTP error code (usually starting with 4xx or 5xx) that tells you what went wrong.

Here's what a successful handshake looks like in practice:

220 mail.example.com ESMTP Ready
EHLO sender.yourdomain.com
250-mail.example.com Hello sender.yourdomain.com
250-SIZE 52428800
250 STARTTLS
MAIL FROM:<sender@yourdomain.com>
250 OK
RCPT TO:<recipient@example.com>
250 Accepted
DATA
354 Enter message, end with "." on a line by itself
[message content]
.
250 Message accepted for delivery

Each 250 response means the server accepted that step. If you see a 421 (greylisting), 451 (temporary failure), 550 (permanent rejection), or 554 (policy rejection), something's wrong with your authentication, reputation, or configuration.

Common mistakes that break the handshake: mismatched HELO hostname (your server says it's server123.esp.com but your reverse DNS says something else), missing or broken SPF record, blocklisted sending IP, sending to a domain that doesn't exist (no MX records), or trying to relay through a server that doesn't allow it.

Still if you're seeing handshake failures, check your raw email headers or SMTP logs. The receiving server's response code will tell you exactly what failed. You can also test your SMTP setup manually with telnet or an SMTP testing tool to see the handshake conversation in real time.

Most ESPs (SendGrid, Postmark, Mailgun) handle the handshake automatically and show you delivery logs with the server responses. If you're running your own mail server, you're responsible for making sure your HELO hostname, reverse DNS, and authentication records are all aligned.

Next step: if you're troubleshooting handshake failures, grab your email headers and look for the SMTP response codes. Our Email Header Analyzer can parse them for you and show you where the handshake went wrong.