HELO and EHLO for email

What are HELO and EHLO in email?

HELO and EHLO are SMTP commands used at the start of every mail delivery session. When a sending mail server connects to a receiving server, the first thing it does after the TCP connection is established is introduce itself with either HELO or EHLO followed by a hostname.

HELO is the original SMTP greeting command defined in early mail standards. EHLO is the extended version, introduced with ESMTP (Extended SMTP), and is the standard used by virtually all modern mail servers. EHLO allows the server to announce which SMTP extensions it supports, such as STARTTLS, authentication, and message size limits.

The hostname provided in the HELO or EHLO greeting is what the sending server claims as its own identity at the connection level.

Why the HELO/EHLO hostname matters

Receiving mail servers log and evaluate the HELO/EHLO hostname as part of their connection-level trust assessment. A hostname that looks suspicious — such as a bare word, a localhost name, an IP address in brackets, or one that does not match the sending IP's reverse DNS — can raise spam scores.

Many spam filtering systems assign a higher trust level to connections where the HELO hostname is a valid fully-qualified domain name (FQDN) that resolves in DNS and is consistent with the PTR record of the sending IP.

A problematic HELO hostname does not typically cause outright rejection on its own, but it compounds with other negative signals and can contribute to spam placement — especially on servers that are not yet trusted.

HELO vs EHLO: what is the difference?

HELO is defined in the original SMTP specification. It initiates a basic SMTP session without support for extensions.

EHLO is defined in the ESMTP specification and initiates an extended session. The receiving server responds with a list of extensions it supports — such as STARTTLS for encrypted transport, AUTH for authentication, and SIZE for message size negotiation.

Modern mail servers normally attempt EHLO first and fall back to HELO only if the receiving server does not support ESMTP. In practice, virtually all servers support EHLO. Seeing HELO in server logs today usually indicates a very old or misconfigured sending server.

From a deliverability perspective, the key point is the same for both commands: the hostname provided should be a valid, meaningful FQDN.

HELO hostname, PTR, and reverse DNS alignment

The strongest SMTP greeting configuration aligns three things:

The PTR record for the sending IP resolves to a meaningful hostname. That hostname forward-resolves back to the same IP (forward-confirmed reverse DNS). The HELO/EHLO hostname matches the PTR hostname.

When all three agree, the receiving server can verify a consistent identity: the IP claims to be a particular hostname, reverse DNS confirms it, and forward DNS confirms the hostname.

A mismatch — for example, announcing a hostname in HELO that differs from what the PTR record returns — creates an inconsistency that many spam filters treat as a negative signal. The mismatch does not prove malicious intent, but it suggests the server was not carefully configured, which correlates with spam sources.

HELO, SPF, DKIM, and DMARC

The HELO/EHLO hostname operates at the connection level, before message content is transmitted. It is evaluated separately from the message-level authentication standards.

SPF can be checked against both the HELO identity (HELO SPF check) and the MAIL FROM domain (envelope SPF check). In practice, the MAIL FROM SPF check is the one that counts for DMARC alignment, but some receivers also check HELO SPF.

DKIM and DMARC are entirely message-level and do not interact with the HELO hostname directly.

A well-configured sending server should have correct HELO/EHLO alignment at the connection level and valid SPF, DKIM, and DMARC at the message level. Neither layer substitutes for the other.

Common HELO/EHLO configuration mistakes

Using localhost or localdomain. Mail servers that announce "localhost", "localhost.localdomain", or similar in HELO are using the default hostname of the server rather than a proper mail identity.

Using a bare hostname without a domain. A hostname like "mailserver" without a domain component is not a valid FQDN and will be treated with suspicion.

Using the sending domain as the HELO hostname. A common mistake is to use the From-address domain (e.g. "example.com") as the HELO hostname. The HELO hostname should identify the mail server, not the sender's domain — and it should match the PTR of the sending IP.

HELO does not match PTR. The hostname announced in HELO differs from what the sending IP's PTR record returns. This inconsistency is flagged by many spam filters.

HELO hostname does not resolve. The HELO hostname cannot be looked up in DNS, meaning it either does not exist or is an internal name not visible to the public internet.

How to fix HELO/EHLO hostname problems

Choose a proper mail server hostname. The hostname should be a valid FQDN that clearly identifies the mail server — for example, "mail.yourdomain.com". It should not be a bare word, a localhost name, or the sending domain itself.

Set the hostname in your mail server configuration. For Postfix, this is the myhostname directive. For Exim, the primary_hostname setting. Other mail servers have equivalent configuration options.

Set a matching PTR record. Contact your hosting or VPS provider to set the PTR record for your sending IP to the same hostname. This ensures HELO and reverse DNS are consistent.

Add a forward DNS record. Create an A or AAAA record for the mail server hostname pointing to the sending IP, completing the forward-confirmed reverse DNS chain.

Verify the full configuration. After changes propagate, confirm that the HELO hostname matches the PTR, the PTR hostname forward-resolves to the sending IP, and SMTP TLS is correctly configured.

How to test HELO/EHLO and related signals

The most direct way to inspect HELO/EHLO behaviour is to connect to your mail server on port 25 using a tool like Telnet or OpenSSL and observe the EHLO exchange directly.

SMTP TLS checkers — including the MXFend SMTP TLS Checker — connect to your mail server, perform the full SMTP handshake, and surface the hostname announced in EHLO alongside TLS certificate details and STARTTLS support.

Blacklist checkers test whether your sending IP is listed on major DNSBLs — a common consequence of sustained HELO misconfiguration combined with other delivery problems.

A full MXFend Email Security Score audit covers SMTP TLS, blacklist status, and authentication records in a single report.

How MXFend can help

SMTP TLS Checker — connects to your mail server and shows the EHLO hostname alongside STARTTLS support, TLS certificate validity, and cipher details. The most direct tool for inspecting connection-level server identity.

Blacklist Checker — tests your sending IP against major DNS blacklists. HELO misconfiguration contributes to IP-level spam signals over time.

Email Security Score — combines SMTP TLS, blacklist, SPF, DKIM, DMARC, MX, BIMI, MTA-STS, and TLS-RPT into a single weighted audit.

SPF, DKIM, and DMARC Checkers — verify the message-level authentication records that work alongside correct HELO configuration to establish a complete and trusted sending identity.