- EHLO, defined
- EHLO is the SMTP greeting a connecting server sends to identify itself and ask what extensions the receiving server supports, replacing the older HELO command.
The command is EHLO mail.yourdomain.com. The receiving server answers with a multi-line reply listing what it can do: STARTTLS, SIZE limits, PIPELINING, 8BITMIME, sometimes AUTH.
That capability list is why the extended form exists. The original HELO had no way to advertise anything, so every later feature needed a handshake that could negotiate.
The hostname you announce is your first reputation signal. A generic name, a bare IP literal, or a name whose reverse DNS points elsewhere all raise the spam score before a recipient has been named.
Falling back to HELO still works with ancient servers. In practice almost nothing needs it, and a receiver that rejects EHLO is old enough to have other problems.
How ZapBounce reports it
Our probes announce a resolving hostname with matching forward and reverse DNS, because a sloppy greeting gets the connection dropped and turns a perfectly good address into an unknown. That plumbing is part of why probe quality tracks infrastructure quality.
A greeting and its reply, line by line
Here's a typical exchange with a hypothetical server. You send EHLO probe.sender.example. It answers with 250-mx1.example.com Hello, then 250-SIZE 52428800, 250-8BITMIME, 250-STARTTLS, 250-ENHANCEDSTATUSCODES and finally 250 SMTPUTF8, the last line marked by a space after the code where the others have a hyphen.
You can read a few things off that list. SIZE says the server takes messages up to 50 MB. STARTTLS says encryption is on offer. SMTPUTF8 says it will handle addresses containing non-Latin characters, and you shouldn't offer it one if the keyword is missing.
One detail trips up hand-written clients. After STARTTLS succeeds, you have to send EHLO again, because the standard tells both sides to forget everything learned before encryption started. The second capability list is often different. AUTH, for instance, commonly shows up only once the channel is encrypted, so that passwords never cross in the clear.
Checking the name your own server announces
Send a message from your server to any mailbox you control and read the top Received header. It records the name your server gave in its greeting next to the IP the connection came from. If that name is localhost, or an internal one like EXCH01.corp.local, every receiver you've ever mailed has seen it.
Then test the pairing. Run dig -x on your sending IP to get its reverse name, and look that name up to see whether it returns the same IP. The greeting name should match. On a cloud server the reverse record is set in the hosting provider's console, not in your own DNS zone, which is why it so often gets missed.
The mail standard says a receiver shouldn't refuse a message purely because the greeting name fails to check out. Plenty of real servers score it heavily or refuse anyway, so don't rely on that sentence to protect you.
EHLO: common questions
What is the difference between EHLO and HELO?
EHLO asks for the server's extension list and enables everything modern. HELO is the original greeting with no negotiation.
What hostname should EHLO announce?
A fully qualified name that resolves to the connecting IP, with reverse DNS pointing back to it. Mismatches are treated as a spam signal.
Why does the reply have several lines?
Each line advertises one capability. A hyphen after the code means more lines follow; a space marks the last one.