DEV Community: Petr Michal

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

Petr Michal — Fri, 07 Aug 2026 07:44:23 +0000

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

or:

EHLO server1.internal

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

The sending server then identifies itself:

EHLO mail.sender.example

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

It should not be:

localhost
server1
mail.local
127.0.0.1

A strong configuration creates a consistent identity chain:

Sending IP
    ↓ PTR
mail.example.com
    ↓ A or AAAA
Same sending IP
    ↓ EHLO
mail.example.com

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

Its PTR record returns:

mail.example.com

But the SMTP session announces:

EHLO host123.provider.example

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

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.

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

Example commands

Check reverse DNS:

dig -x 203.0.113.20 +short

Check forward DNS:

dig mail.example.com A +short

Inspect an SMTP greeting:

openssl s_client -starttls smtp -connect mail.example.com:25

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.

Why SPF Breaks After Adding One More Email Provider

Petr Michal — Mon, 27 Jul 2026 07:43:47 +0000

Why SPF Breaks After Adding One More Email Provider

Your SPF record may look valid and still produce a PermError.

This often happens after connecting one more service:

Google Workspace
Microsoft 365
Mailchimp
Zendesk
a CRM
a support platform

Each include: can trigger additional DNS lookups. SPF allows no more than 10 DNS-triggering mechanisms during one evaluation.

A simple-looking record

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com -all

The record contains only three include: mechanisms, but each included record may contain more:

include
redirect
a
mx
exists

The limit applies to the complete evaluation tree, not only to the mechanisms visible in the root record.

What happens after the limit is exceeded

The receiving mail server may return an SPF PermError.

That does not necessarily mean every message will be rejected. The final outcome depends on:

the receiving provider,
whether DKIM passes,
whether SPF or DKIM aligns with DMARC,
the receiver's local spam-filtering rules.

This is why the problem can appear inconsistent:

one provider accepts the message,
another sends it to spam,
another reports an authentication failure.

How to diagnose it

Expand every include: recursively.
Count all DNS-triggering mechanisms in the full tree.
Identify senders and providers that are no longer used.
Check whether multiple services authorize the same infrastructure.
Look for nested includes that consume more lookups than expected.
Avoid blindly flattening records without understanding how the provider updates its IP ranges.

Common mistakes

Counting only visible includes

Three visible include: mechanisms do not necessarily mean three DNS lookups.

An included record may trigger several additional lookups of its own.

Adding a second SPF record

A domain should publish a single SPF policy.

Adding another TXT record beginning with v=spf1 does not extend the existing policy. Multiple SPF records can instead cause a PermError.

Flattening and forgetting

Flattening can reduce DNS lookups by replacing includes with IP addresses, but it also creates a maintenance obligation.

If the provider changes its sending infrastructure and the flattened record is not updated, legitimate mail may stop passing SPF.

A safer way to fix it

Start by mapping the complete lookup tree.

Then:

remove obsolete providers,
remove duplicate authorization paths,
simplify unnecessary mechanisms,
confirm which systems still send mail for the domain,
flatten only where you understand the update and monitoring strategy.

The goal is not only to get below 10 lookups today. The SPF policy should remain correct when providers change their infrastructure.

Test the full lookup tree

I built a free SPF lookup visualizer for this type of diagnosis:

Open the MXFend SPF Lookup Visualizer

It expands the recursive lookup tree and helps show where the SPF lookup budget is being consumed.

You can also browse more SPF guides in the
MXFend SPF knowledge base.

Disclosure: I built MXFend. The visualizer is free to use and does not require an account.

DEV Community: Petr Michal

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

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

What HELO and EHLO actually do

What a valid EHLO hostname should look like

Why PTR and EHLO should agree

Common HELO and EHLO mistakes

Using localhost

Using an internal hostname

Missing forward DNS

Using the wrong identity on a multi-IP server

Assuming the From domain must match

How to check your configuration

Example commands

HELO is not a replacement for email authentication

Read the complete guide

Why SPF Breaks After Adding One More Email Provider

Why SPF Breaks After Adding One More Email Provider

A simple-looking record

What happens after the limit is exceeded

How to diagnose it

Common mistakes

Counting only visible includes

Adding a second SPF record

Flattening and forgetting

A safer way to fix it

Test the full lookup tree

Using `localhost`