HELO / EHLO

Every SMTP conversation begins with the connecting server identifying itself. The receiving server greets first ("220 mx.example.com ESMTP Postfix"), and the sending server replies with HELO or EHLO followed by its claimed hostname:

EHLO mail.sender-domain.com

HELO is the original SMTP greeting (RFC 821). EHLO is the extended-SMTP version (RFC 5321) that signals the sender supports modern extensions like STARTTLS, AUTH, 8BITMIME. Modern senders always use EHLO. HELO appears only in legacy or constrained environments.

The hostname after EHLO is what the receiver records and uses for several downstream checks: rDNS verification, SPF evaluation in some configurations, anti-spoofing checks, reputation tracking. So getting it right matters more than people realise.

The HELO hostname has to satisfy three conditions at once:

1. It must be a fully-qualified domain name. "mail.example.com" is valid. "mail" alone is not. "localhost" is not. IP addresses are not.
2. It must match the reverse DNS of the connecting IP. If the IP is 185.10.20.30 and rDNS is mail.example.com, EHLO must declare mail.example.com. Mismatches between rDNS and HELO get flagged by virtually every modern receiver.
3. It must forward-resolve back to the same IP. mail.example.com must have an A record pointing to 185.10.20.30. This closes the loop: rDNS → hostname → A record → same IP. Called FCrDNS (Forward-Confirmed Reverse DNS).

Fail any of the three and reputation suffers. Most receivers do not reject outright on mismatch alone; they downgrade the trust signal, which feeds spam-folder routing.

Patterns that produce HELO problems:

• HELO declares a generic hostname. Some MTAs default to the local machine's hostname ("server1.local" or "host.example") rather than the public mail-sending hostname. Set EHLO explicitly to a publicly resolvable FQDN.
• HELO matches one IP but the connection comes from another. Multi-IP servers must declare the right HELO per outgoing IP. Common mistake on PowerMTA or Postfix multi-IP setups: HELO = primary IP's hostname even when sending from a secondary IP.
• rDNS not configured. Hosting providers sometimes ship IPs with default rDNS ("static.185.10.20.30.provider.com"). Set custom rDNS to a hostname under your sending domain and align HELO with it.
• Forward DNS missing. rDNS exists, HELO matches, but the hostname has no A record. Easy to overlook. Trivial to fix once you notice.
• Hostname on a different domain than From:. Not strictly required to match, but related-organisation alignment helps reputation. HELO=mail.example.com + From: news@example.com is fine. HELO=mta42.shared-host.com + From: news@example.com is weaker.

HELO is the first information about you that the receiver gets: before authentication, before content, before audience. Receivers use it as an early signal:

• HELO is one of the inputs to early connection-time spam scoring at most receivers.
• Mismatched HELO/rDNS is a common reject criterion for paranoid receivers (corporate Exchange, security gateways like Proofpoint).
• HELO is logged by the receiver. When something goes wrong later (bounce investigation, complaint trace), HELO is in the audit trail.
• Some SPF mechanisms reference HELO directly. spf:helo can authorise based on HELO hostname rather than envelope sender.

The fix is mechanical. Configure rDNS to a hostname under your sending domain. Configure forward DNS to the same IP. Configure your MTA to use that exact hostname as HELO/EHLO. Test with swaks --to test@example.com --from sender@yourdomain.com --server your-mta.example.com and inspect the SMTP transaction.

EHLO replaced HELO for ESMTP (extended SMTP) interaction. The receiver responds to EHLO with a list of supported extensions, and the sender chooses which to use. Modern receivers expect specific capability advertisements and apply lower trust to senders that look outdated.

Critical capabilities to advertise: STARTTLS for opportunistic TLS upgrade, SIZE indicating maximum accepted message size (typically 50-150 MB depending on receiver), PIPELINING for command efficiency, 8BITMIME for binary content support, SMTPUTF8 for internationalised email addresses (EAI), DSN for delivery status notifications, ENHANCEDSTATUSCODES for detailed response codes, CHUNKING (BDAT extension) for large messages.

Senders should advertise the extensions they support. MTAs that send only HELO without EHLO are flagged by some receivers as legacy or potentially abusive. Modern PowerMTA, Postfix, Exim, Sendmail all default to EHLO; if your MTA is sending only HELO, configuration somewhere is broken.

