HELO vs EHLO: Why Your SMTP Greeting Can Hurt Email Delivery

The way your mail server greets incoming SMTP connections can significantly impact email delivery. Specifically, the greetings using HELO and EHLO commands might be causing issues. These greetings occur before any message body is sent and are one of the first signals a receiving server assesses when deciding to deliver or reject mail.

HELO and EHLO serve different purposes in the Simple Mail Transfer Protocol (SMTP). The older HELO greeting is being replaced by the more modern EHLO or "Extended SMTP" greeting. EHLO not only identifies the sending server but also allows the receiving server to advertise capabilities like STARTTLS (for secure email transmission), SIZE (indicating maximum message size), PIPELINING (batch processing of commands), and DSN (delivery status notifications).

Modern mail servers typically attempt EHLO before resorting to HELO if necessary. So, what should appear in an EHLO hostname? Ideally, it should be a fully qualified domain name (FQDN) that can be publicly resolved, such as "mail.example.com". It should not be something like "localhost", "server1", "mail.local", or "127.0.0.1".

A strong configuration should create a seamless identity chain. The sending IP address should have a valid PTR record pointing to the FQDN, and that same FQDN should be the one announced in the EHLO greeting. This is often referred to as "forward-confirmed reverse DNS". If the PTR record points to something like "mail.example.com", but the EHLO greeting mentions "host123.provider.example", inconsistencies can occur. While the mail might still be delivered, the identity mismatch can raise red flags for receiving servers.

Receiving servers often combine these identity inconsistencies with other signals such as IP reputation, blocklists, SPF, DKIM, DMARC results, TLS configuration, complaint history, and sending patterns. Even if a HELO/EHLO mismatch isn't the sole reason for a message being marked as spam, it can make a sender appear less trustworthy. Common mistakes include using "localhost", internal hostnames, missing forward DNS resolution, or using the same hostname for all IP addresses when a server handles multiple IPs.

The EHLO hostname doesn't necessarily need to match the visible "From" domain. For example, you might use "EHLO mail.example.net" while sending emails from "billing@example.com". The key is that the server's identity should be valid, resolvable, and consistent with your sending infrastructure. To verify your configuration, start with your actual outbound IP address, not just the domain in the "From" header.

Resolve the IP's PTR record and ensure it points back to the correct IP. Then, check the EHLO value announced by your server. It should be consistent with the complete identity chain. Finally, verify your email authentication mechanisms like SPF, DKIM, and DMARC separately. Make sure the reverse DNS, forward DNS, and SMTP greetings all match.

Also, check your STARTTLS setup and verify your SPF, DKIM, and DMARC records. Use commands like "dig -x <IP>" to check reverse DNS, "dig <email domain> A" for forward DNS, and "openssl s_client -starttls smtp -connect <email domain>:25" to inspect the SMTP greeting. Keep in mind that while a correct EHLO identity is important, it doesn't replace email authentication mechanisms such as SPF, DKIM, and DMARC.

All should be configured correctly for reliable email delivery. For a more comprehensive guide, including common mistakes and diagnostic tools, refer to the full guide available on MXFend.