EHLO and HELO Explained: SMTP Greetings, Deliverability, and DMARC

EHLO and HELO are two small words that sit right at the start of an SMTP conversation, but they can have an outsized impact on deliverability, spam filtering, and how mailbox providers interpret the legitimacy of your mail stream.

If you have ever seen logs mentioning “HELO domain,” “EHLO string,” or “HELO does not resolve,” you are looking at this exact part of the email handshake. Most teams only notice it when something breaks: messages start landing in spam, an email gateway rejects a connection, or a DMARC project surfaces suspicious traffic in reports.

This guide explains what EHLO/HELO is, how it works, what good configuration looks like, and how to troubleshoot common issues.

What Are HELO and EHLO?

When one mail server connects to another over SMTP, it introduces itself. Historically, that introduction was HELO (the original SMTP greeting). Later, SMTP was extended with additional capabilities (called ESMTP), and the greeting became EHLO (Extended HELO).

In simple terms:

• HELO is the legacy SMTP greeting.
• EHLO is the modern greeting that tells the receiving server “I support ESMTP extensions,” and allows the receiver to advertise features like STARTTLS, AUTH, SIZE, and more.

The greeting includes a hostname (sometimes a domain). That value is often called the HELO domain or EHLO name. It is not the same as the “From” domain your users see in an email client. It is a server-to-server identifier used during connection and reputation checks.

Where EHLO/HELO Fits in the Email Journey

EHLO/HELO help to visualize the order of events in a typical SMTP delivery:

1. Sending server connects to receiving server.
2. Sending server sends EHLO (or HELO if it cannot use ESMTP).
3. Receiver responds with supported SMTP features.
4. Sender transmits the message headers and body.
5. Receiver evaluates authentication (SPF, DKIM, DMARC) and other signals.

Even though DMARC evaluates alignment using the “From” domain, many mailbox providers and security gateways use HELO/EHLO as an important signal for:

• Connection legitimacy and basic hygiene checks.
• IP reputation tracking (a stable HELO can help consistency).
• Detecting misconfigured or suspicious infrastructure.

Is EHLO/HELO Related to SPF and DMARC?

Directly, DMARC is not “based on” EHLO/HELO. DMARC evaluates alignment between the visible “From” domain and either SPF or DKIM authentication. However, HELO/EHLO can still affect your email program in a few important ways.

SPF can check the HELO identity

SPF evaluates whether a sender is authorized to send mail for a domain. The “domain” used by SPF checks is usually the MAIL FROM (Return-Path) domain, but there is also a concept called HELO identity in SPF. Some receivers consider whether the HELO/EHLO name is sensible and consistent, especially when other signals look suspicious.

If your project includes aligning SPF for DMARC (for example, during enforcement), you will likely also be cleaning up infrastructure signals at the same time. That process is covered in more depth in How to Troubleshoot and Fix DMARC Issues.

Bad HELO/EHLO can hurt deliverability even if DMARC passes

You can have SPF, DKIM, and DMARC configured correctly and still see deliverability problems if your SMTP greeting is clearly misconfigured, like:

• HELO name is localhost or an internal hostname.
• HELO name is an IP literal or a random string.
• HELO name does not resolve in DNS.
• HELO name does not match the reverse DNS pattern mailbox providers expect.

This is especially relevant for high-volume senders focused on inbox placement. If deliverability is a priority, see Improve Email Deliverability with DMARC for a broader checklist that combines authentication with sending reputation basics.

What a “Good” EHLO/HELO Configuration Looks Like

A healthy SMTP greeting is boring, consistent, and verifiable. The ideal setup typically follows these rules:

• Use a fully qualified domain name (FQDN) as the EHLO/HELO name (for example, mail.yourdomain.com or smtp.yourdomain.com).
• Make sure it resolves (A record or AAAA record exists).
• Match reverse DNS expectations (the sending IP should have a PTR record that points to a hostname, and that hostname should resolve back to the IP). Some providers are strict about forward-confirmed reverse DNS for bulk traffic.
• Keep it stable across your sending infrastructure. Frequent changes look suspicious.

If you are implementing DMARC for the first time and you are cleaning up sending infrastructure, the step-by-step DNS work is covered here: Complete DMARC Implementation Guide.