Receivers also evaluate the EHLO capability list against expectations. A capability list missing STARTTLS at receivers that require TLS will fail subsequent SMTP transactions; a capability list with strange or non-standard extensions sometimes triggers heuristic flags. Stick to RFC-standard capabilities.

Major receivers apply scoring at multiple SMTP transaction phases. HELO/EHLO is among the earliest signals, and bad signals here can cause the connection to be rejected before MAIL FROM, RCPT TO, or message body have any chance to influence the decision.

Specific patterns that lower trust at HELO time. HELO presenting an IP address rather than hostname (HELO 192.0.2.50): rejected at most modern receivers, since RFC 5321 requires hostname. HELO presenting a hostname that doesn't match rDNS: significant trust penalty. HELO presenting a hostname under .local or other RFC 6761 reserved TLDs: rejected. HELO presenting a hostname that doesn't forward-resolve: significant trust penalty. HELO presenting a clearly generic hostname (localhost, localhost.localdomain, mail.example.com as a literal): rejected at major receivers.

The cumulative effect is that HELO matters more than its position in the SMTP transaction suggests. Operators sometimes treat HELO as a formality (the actual mail sending starts at MAIL FROM) and discover that misconfigured HELO causes rejections that look mysterious because the rejection happens before any clearly-attributable mail content. Audit HELO configuration as part of any deliverability investigation; it's easy to verify and easy to fix when wrong.

Receiver-side enforcement on HELO/EHLO compliance has tightened through 2024-2026 as receivers have integrated HELO validation more deeply into their classification systems. The structural pattern is that HELO is no longer a soft signal that other factors can override; persistent HELO problems produce direct enforcement at major receivers regardless of other signals.

The specific 2026 enforcement patterns: Microsoft 365 commercial properties reject SMTP connections at the HELO stage when the HELO hostname is malformed (RFC violation, contains invalid characters, presents an IP literal instead of FQDN) or persistently misaligned with reverse DNS. Gmail accepts the connection but applies HELO compliance as input to classification; persistent misalignment produces measurable placement penalty. Enterprise email security gateways (Mimecast, Proofpoint, Barracuda) apply the strictest enforcement; some configurations reject at HELO for any reverse DNS mismatch regardless of other reputation signals.

The structural reasoning for tighter enforcement is that HELO compliance is one of the cheapest signals receivers can evaluate (no DNS queries for content, no payload inspection, evaluated at connection time before any message data is exchanged), and it correlates strongly with sender quality. Senders running legitimate production sending infrastructure typically have correct HELO configuration; senders operating from compromised hosts or makeshift infrastructure often have HELO misconfigurations. The signal is cheap to evaluate and high quality for classification purposes.

For operators, the practical implication is that HELO compliance should be verified at deployment time and monitored ongoing. The companion rDNS tester on this site checks the connected condition between PTR and HELO; running the test during initial deployment catches the common misconfiguration where the MTA HELO does not match the PTR record for the connecting IP.

The most common HELO misconfiguration in production deployments is multi-IP sending operations using a single global HELO hostname for all outbound connections. The configuration produces HELO/PTR alignment for one of the sending IPs (the one whose PTR matches the global HELO) and misalignment for all others. The mechanics vary by MTA software.

PowerMTA uses per-VirtualMTA configuration that ties HELO to the source IP. The configuration looks like: each VirtualMTA declaration includes smtp-source-host setting that specifies the hostname presented during HELO from that VirtualMTA outbound connections. With this pattern, each VirtualMTA can present a different HELO matching its specific PTR record. Operators using PowerMTA need explicit per-VirtualMTA HELO configuration; the default global hostname behaves like Postfix below.

Postfix uses myhostname as the global default HELO. Multi-IP Postfix configurations need additional setup. The sender_dependent_default_transport_maps and smtp_helo_name per-transport patterns let Postfix present different HELO per outbound transport. The configuration is more complex than PowerMTA but achievable; operators running Postfix at scale with multiple IPs typically have explicit per-transport HELO configuration.

Exim uses helo_data which can be conditional on outbound interface or routing decision. The configuration syntax is flexible; operators can construct expressions that produce per-IP HELO based on which outbound IP the message is using. The implementation requires more thought than PowerMTA but provides equivalent control.

