[ Headers & delivery errors ]

SMTP HELO and EHLO names: distinguish identification from authentication

Use HELO and EHLO as SMTP identification and capability signals, then evaluate authentication and policy separately.

By the EmailAuth research team · 3 min read

[ Key points ]

  • Greeting names and advertised capabilities are not proof of domain ownership or relay permission.
On this page
  1. Interpret the greeting
  2. Distinguish consistency checks from authentication
  3. Read a hypothetical greeting exchange
  4. Troubleshoot the exact rejection
  5. Choose the next check from the reply

The name after EHLO is a client-supplied SMTP identity, not proof that the client owns a domain or is authorized to send the visible message. EHLO also asks the server to advertise extensions. A useful investigation separates that greeting name, the connecting IP, the envelope sender and the message's visible From domain. Confusing them can produce both false alarms and ineffective fixes.

Interpret the greeting

RFC 5321 describes the client greeting and the domain or address-literal forms used to identify the client. EHLO requests extended SMTP behavior; HELO is the basic greeting. A server's EHLO response can advertise supported extensions, but support and permission are distinct. For example, advertising a capability does not mean an unauthenticated client may relay mail to every recipient.

The client should provide the appropriate fully qualified domain name when available, with an address literal used in the circumstances defined by the protocol. A generic workstation label or an unrelated domain can cause interoperability or policy trouble. Review the actual server's requirements rather than assuming every deployment enforces the same checks. RFC 5321 sections 4.1.1.1 and 4.1.4.

Distinguish consistency checks from authentication

An operator may compare the greeting with forward or reverse DNS, but such a comparison is a separate signal and must follow protocol and local policy constraints. RFC 5321 says a server may verify whether the EHLO name corresponds to the client's IP, but must not refuse a message solely because that verification fails. Do not turn a common anti-abuse heuristic into a universal SMTP requirement.

SPF can evaluate a HELO identity as described by RFC 7208. That result is not interchangeable with evaluation of a nonempty MAIL FROM identity. For a null reverse path, the SPF procedure uses a constructed identity based on HELO. Preserve which identity was checked instead of displaying one unlabeled SPF result.

Read a hypothetical greeting exchange

Suppose a server sends 220, the client sends EHLO client.example, and the server replies with 250 continuation lines followed by a final 250 line advertising its available extensions. This illustrates greeting and capability discovery, not proof of DNS resolution, client ownership or permission to relay.

Now suppose RCPT TO later returns a relay-denied response. The successful greeting did not grant that permission. Record the rejection at RCPT, along with the actual connection and account state, instead of concluding that EHLO authentication failed. Conversely, a rejection to EHLO itself needs its own complete explanation. These are invented protocol cases, not a retained lab or commercial-provider test.

Troubleshoot the exact rejection

Preserve the complete greeting-stage reply and any later rejection. An EHLO failure may require checking syntax, implementation compatibility or the expected service endpoint. A failure at RCPT can instead concern relay permission or recipient existence. A failure after DATA can involve content or message policy. Do not rename the client host to the visible From domain merely because the eventual message failed DMARC.

After successful STARTTLS, discard the pre-TLS SMTP information and send a fresh EHLO as recommended by RFC 3207 section 4.2; the capability list can change. If authentication is required for submission, follow the provider's supported secure method. Test the corrected configuration using harmless content and record the final response at each stage. The useful conclusion is which operation failed and why, not whether a hostname looked plausible.

Choose the next check from the reply

  • EHLO syntax or greeting rejection: check the exact endpoint, supplied name and full reply.
  • AUTH failure after TLS: check the provider-supported secure method and current permissions without exposing secrets.
  • RCPT rejection: distinguish recipient existence from relay authorization using the full response.
  • Post-DATA rejection: inspect the message-policy explanation and trusted authentication evidence.
  • DMARC complaint: compare the actual SPF/DKIM identity with From; renaming EHLO alone is not a general alignment repair.

[ Takeaway ]

Use HELO and EHLO as SMTP identification and capability signals, then evaluate authentication and policy separately.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Record all identities

Greeting, peer IP and envelope each have a distinct role.

Next steps

  1. Capture EHLO replies.
  2. Label SPF identities.
  3. Rediscover extensions after TLS.

CISO / SecOps

Use trust signals carefully

DNS consistency is not proof of message authorization.

Next steps

  1. Review local rejection rules.
  2. Keep protocol checks distinct.
  3. Avoid treating greeting text as an allow signal.

Founder / Non-technical

Avoid cosmetic fixes

A plausible greeting name is not a security verdict.

Next steps

  1. Ask which command failed.
  2. Separate submission from delivery issues.
  3. Require evidence for claimed remediation.

[ FAQs ]

Frequently asked questions

Does EHLO authenticate domain ownership?

No. It supplies a client identity and requests extension information.

Is HELO identical to EHLO?

Both greet the server, but EHLO requests extended SMTP capabilities.

Must an EHLO DNS mismatch alone cause rejection?

RFC 5321 says a server must not refuse a message solely on failure of that verification.

Can SPF check HELO?

Yes. Record the evaluated identity and distinguish it from nonempty MAIL FROM evaluation.

What happens with an empty reverse path?

The SPF procedure uses an identity constructed from HELO as specified in RFC 7208.

Does a successful greeting prove the supplied name resolves?

No. The hypothetical greeting demonstrates command flow only. DNS resolution and ownership require separate evidence.

Why rediscover capabilities after STARTTLS?

RFC 3207 requires discarding pre-TLS SMTP knowledge and recommends EHLO as the first command after TLS; the advertised capabilities can change.

Should EHLO be changed to match From after a DMARC failure?

Not as a generic fix. Diagnose the actual authenticated identity and failing stage first.

[ Sources ]

Sources

  1. RFC 5321 Simple Mail Transfer Protocol

    Sections §2.3 · §4.1 · §4.2 · §4.5

  2. RFC 7208 Sender Policy Framework

    Sections §2.3 · §2.4 · §4 · §10

  3. RFC 3207 SMTP Service Extension for Secure SMTP over TLS

    Sections §4

[ Glossary ]

Glossary

EHLO
The extended SMTP greeting that identifies the client and requests capabilities.
HELO identity
The client identity supplied in the SMTP greeting and usable in SPF evaluation.
Address literal
A bracketed address form permitted in specified SMTP identity contexts.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base