Why Your HELO/EHLO Domain Matters for Email Deliverability

Alex SerkinPublished: September 15, 2025Updated: November 4, 2026

When it comes to email authentication, most senders focus on SPF, DKIM, and DMARC. While these are crucial, there's another technical detail that often goes unnoticed: the HELO/EHLO domain in your SMTP handshake.

Key Takeaways

EHLO identifies the connecting SMTP client; the receiving server responds with its supported extensions.
Check the sending hostname and its DNS records. It does not have to match the visible From domain.
Review SPF, DKIM, DMARC, and actual inbox placement as separate checks.

What Is HELO/EHLO?

HELO (or its modern version, EHLO) is the greeting an SMTP client sends after connecting to another mail server. The command includes a name for the sending host. It's essentially your server introducing itself:

EHLO mail.example.com

Think of it like a caller ID for email.

RFC 5321 defines the HELO and EHLO commands.
EHLO starts an Extended SMTP (ESMTP) session. The receiving server's response lists the extensions it supports.

Reading an EHLO Response

Here is a short SMTP exchange. S is the receiving server; C is the sending client. These names are examples, not settings to copy:

A short SMTP exchange

Receiving server (S) → sending client (C)
```
S: 220 mx.example.org ESMTP ready
```
Sending client (C) → receiving server (S)
```
C: EHLO outbound.example.net
```

Receiving server (S) → sending client (C)

S: 250-mx.example.org
S: 250-SIZE 52428800
S: 250 STARTTLS

The first reply names the receiver. The EHLO command names the sender. The 250- lines continue the response; the final 250 followed by a space ends it, as defined in RFC 5321.

The reply lists supported features: SIZE advertises a message-size limit, while STARTTLS offers the option to negotiate TLS. That offer does not mean encryption is already active, and different servers can advertise different features.

A 250 here means the greeting succeeded. It is a good start, not an inbox invitation and the later delivery result still matters.

After a successful STARTTLS negotiation, the client should send EHLO again because the available capabilities can change. Seeing the greeting twice can be expected.

Why Alignment Matters

Mailbox providers can examine HELO/EHLO information during delivery. What matters here is whether the hostname accurately represents the sending server and fits its DNS configuration. It does not generally need to match the visible From domain.

Authentication & Transparency
- RFC 5321 calls for a primary host name when possible and allows an address literal when the client has no suitable name.
- The EHLO hostname identifies the connecting server; the From domain identifies the apparent author of the message.
Anti-Spam & Anti-Phishing
- A malformed or misleading hostname can complicate a receiver's checks.
- Microsoft recommends configuring HELO/EHLO to match the sending IP's reverse DNS (PTR) entry.
Reputation Tracking
- Some domain blocklists can check the HELO/EHLO name. Spamhaus documents this use for its Domain Blocklist.
- Check the hostname and sending IP on their own merits instead of treating a different From domain as a reputation failure.
Best Practices & Standards
- Use a stable, resolvable hostname that accurately represents the sending host, and check the IP's PTR and forward DNS records.
- DMARC alignment is a separate check: a passing SPF MAIL FROM identity or DKIM signing domain must align with the visible From domain.

EHLO and From: Two Different Identities

If your From domain is:

From: [email protected]

Your own sending server might introduce itself as:

EHLO mail.example.com

This is one possible setup, not a required match to From. If an email service provider sends for you, it may use a hostname under its own domain. Check the outbound IP, its PTR record, and whether the named host resolves back to that IP. Our guide to forward-confirmed reverse DNS explains the DNS check.

After changing a server or provider, test inbox placement and review authentication separately. You can also check your SPF record and check domain blacklist status. A blacklist lookup does not test the EHLO hostname.

How to Check the EHLO Name Your Sending Service Uses

Before changing anything, check which domain name your sending service actually announces. A receiving server's banner describes that server. A greeting you type into a manual test describes your test client. For this check, you need the outgoing connection used by your real sending service.

Ask your administrator or provider's support team for an SMTP transcript or diagnostic log from an actual outbound delivery. It needs to record the EHLO name and outbound IP; not every log includes SMTP commands.
Check the sending IP's PTR hostname and its A or AAAA records. Then, have the provider compare those results with the EHLO name in the transcript.
If a discrepancy needs fixing, ask the team responsible for that sending configuration to review it. Then retest the same sending route.

Changing a website DNS record does not automatically change a provider's greeting or reverse DNS. Keep the check tied to the service that sent the message.

What did your EHLO check actually tell you?

EHLO differs from the visible From address: That difference alone does not establish a problem. Review authentication separately.
EHLO and reverse DNS use different hostnames: Ask the provider or administrator to review the sending setup. Also check that the PTR hostname resolves back to the sending IP.
The reply to EHLO is 250: The greeting succeeded. Follow the subsequent delivery result.

These are independent observations; more than one can apply to the same delivery. A successful greeting is not proof of inbox placement. Microsoft recommends hostname and reverse-DNS consistency, and Google's sending-IP guidance explains the PTR and forward-DNS check.

For the wider picture, see how DNS supports email routing and authentication.

Need Help Checking Deliverability?

The SMTP hostname is one part of the sending picture. EmailConsul helps you review inbox placement, authentication, and IP and domain reputation signals. Explore the tools in a trial, or book a demo to discuss your sending setup.

Book a Demo

Final Thoughts

Deliverability is about trust. A clear HELO/EHLO identity and correctly configured DNS give receiving servers useful information about your sending host. Keep those checks separate from authentication of the From domain, and review the actual delivery result before deciding what to change.

At EmailConsul, we help senders review authentication, IP and domain reputation, and inbox placement together.