Other MTAs (Halon, Momentum, internal/custom MTAs) typically support per-source-IP HELO configuration through their respective configuration languages. Any MTA that does not support per-IP HELO is operationally inappropriate for multi-IP production sending in 2026; the receiver enforcement makes the absence of per-IP HELO a hard production blocker.

The verification pattern after configuration: send test messages from each sending IP, examine the SMTP transcript on the receiver side, confirm the HELO hostname matches the PTR record for the connecting IP. Several open-source tools (and the rdns tester on this site) automate the verification at scale; manual verification with explicit test sends is sufficient for smaller deployments.

Beyond mechanical correctness (matching PTR, well-formed FQDN), the HELO hostname itself communicates information to receivers about the sending infrastructure. The naming conventions that work well in production produce predictable signals.

Use functional hostnames in the customers domain: mail01.example.com, mta-eu-01.example.com, smtp1.example.com. The hostname identifies the sender by domain (which receivers can validate against the senders other DNS configuration) and indicates the role (mail-related infrastructure). Functional hostnames signal professional sending operations.

Avoid generic provider hostnames: ec2-185-12-34-56.compute.amazonaws.com, vps-185-12-34-56.example-isp.net. These are the default PTR values assigned by infrastructure providers when the customer has not configured their own. Generic provider hostnames signal that the sender has not bothered to configure professional infrastructure, which correlates with poor sender quality in receiver-side classification models.

Use consistent naming patterns across infrastructure: mail01.example.com, mail02.example.com, mail03.example.com rather than mixed conventions across the sending pool. Consistency makes the sending operation look organized and intentional, which signals professional infrastructure management.

Match the geographic or functional pool: for multi-region sending operations, the hostname can encode region (mail-eu-01.example.com, mail-us-01.example.com) or function (marketing-01.example.com, transactional-01.example.com). The encoding helps operators identify mail provenance in troubleshooting and signals to receivers that the sending infrastructure is purposefully segmented rather than randomly distributed.

Avoid hostnames that suggest mass sending or marketing automation specifically: bulk-mailer-01.example.com or spam-cannon.example.com would be poor choices. Hostnames that overtly identify the infrastructure as bulk-sending can produce additional scrutiny from some receivers even when the actual sending is legitimate. Functional but neutral naming (mail, mta, smtp) is the safer pattern.

Most HELO issues surface either at initial deployment (failure to send entirely, or visible HELO rejection in MTA logs) or as gradual placement degradation that traces back to HELO compliance over time. The troubleshooting patterns below cover both categories.

SMTP rejection at HELO: the receiver returns a 5xx code immediately after the HELO/EHLO command before any message data is exchanged. The rejection typically includes a brief explanation: 504 5.5.2 Need fully-qualified hostname for malformed HELO, 550 5.7.1 Bad HELO for HELO matching known-bad patterns, 421 4.7.0 HELO command rejected for various other policy violations. The MTA logs surface these rejections; production operators should alert on any HELO-stage rejection volume above background noise.

Placement degradation traceable to HELO: harder to diagnose because the receiver does not announce HELO problems through SMTP responses when applying soft penalty. Diagnostic indicators: SNDS reputation drops on specific IPs despite clean sending patterns, Postmaster Tools at Gmail shows authentication or compliance warnings, blocklist monitoring shows IPs listed on the few RBLs that specifically flag HELO issues. The verification path runs the rdns tester to confirm PTR/HELO alignment, then examining MTA outbound transcripts to verify the configured HELO matches what receivers actually see.

Inconsistent HELO across the sending pool: particularly common in operations that have grown organically over time and where new sending infrastructure was added without verifying HELO configuration matched existing patterns. The fix is auditing every sending IP for its actual HELO behavior (not just configured intent) and bringing the inconsistent IPs into compliance with the standard naming pattern.

HELO changes during MTA upgrades: some MTA software changes its HELO behavior between versions, or resets to default behavior after configuration files are regenerated through automated deployment. Operators upgrading MTA software or running configuration-management automation should explicitly verify HELO configuration survives the operations; defaults that produce silent HELO regression are a frequent post-upgrade issue.

HELO compliance during IP migration: when sending operations move to new IPs, the HELO configuration needs to migrate alongside. Common failure pattern: new IPs deployed with the old PTR records still pointing to the previous IPs, or with new PTR records but MTA HELO still pointing to the old hostnames. The migration checklist should explicitly include HELO verification at each step of the IP transition.