HELO is a command used in the Simple Mail Transfer Protocol to identify the sending mail server during the initial stage of an email transmission. When a connection is established between a sending and receiving mail server, the sending server introduces itself using the HELO command followed by its hostname. This hostname represents the identity of the server attempting to deliver the message.
The HELO command plays a foundational role in email communication by establishing a basic level of trust and context. Receiving servers use this information alongside other checks to determine whether the connection appears legitimate. While HELO itself does not authenticate the sender, it contributes to the overall validation process by signalling the server’s declared identity.
Modern implementations typically use EHLO, an extended version of HELO that supports additional SMTP features. However, HELO remains relevant for compatibility and fallback scenarios. Proper configuration ensures that the declared hostname aligns with DNS records, which is critical for maintaining deliverability and avoiding spam classification.
Advanced
HELO and EHLO are part of the SMTP handshake sequence. EHLO extends HELO by enabling capabilities such as authentication methods, TLS encryption, and message size limits. Despite this, the hostname declared in either command must be a fully qualified domain name that resolves correctly in DNS.
Alignment between HELO, reverse DNS, and forward DNS is a key deliverability factor. Best practice requires that the HELO hostname matches the PTR record of the sending IP and resolves back to that same IP address. This forward confirmed reverse DNS alignment is heavily weighted by spam filters and receiving mail servers.
In high volume or multi tenant environments, misconfigured HELO values such as generic hostnames, IP literals, or mismatched domains can trigger rejection or spam filtering. Mail servers like Postfix, Exim, and Microsoft Exchange allow explicit configuration of the HELO or EHLO identity, which must be carefully managed across all outbound relays.
Relevance
- Establishes sender identity during SMTP communication
- Contributes to email trust and deliverability
- Supports alignment with DNS and authentication checks
- Required for proper SMTP session negotiation
Applications
- Configuring outbound mail server identity in Postfix or Exim
- Aligning HELO hostname with PTR and A records
- Ensuring compatibility across different mail servers
- Supporting secure email delivery workflows
Metrics
- HELO validation results in mail server logs
- Email acceptance versus rejection rates
- Spam filtering outcomes related to hostname checks
- Alignment consistency across DNS and SMTP layers
Issues
- Invalid or non resolvable HELO hostnames causing rejection
- Mismatch with PTR or A records reducing trust
- Use of IP addresses instead of domain names triggering filters
- Inconsistent configuration across multiple mail servers
Example
A mail server sends an email and initiates the SMTP session with HELO mail.example.com. The receiving server checks that mail.example.com resolves correctly in DNS and matches the reverse DNS of the sending IP. This alignment strengthens trust and increases the likelihood that the email is accepted and delivered to the inbox.