The SMTP banner is the greeting your mail server sends when a remote server connects. HELO and EHLO are the greetings your server sends back when connecting outbound. Both must resolve to a fully qualified domain name that matches the sending IP reverse DNS, or receiving servers will penalize or reject your messages.
Most email deliverability guides focus on content, authentication, and reputation. These matter, but they assume the conversation between mail servers has already started cleanly. Before any content is evaluated, before SPF or DKIM is checked, the two servers greet each other, and that greeting is the first deliverability signal a receiving system records.
This guide covers the SMTP banner, HELO and EHLO commands, and how to configure them correctly to avoid the pre-content filtering that catches a surprising number of otherwise legitimate senders.
Understanding the SMTP Conversation
When a sending mail server delivers a message, it opens a TCP connection to the receiving server on port 25 (or 587 for authenticated submission). The receiving server responds with a banner, and the sending server identifies itself with a HELO or EHLO command. Only after this exchange succeeds does the actual message transfer begin.
A typical SMTP conversation starts like this:
220 mx.example.com ESMTP Postfix (Ubuntu)
EHLO mail.sender.com
250-mx.example.com Hello mail.sender.com [203.0.113.45]
250-SIZE 52428800
250-PIPELINING
250-8BITMIME
250-STARTTLS
250 DSNThe first line starting with 220 is the receiving server banner. The EHLO line is sent by the connecting server. The 250 responses advertise supported extensions. Receiving servers log every element of this exchange and cross-reference it against DNS, blacklists, and reputation data in milliseconds, before the DATA command ever transmits message content.
What Is the SMTP Banner?
The SMTP banner (also called the greeting banner or 220 response) is the first line your mail server sends to any remote server that connects to it. Per RFC 5321, the banner must begin with the response code 220 and should include the fully qualified domain name of the server.
A properly configured banner looks like this:
220 mail.example.com ESMTP PostfixThe critical component is the FQDN (mail.example.com). This hostname must:
- Resolve via DNS to the server IP address (A record)
- Match the PTR record (reverse DNS) for that IP
- Be a hostname that actually belongs to your organization
- Not be an internal hostname, localhost, or generic placeholder
Critical: A banner reading "220 localhost.localdomain ESMTP" will be rejected or heavily filtered by every major mailbox provider. This default value appears on freshly installed Linux servers and is the single most common banner misconfiguration.
HELO vs EHLO: What Is the Difference?
HELO and EHLO are commands issued by the connecting server to identify itself. HELO is the original command from RFC 821 (1982). EHLO was introduced with Extended SMTP in RFC 1869 and allows the server to advertise support for features like STARTTLS, SIZE limits, and pipelining.
Modern mail servers should always use EHLO. HELO is only used as a fallback if the receiving server does not support ESMTP, which is vanishingly rare in 2026. The argument to either command is a hostname, and this is where deliverability problems start.
The HELO/EHLO Hostname Requirement
The hostname in your EHLO command must be an FQDN that resolves to the sending IP address and matches the reverse DNS record for that IP. This is known as forward-confirmed reverse DNS (FCrDNS), and every major mailbox provider checks for it.
The validation chain looks like this:
- Receiving server accepts connection from IP 203.0.113.45
- Receiving server performs reverse DNS lookup on 203.0.113.45, getting mail.example.com
- Sending server issues: EHLO mail.example.com
- Receiving server performs forward DNS lookup on mail.example.com, expecting to get 203.0.113.45
- If all three values align, the check passes
When these values do not align, bad things happen. Some specific failure modes:
| Misconfiguration | Typical Receiver Response |
|---|---|
| EHLO with IP address instead of hostname | Spam score increase, possible rejection |
| EHLO hostname with no DNS record | Reject with 550 error at many receivers |
| EHLO hostname forward-resolves to different IP | Spam score increase, filtering to junk folder |
| EHLO with localhost or internal hostname | Near-universal rejection at commercial receivers |
| Missing reverse DNS entirely | Outright rejection at AOL, Yahoo, and Comcast |
Configuring the SMTP Banner and HELO
Postfix
Postfix controls the banner via myhostname and smtpd_banner in /etc/postfix/main.cf:
myhostname = mail.example.com
myorigin = $myhostname
smtpd_banner = $myhostname ESMTP $mail_name
smtp_helo_name = $myhostnameThe smtp_helo_name parameter explicitly sets what Postfix will send as EHLO when delivering outbound mail. Without this line, Postfix defaults to myhostname, which is usually correct, but setting it explicitly prevents configuration drift.
Exim
Exim uses the primary_hostname directive in /etc/exim/exim.conf:
primary_hostname = mail.example.com
smtp_banner = $primary_hostname ESMTP Exim $version_numberMicrosoft Exchange
Exchange uses the send connector FQDN setting. In Exchange Admin Center, navigate to Mail Flow, then Send Connectors, select the outbound connector, and set Specify the FQDN this connector will provide in response to HELO or EHLO to your mail server FQDN.
Sendmail
Sendmail uses the Dj macro in sendmail.mc or sendmail.cf:
DjMmail.example.comFor servers behind NAT or with multiple IP addresses, ensure the HELO hostname matches the specific egress IP being used for outbound mail, not the internal or public-facing web IP. Mismatches here are a common source of mysterious filtering at large providers.
Aligning Reverse DNS with Your Banner
The PTR record for your sending IP must be set in the reverse DNS zone for your IP range. You typically cannot set this yourself; it is controlled by whoever owns the IP allocation (your hosting provider, cloud platform, or ISP).
To verify your current reverse DNS:
dig -x 203.0.113.45
host 203.0.113.45
nslookup 203.0.113.45The output should return the exact hostname you use in your HELO and banner. If it returns a generic hostname like 203-0-113-45.static.example-isp.com, you need to request a custom PTR record from your provider. Most cloud providers (AWS, GCP, Azure, DigitalOcean, Linode, Hetzner) support custom reverse DNS through their control panel or support channels. Use a reverse DNS checker to verify alignment.
AOL and Yahoo reject mail from any IP without a valid PTR record, returning error code 421 or 554 during the SMTP conversation. This is one of the oldest and most consistently enforced anti-spam checks on the internet, in place since the early 2000s.
Testing Your SMTP Banner and HELO
The simplest way to test is to connect directly to your mail server using telnet or openssl:
telnet mail.example.com 25You should see a banner like:
220 mail.example.com ESMTP PostfixIf the banner shows localhost, localhost.localdomain, ubuntu, or your server internal hostname, you have a misconfiguration that needs immediate correction.
To test your outbound EHLO, send a test message to a service that echoes back headers (many deliverability testing tools do this). Look in the Received header for the line showing your server identified itself:
Received: from mail.example.com (mail.example.com [203.0.113.45])
by mx.receiver.com (Postfix) with ESMTPS id ABC123
for <test@receiver.com>; Fri, 17 Apr 2026 12:00:00 +0000The hostname after "from" is what your server sent as EHLO. It must match your PTR record exactly.
Common Banner and HELO Failures
Generic or Default Hostnames
Freshly installed servers often keep default hostnames like ubuntu, debian, or localhost.localdomain. These will cause immediate filtering. Set a proper hostname with hostnamectl set-hostname mail.example.com before configuring any mail services.
Hostname Mismatch Between Services
A server with PTR record mail.example.com but HELO hostname mailserver.example.com fails FCrDNS checks. The two must match exactly. This commonly occurs when administrators update one but not the other.
Using an IP Address in HELO
RFC 5321 permits an IP literal in HELO (like [203.0.113.45]), but commercial mailbox providers treat this as a strong spam signal. Always use a hostname, never a bare IP.
Wildcard or Generic ISP Hostnames
Hostnames assigned automatically by ISPs (like 203-0-113-45.fiber.example-isp.net) technically pass FCrDNS but are heavily penalized by Gmail and Outlook. These hostnames signal residential or dynamic IP space, which is banned for mail delivery.
STARTTLS Misadvertised
If your EHLO response advertises STARTTLS but your TLS configuration is broken (expired certificate, mismatched hostname, unsupported protocol version), sending servers will fail on TLS negotiation. Test your STARTTLS configuration with openssl s_client -starttls smtp -connect mail.example.com:25.
Tip: Run a quick sanity check by connecting to gmail-smtp-in.l.google.com on port 25 from your server. Gmail logs incoming HELO hostnames and will drop the connection cleanly if yours looks suspicious. Check your mail logs immediately after for any 4xx or 5xx responses that indicate greeting-phase rejection.
Relationship to SPF, DKIM, and DMARC
The HELO hostname is not the same as the envelope sender (MAIL FROM) or the message From header. Each is checked differently:
- SPF typically validates the envelope sender domain, though RFC 7208 also supports HELO-based SPF checks
- DKIM validates the signing domain in the d= parameter of the DKIM-Signature header
- DMARC validates alignment between the From header domain and either SPF or DKIM
The HELO hostname affects reputation and basic spam filtering independently of these authentication checks. A message can pass SPF, DKIM, and DMARC and still be filtered because the sending server had a broken HELO configuration. This is why HELO configuration deserves attention even on modern, fully authenticated mail systems. For a complete authentication picture, see our email authentication guide.
Frequently Asked Questions
HELO is the original SMTP greeting command from 1982, while EHLO is the Extended SMTP version that lets servers advertise additional features like STARTTLS, SIZE limits, and pipelining. Modern mail servers always use EHLO and only fall back to HELO if the receiving server does not support ESMTP, which is extremely rare today.
Yes. The HELO hostname is one of the first signals receiving servers evaluate. A hostname that does not resolve via DNS, does not match the reverse DNS of the sending IP, or uses a generic value like localhost will cause spam filtering or outright rejection. Proper HELO configuration is a prerequisite for reliable delivery to major mailbox providers.
A proper SMTP banner starts with code 220 followed by your server fully qualified domain name and a brief identifier. An example is: 220 mail.example.com ESMTP Postfix. The hostname must resolve via DNS to your server IP and match the reverse DNS entry for that IP address.
Use telnet or openssl to connect directly to your mail server on port 25: run telnet mail.example.com 25 from any terminal. The first line the server responds with is your banner. It should begin with 220 followed by a proper hostname. If it shows localhost, ubuntu, or any generic default, you need to correct your configuration.
Yes, and it happens more often than most administrators realize. AOL, Yahoo, and Comcast reject mail outright from servers with missing or invalid reverse DNS. Gmail, Outlook, and most other providers apply heavy spam filtering to mismatched or generic HELO hostnames, which can push otherwise legitimate mail to the junk folder.