DEV Community

Cover image for HELO vs EHLO: Why Your SMTP Greeting Can Hurt Email Delivery
Petr Michal
Petr Michal

Posted on • Originally published at mxfend.com

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

#email #security #dns #devops

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

Your SPF, DKIM, and DMARC records may all look correct while your mail server still introduces itself as:

EHLO localhost
Enter fullscreen mode Exit fullscreen mode

or:

EHLO server1.internal
Enter fullscreen mode Exit fullscreen mode

That greeting happens before the message body is transmitted and can become one of the first identity signals a receiving server evaluates.

What HELO and EHLO actually do

When one mail server connects to another, the receiving server first sends an SMTP banner:

220 mx.receiver.example ESMTP
Enter fullscreen mode Exit fullscreen mode

The sending server then identifies itself:

EHLO mail.sender.example
Enter fullscreen mode Exit fullscreen mode

HELO is the older SMTP greeting.

EHLO is the modern Extended SMTP greeting. It also allows the receiving server to advertise capabilities such as:

  • STARTTLS
  • SIZE
  • 8BITMIME
  • PIPELINING
  • DSN

Modern mail servers normally try EHLO first and fall back to HELO only when necessary.

What a valid EHLO hostname should look like

A good EHLO identity is normally a publicly resolvable fully qualified domain name:

mail.example.com
Enter fullscreen mode Exit fullscreen mode

It should not be:

localhost
server1
mail.local
127.0.0.1
Enter fullscreen mode Exit fullscreen mode

A strong configuration creates a consistent identity chain:

Sending IP
    ↓ PTR
mail.example.com
    ↓ A or AAAA
Same sending IP
    ↓ EHLO
mail.example.com
Enter fullscreen mode Exit fullscreen mode

This is commonly described as forward-confirmed reverse DNS.

Why PTR and EHLO should agree

Suppose the sending connection comes from:

203.0.113.20
Enter fullscreen mode Exit fullscreen mode

Its PTR record returns:

mail.example.com
Enter fullscreen mode Exit fullscreen mode

But the SMTP session announces:

EHLO host123.provider.example
Enter fullscreen mode Exit fullscreen mode

The server may still deliver mail, but the identity is inconsistent.

Receiving systems can combine that inconsistency with other signals:

  • IP reputation
  • blocklist status
  • SPF, DKIM, and DMARC results
  • TLS configuration
  • complaint history
  • sending patterns

A HELO mismatch is rarely the only reason a message lands in spam, but it can make an already marginal sender look less trustworthy.

Common HELO and EHLO mistakes

Using localhost

This often happens after installing Postfix, Exim, or another MTA without setting the public hostname.

Using an internal hostname

Names such as mail.internal or server1.lan cannot be verified through public DNS.

Missing forward DNS

The PTR points to mail.example.com, but that hostname does not resolve back to the sending IP.

Using the wrong identity on a multi-IP server

A server sends from several IP addresses but announces the same hostname for all of them, even though each IP has a different PTR record.

Assuming the From domain must match

The EHLO hostname does not necessarily need to equal the visible From domain.

For example, this can be valid:

EHLO mail.example.net
From: billing@example.com
Enter fullscreen mode Exit fullscreen mode

What matters most at this layer is that the server identity is valid, resolvable, and consistent with the sending infrastructure.

How to check your configuration

Start with the actual outbound IP address, not only the domain used in the From header.

  1. Find the IP used for outbound SMTP.
  2. Resolve its PTR record.
  3. Resolve the returned hostname back to an IP.
  4. Inspect the EHLO value used by the sending server.
  5. Verify that the complete identity chain is consistent.
  6. Check STARTTLS and the server certificate.
  7. Then verify SPF, DKIM, and DMARC separately.

Example commands

Check reverse DNS:

dig -x 203.0.113.20 +short
Enter fullscreen mode Exit fullscreen mode

Check forward DNS:

dig mail.example.com A +short
Enter fullscreen mode Exit fullscreen mode

Inspect an SMTP greeting:

openssl s_client -starttls smtp -connect mail.example.com:25
Enter fullscreen mode Exit fullscreen mode

The exact tests available depend on whether the remote server accepts connections from your network and whether port 25 is blocked.

HELO is not a replacement for email authentication

A correct EHLO identity does not replace:

  • SPF
  • DKIM
  • DMARC

These mechanisms work at different layers.

HELO/EHLO and PTR describe the connecting server.

SPF, DKIM, and DMARC authenticate domains and messages.

For reliable delivery, both layers should be configured correctly.

Read the complete guide

The original guide includes more context about HELO, EHLO, DNS identity, and common configuration mistakes:

Read the complete HELO and EHLO guide on MXFend

You can also use the MXFend SMTP TLS Checker to inspect STARTTLS and related mail-server configuration.

Disclosure: I built MXFend. The diagnostic tools are free to use and do not require an account.

Top comments (0)