Infrastructure

HELO / EHLO

Definition

HELO and EHLO are the opening commands of every SMTP conversation: the sending server uses them to introduce itself with a hostname before any mail is exchanged. EHLO (Extended HELO) is the modern form, defined in RFC 5321, that asks the receiver to list the extensions it supports, such as STARTTLS and AUTH. The plain HELO is the legacy fallback.

  • The first command a sending server issues to identify itself in an SMTP session
  • EHLO returns a multi-line list of extensions; HELO returns a single plain line
  • EHLO is what advertises STARTTLS, AUTH, SIZE, and other capabilities
  • The greeting hostname should be an FQDN that matches your reverse DNS
At a glance
Command type SMTP greeting
Modern form EHLO (Extended HELO)
Legacy form HELO
Defined in RFC 5321 (2008)
Success reply 250
Should be A resolvable FQDN

How the greeting works

Every SMTP delivery opens with a handshake. After the receiving server answers a new connection with a 220 banner, the sending server has to identify itself before it can do anything else. That identification is the HELO or EHLO command, followed by the sender’s own hostname, for example EHLO mail.example.com.

The two commands differ in what comes back. A plain HELO, from the original 1982 SMTP specification, just gets a one-line 250 acknowledgement. An EHLO, introduced with Extended SMTP, gets a multi-line 250 response in which the receiver advertises every extension it supports. Modern clients always try EHLO first and fall back to HELO only if the server does not understand it.

What an EHLO exchange looks like

The receiver answers EHLO with one 250 line per capability. This is how a sender discovers that it can, for instance, upgrade to encryption with STARTTLS or authenticate with AUTH:

A client EHLO and the multi-line capability list the server returns 
C: EHLO mail.example.com
S: 250-mx.receiver.net at your service
S: 250-SIZE 35882577
S: 250-8BITMIME
S: 250-STARTTLS
S: 250-ENHANCEDSTATUSCODES
S: 250 SMTPUTF8

Why the HELO hostname matters for deliverability

The hostname you announce in the greeting is more than a formality; receivers inspect it as a basic trust signal. Best practice is to use a fully qualified domain name that resolves in DNS and matches the PTR record of your sending IP, the same match that underpins forward-confirmed reverse DNS. A greeting of localhost, an internal name, a bare IP literal, or a random string is a classic spam signal.

You can have SPF, DKIM, and DMARC all configured perfectly and still get filtered if the HELO name is obviously wrong. The greeting also matters for SPF’s lesser-known helo identity, which some receivers check alongside the Return-Path. Confirm your sending IP’s reverse record with the reverse DNS checker.

Where HELO/EHLO sits in an SMTP session

The sender opens a connection and the receiver answers with a 220 banner
The sender introduces itself with EHLO mail.example.com
The receiver replies with a multi-line 250 capability list
STARTTLS offered AUTH offered SIZE limit given
The sender uses the advertised extensions, then sends MAIL FROM and the message
A resolvable, matching greeting hostname helps the message pass basic checks

HELO vs EHLO

HELO EHLO
Era Original SMTP (1982) Extended SMTP (ESMTP)
Reply Single 250 line Multi-line 250 list
Advertises extensions? No Yes
Unlocks STARTTLS / AUTH? No Yes
Used today as Legacy fallback The default greeting

By the numbers

250
The SMTP reply code for a successful greeting; EHLO returns one 250 line per supported extension.
FQDN
What the greeting hostname should be: a fully qualified name that resolves and matches your reverse DNS.

Common mistakes

Greeting with localhost or an IP literal
A greeting of localhost, an internal hostname, or a bare bracketed IP is a textbook spam signal. Configure your MTA to announce a real fully qualified domain name.
A HELO name that does not match reverse DNS
When the greeting hostname and the sending IP’s PTR record point in different directions, forward-confirmed reverse DNS fails and many receivers downgrade or refuse the mail. Keep the greeting, the A record, and the PTR record aligned.
Forcing HELO instead of EHLO
Falling back to plain HELO when the server supports EHLO means losing STARTTLS and AUTH, so the session stays unencrypted and unauthenticated. Always attempt EHLO first.

Frequently asked questions

What is the difference between HELO and EHLO?
HELO is the original SMTP greeting and returns a single acknowledgement line. EHLO is the Extended SMTP version: it asks the receiver to list the extensions it supports, returning a multi-line response that can include STARTTLS for encryption, AUTH for authentication, SIZE, and more. Modern servers send EHLO first and only fall back to HELO if EHLO is not understood.
What hostname should my server use in HELO/EHLO?
A fully qualified domain name that resolves in DNS and matches the PTR (reverse DNS) record of the IP you send from. Avoid localhost, internal names, bare IP literals, and random strings, since receivers treat those as spam signals. A consistent, resolvable greeting hostname is part of passing forward-confirmed reverse DNS.
Does the HELO/EHLO hostname affect deliverability?
Yes. Receivers use it as a basic identity check. A greeting hostname that does not resolve, or that conflicts with your reverse DNS, can push otherwise legitimate mail toward the spam folder even when SPF, DKIM, and DMARC all pass. It is one of the quieter reasons mail is filtered.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← Back to glossary