HELO

HELO is the SMTP greeting command a client sends to introduce itself to a mail server. It starts a session and supplies a domain name or host identifier, while EHLO is the extended form used by most modern SMTP clients. The name is separate from the message headers and affects protocol negotiation, not display.

SMTP greeting and session negotiation

HELO is the opening SMTP command a client uses to announce itself and begin a mail session. It identifies the sending host to the server so the protocol can move from connection setup into message exchange.

That greeting is part of SMTP’s conversation framing, not message content. The server uses it to establish the remote peer’s claimed identity for the session, while later SMTP commands carry the actual envelope and delivery instructions.

HELO versus EHLO

HELO is the original, simpler greeting form. EHLO is its extended successor, and most modern clients use it because it advertises support for additional SMTP features during negotiation.

The distinction matters because a server may respond differently depending on which greeting it receives. A client that sends HELO is generally signaling baseline SMTP behaviour, while EHLO opens the door to extension discovery and richer session capability.

Why the hostname matters

The domain name or host identifier in HELO is not the same thing as the sender shown in message headers. It is a protocol-level identifier used in the SMTP exchange, so it can influence interoperability, logging, and server-side policy decisions without changing the visible From address.

That separation is important in mail security because operators often inspect the greeting alongside other SMTP signals when deciding whether a session is well-formed. A mismatched, malformed, or placeholder greeting can be a useful indicator of low-quality clients, misconfiguration, or automated abuse.

Where HELO fits in mail delivery

HELO sits at the front of the SMTP transaction lifecycle, before the server accepts envelope commands such as MAIL FROM and RCPT TO. It is one of the protocol’s basic trust and negotiation steps, and it helps define how the rest of the session proceeds.

In practice, mail systems use the greeting as one input among several, including IP reputation, DNS, authentication results, and policy checks. HELO alone does not prove legitimacy, but it is part of the server’s view of the client’s behaviour and conformance to SMTP expectations.

Risk and Threat Considerations

A weak or misleading HELO value can contribute to spam filtering failures, policy evasion, or troubleshooting blind spots. Attackers and bulk mail senders commonly abuse SMTP greetings that look generic, inconsistent, or unrelated to the connecting host in an attempt to blend into ordinary traffic.

Failure mechanism: Mail infrastructure may treat the greeting as one weak signal among many, so a poor HELO string is not usually decisive on its own. The real failure occurs when operators overtrust the greeting, under-validate the session, or miss the mismatch between the claimed host and the observed connection.

Impact: Misleading greetings can reduce detection quality, complicate incident review, and weaken mail policy enforcement. In the worst case, they help suspicious senders appear more routine than they are, which can increase the chance of spam, phishing, or abuse passing through initial checks.

Practitioner Guidance

What to watch for: Treat HELO as a consistency check, not an authentication mechanism. Good operations look for alignment between the greeting, reverse DNS, session behaviour, and other SMTP controls rather than making trust decisions from the greeting alone.

Practitioner takeaway: If HELO is missing, malformed, or inconsistent with the connection context, investigate it as a mail hygiene signal and combine it with stronger SMTP and anti-abuse controls before deciding whether to trust the session.

Related resources from NHI Mgmt Group

• Why does allowing sender-controlled HELO or EHLO values increase spoofing risk in SPF macro designs?
• HELO/EHLO