Common EHLO/HELO Problems and How to Fix Them

1) HELO is “localhost” or an internal name

This usually happens with self-managed MTAs, appliances, or legacy systems. It tells the receiver that the sender is misconfigured at best, or hiding identity at worst.

Fix: configure your MTA to use a public FQDN. For example:

• Postfix: set myhostname and confirm it is used for SMTP greetings.
• Exim: adjust primary_hostname.
• Exchange: confirm the “FQDN” on send connectors.

2) HELO domain does not resolve in DNS

Many gateways apply “HELO must resolve” checks. Even when they do not hard-reject, it can reduce trust and increase filtering.

Fix: publish an A/AAAA record for the hostname used in the greeting. Keep it simple. If you do not control DNS, this is a quick request for your DNS admins.

3) Reverse DNS (PTR) mismatch

Bulk senders often run into issues when the sending IP has no PTR record, or the PTR points to something unrelated. Some providers and spam filters treat missing or mismatched reverse DNS as a sign of low-quality infrastructure.

Fix: set a PTR record for your sending IP that points to a hostname you control (often a subdomain like mail.yourdomain.com), and ensure the hostname resolves back to the IP.

4) Shared infrastructure and third-party vendors

If you use an ESP, CRM, ticketing system, or payment provider, you may not control their SMTP greeting. That is fine. The practical goal is to make sure authentication and alignment are correct, and that the vendor is using reputable, stable infrastructure.

Fix: treat vendor onboarding as a structured process: validate SPF, DKIM, and DMARC alignment first, and then evaluate supporting signals like reverse DNS if you see deliverability issues.

5) HELO and MAIL FROM are unrelated

This is not automatically wrong. Many systems use a different hostname for SMTP greetings than the Return-Path domain. But if everything looks inconsistent, providers may treat it as suspicious, especially when combined with other problems (high complaint rates, low engagement, or authentication failures).

Fix: prioritize correctness and stability. You do not need every identifier to match, but you do want each one to look intentional and properly configured.

How to Check Your EHLO/HELO in Practice

You have a few practical options depending on how hands-on you want to be:

• Check your sending logs: most MTAs log the SMTP session, including the greeting used during outbound delivery.
• Use a test inbox and review headers: many providers include details that hint at the connecting server identity and the HELO/EHLO name.
• Telnet or openssl to your SMTP server: if you control the server, you can connect and see exactly what it announces (use STARTTLS where appropriate).

If you are in the middle of DMARC work and you are seeing repeated authentication failures, it is often helpful to solve those first, then clean up secondary signals like HELO consistency. The troubleshooting workflow is laid out in How to Troubleshoot and Fix DMARC Issues.

EHLO/HELO and Bulk Sender Requirements

Google and Yahoo have raised the baseline for bulk senders. While their published requirements focus on authentication (SPF, DKIM, DMARC) and user experience signals (complaints, unsubscribe support), real-world deliverability still depends on basic infrastructure hygiene, including consistent, reputable SMTP identity.

If you are diagnosing compliance-related delivery failures or confusing bounce messages, this guide is a useful companion: Navigating New Email Compliance: A Guide to Google and Yahoo Error Messages.

EHLO/HELO and DMARCeye

DMARCeye helps organizations understand how low-level SMTP signals like EHLO and HELO relate to real-world authentication and deliverability outcomes. While EHLO/HELO is not evaluated directly by DMARC, issues at the SMTP connection layer often surface indirectly through authentication failures, unexpected sending sources, or abnormal traffic patterns.

By analyzing DMARC aggregate reports and correlating them with sending IPs and infrastructure behavior, DMARCeye allows users to:

• Identify IP addresses and servers sending mail on behalf of your domain.
• Detect misconfigured or unexpected sending sources early.
• Correlate SPF, DKIM, and alignment failures with specific infrastructure.
• Track improvements as sending hygiene and authentication are corrected.

When EHLO/HELO configuration issues exist on owned infrastructure, they often coincide with other problems such as missing reverse DNS, unstable sending hosts, or incomplete authentication alignment. DMARCeye provides the visibility needed to prioritize fixes and validate that changes lead to measurable improvements in authentication success and deliverability.

Sign up for a free trial of DMARCeye today and secure your email domain.