# What should your mail server's HELO/EHLO hostname be?

URL: https://iblockspam.com/blog/helo-ehlo-hostname-explained
Last updated: 2026-11-03
Published: 2026-11-03
Topic: Running email day to day
Author: iBlockSpam Team

> What the HELO/EHLO hostname is, why it should be a real FQDN matching your PTR record, how receivers and SPF use it, and how to set it in Postfix and Exchange.

## Short answer

The HELO/EHLO hostname is the name a sending mail server gives when it starts an SMTP session. RFC 5321 says it must be a fully qualified host name that resolves to an address, or an address literal. Use one name, such as mail.example.com, whose A record points to the sending IP and whose PTR record points back.

Every SMTP session starts with the sending server introducing itself. That one word after `EHLO` is easy to ignore, and it's one of the first things a receiving server looks at. A wrong or generic name won't always get your mail rejected, but it adds to the evidence that your server is misconfigured, and some receivers refuse it outright.

## What is the HELO/EHLO hostname?

The HELO/EHLO hostname is the name a mail client or server gives in its first SMTP command, for example `EHLO mail.example.com`. [RFC 5321, section 4.1.1.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.1.1.1) says these commands "are used to identify the SMTP client to the SMTP server" and that "the argument clause contains the fully-qualified domain name of the SMTP client, if one is available."

A fully qualified domain name (FQDN) is a complete name that exists in public DNS, such as `mail.example.com`, as opposed to a bare machine name such as `mail` or `server01`. The HELO name is also called the HELO identity, and it is separate from the two sender addresses in a message:

| Identity | Where it appears | Example | Who usually controls it |
|---|---|---|---|
| HELO/EHLO name | First SMTP command | `EHLO mail.example.com` | Whoever runs the sending server |
| Envelope sender (MAIL FROM) | `MAIL FROM:<...>`, later the Return-Path header | `bounces@example.com` | The sending service |
| Header From | The From line people see | `Alice <alice@example.com>` | The sender |

If you need a refresher on the full conversation, [what is SMTP](https://iblockspam.com/blog/what-is-smtp) walks through each command, and [Return-Path vs From address](https://iblockspam.com/blog/return-path-vs-from-address) covers the two sender addresses.

## What is the difference between HELO and EHLO?

EHLO is the extended version of HELO: it identifies the client and asks the server to list the SMTP extensions it supports. HELO comes from the original SMTP standard and returns a simple greeting with no list. RFC 5321 says "a client SMTP SHOULD start an SMTP session by issuing the EHLO command," and that "servers MUST support the HELO command and reply properly to it."

The extension list is why EHLO matters. It tells the client whether the server accepts `STARTTLS` (encryption), `AUTH` (login), `SIZE` (and the maximum message size) and other features. RFC 5321 also says "servers MUST NOT return the extended EHLO-style response to a HELO command", so a client that sends HELO can't use any of them. Old printers and scripts sometimes still send HELO, which is one reason they can't encrypt or authenticate.

## What should the HELO hostname be?

Use one real host name for each sending IP address, and make it consistent in three places: the EHLO command, the name's A or AAAA record, and the IP's PTR record. RFC 5321, [section 2.3.5](https://www.rfc-editor.org/rfc/rfc5321.html#section-2.3.5), sets the minimum: "The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal."

An address literal is the IP address in square brackets, such as `[203.0.113.10]` for IPv4 or `[IPv6:2001:db8::25]` for IPv6. It's allowed for clients without a name, but a server that sends mail to the internet should have one.

The blocklist operator Spamhaus gives the practical version on its [Combined Spam Sources page](https://www.spamhaus.org/blocklists/combined-spam-sources/). It says the HELO value "should be a fully qualified domain name (FQDN)", that "the forward DNS lookup (domain name to IP address) of your IP should match the HELO value set in your server", and that you should ensure "your hostname and your HELO match" and that "reverse DNS (PTR record) is defined and pointing to the same hostname".

A correct setup looks like this example:

```
EHLO name:     mail.example.com
A record:      mail.example.com.            IN A    203.0.113.10
PTR record:    10.113.0.203.in-addr.arpa.   IN PTR  mail.example.com.
SPF for host:  mail.example.com.            IN TXT  "v=spf1 a -all"
```

The PTR record is set by whoever owns the IP address, usually your hosting provider or ISP, not in your own DNS zone. Our guide to [reverse DNS (PTR) records](https://iblockspam.com/blog/reverse-dns-ptr-records-for-mail-servers) explains forward-confirmed reverse DNS and how to request a PTR change.

### Good and bad HELO names

| HELO name | Verdict | Why |
|---|---|---|
| `mail.example.com` (A and PTR match) | Good | Real FQDN, forward and reverse DNS agree |
| `mx3.provider.example` on a provider's shared IP | Good | Identifies the responsible operator |
| `vps12345.host.example` (A and PTR match) | Acceptable | Valid, but anonymous |
| `[203.0.113.10]` | Acceptable for clients | Allowed by RFC 5321 when the host has no name |
| `localhost` or `localhost.localdomain` | Bad | Not a public name; Spamhaus lists `localhost.localdomain` as a common misconfiguration |
| `mail` or `SERVER01` | Bad | Not fully qualified; RFC 5321 says local aliases "MUST NOT appear in any SMTP transaction", and Spamhaus lists `mail` as a common misconfiguration |
| `WIN-XYZPDQ01` | Bad | A default Windows machine name, cited by Spamhaus |
| `example.com` (no A record for the sending IP) | Weak | Exists in DNS but doesn't point to the server |
| `gmail.com` or another domain you don't run | Bad | Looks like forgery |

## Will receivers reject mail because of the HELO name?

Some will, but rarely on a mismatch alone. RFC 5321, [section 4.1.4](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.1.4), says a server "MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis." Section 7.9 then adds that "an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server."

In practice, that means receivers treat a mismatch as a signal and reject names that are clearly broken. Two examples from primary documentation:

- **Gmail** lists `501 5.5.4` replies for "HELO/EHLO argument ... invalid" and "Empty HELO/EHLO argument not allowed" in its [SMTP errors reference](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes), and `503 5.5.1 EHLO/HELO first` for a client that skips the command.
- **Postfix**, a widely used open-source mail server, gives administrators [optional restrictions](https://www.postfix.org/postconf.5.html): `reject_invalid_helo_hostname` for a malformed name (reply 501 by default), `reject_non_fqdn_helo_hostname` for a name "not in fully-qualified domain or address literal form" (504), and `reject_unknown_helo_hostname` when the name "has no DNS A or MX record" (450).

Blocklists look at it too. Spamhaus's CSS page names forward and reverse DNS and HELO values among the things a server "should be configured with". A bad HELO name won't list you by itself, but it makes an infected or misconfigured server easier to spot. If your IP is listed, our guide to [getting off an email blacklist](https://iblockspam.com/blog/remove-domain-ip-from-email-blacklist) explains the steps, and the [Blacklist Checker](https://iblockspam.com/tools/blacklist-checker) shows where you stand.

## How do SPF and DMARC use the HELO name?

SPF can check the HELO name as its own identity, but DMARC ignores that check. [RFC 7208, section 2.3](https://www.rfc-editor.org/rfc/rfc7208.html#section-2.3) says "it is RECOMMENDED that SPF verifiers not only check the 'MAIL FROM' identity but also separately check the 'HELO' identity". It adds that HELO records "refer to a single host" and are "a very reliable source of host authorization status." Section 10.1.2 calls SPF records for individual hosts "best practice" and gives `v=spf1 a -all` as the standard record for a mail host.

The HELO name also matters for bounces. A bounce has an empty envelope sender, written `MAIL FROM:<>`. [Section 2.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-2.4) says that in this case the MAIL FROM identity becomes "the mailbox composed of the local-part 'postmaster' and the 'HELO' identity". So without an SPF record on your HELO name, your server's bounces can't pass SPF.

DMARC is different. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) says "DMARC relies solely on SPF validation of the MAIL FROM identity." A passing HELO check won't make a message pass DMARC, and a failing one won't make it fail. For DMARC, what counts is an aligned envelope sender or an aligned DKIM signature; see [DMARC alignment](https://iblockspam.com/blog/dmarc-alignment-relaxed-vs-strict).

## Where can you see the HELO name in a message?

Look at the `Received` headers. [RFC 5321, section 4.4](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.4) says the FROM clause of each Received line "SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection." A typical example:

```
Received: from mail.example.com (mail.example.com [203.0.113.10])
        by mx.receiver.example with ESMTPS id 4ABC123
        for <bob@receiver.example>; Tue, 3 Nov 2026 09:14:02 -0500
```

The first name is the EHLO name. The part in parentheses is what the receiver found itself: the PTR name and the connecting IP. When the two disagree, you see it right there. Many receivers also add a `Received-SPF` header with a `helo=` field. Paste the full headers into the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer) to see each hop, and read [how to read email headers](https://iblockspam.com/blog/how-to-read-email-headers) for the rest.

## How do you set the HELO hostname?

Set it in the software that delivers mail, not in DNS. The exact setting depends on the server:

- **Postfix:** `smtp_helo_name` sets "the hostname to send in the SMTP HELO or EHLO command". Its default is `$myhostname`, the machine's host name, so the simplest fix is usually to set `myhostname = mail.example.com` in `main.cf` and reload.
- **Exchange Server:** each Send connector has an `-Fqdn` setting. [Microsoft Learn](https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-sendconnector) says it's used "in the EHLO/HELO command when the Send connector communicates with the next hop messaging server", and that by default it's the FQDN of the server holding the connector. For example: `Set-SendConnector "Internet" -Fqdn mail.example.com`.
- **Microsoft 365 and Google Workspace:** you don't set it. Their outbound servers use their own names.
- **Apps, devices and scripts:** look for a field named "HELO name", "EHLO domain" or "local hostname". If there isn't one, the device usually sends its own machine name, which is a good reason to send through an authenticated [smart host](https://iblockspam.com/blog/what-is-a-smart-host-smtp-relay) instead of directly.

## How do you check your HELO setup?

Follow these steps on each server that sends mail directly to the internet:

1. **Find the name your server sends.** Check its configuration, or send a test message to a mailbox you control and read the top `Received` header.
2. **Look up the name's A or AAAA record** and confirm it returns your sending IP.
3. **Look up the IP's PTR record** with the [Reverse DNS (PTR) Lookup](https://iblockspam.com/tools/ptr-lookup) and confirm it returns the same name.
4. **Publish `v=spf1 a -all`** (or an `ip4:`/`ip6:` equivalent) on that host name.
5. **Test the conversation.** Connect to a receiving server and send `EHLO` with your name; our guide to [testing an SMTP server with Telnet and OpenSSL](https://iblockspam.com/blog/test-smtp-server-telnet-openssl) has the commands.
6. **Check the result** with the [deliverability test](https://iblockspam.com/tools/deliverability-test), which reports reverse DNS and authentication for the message it receives.

## Next steps

- Pick one name per sending IP, set it as the HELO name, and make the A and PTR records match it.
- Add an SPF record for that host name so bounces from your server can pass SPF.
- If you're starting a new server on a cloud host, check that outbound port 25 is allowed before you troubleshoot anything else; see [port 25 blocked by cloud providers and ISPs](https://iblockspam.com/blog/port-25-blocked-cloud-isp).
- If you'd rather not manage HELO names, PTR records and IP reputation yourself, send through a relay. iBlockSpam's [outbound relay](https://iblockspam.com/features/outbound-relay) is a smart host with DKIM signing, with 500 messages per domain per month included.

## Frequently asked questions

### Does the HELO name have to match my email domain?

No. The HELO name identifies the server, not the sender's address, so mail from you@example.com can come from a server that says EHLO mx3.provider.example. What matters is that the name is a real host name, resolves to the sending IP and matches that IP's PTR record. On your own dedicated server, using your own domain is clearest.

### Can a receiver reject my mail because the HELO name doesn't match my IP?

RFC 5321 says a server must not refuse a message only because the EHLO name fails to match the client's IP. It also says servers may refuse mail for any operational reason, and many reject names that are malformed, unqualified or don't exist in DNS. Gmail, for example, rejects an invalid or empty HELO argument with 501 5.5.4.

### What is the difference between HELO and EHLO?

Both identify the client, but EHLO also asks the server to list its SMTP extensions, such as SIZE, STARTTLS and AUTH. HELO is the older command from RFC 821 and gets a plain reply with no extension list. RFC 5321 says clients should start with EHLO, and servers must still accept HELO.

### Should I publish an SPF record for my HELO hostname?

Yes, it's good practice. RFC 7208 recommends that receivers check the HELO identity and calls SPF records for individual hosts best practice, suggesting v=spf1 a -all for a mail host. That record also covers bounces, which have an empty MAIL FROM and are checked against postmaster at the HELO name.

### Do I need to set the HELO name if I use Microsoft 365 or Google Workspace?

No. When Microsoft 365 or Google Workspace delivers your mail, their servers use their own host names, which they manage. You only control the HELO name on servers you run yourself, such as Postfix, Exim or Exchange Server, and on apps or devices that deliver mail directly instead of through your provider.

## Sources

- [RFC 5321: Simple Mail Transfer Protocol, sections 2.3.5, 4.1.1.1, 4.1.4, 4.4 and 7.9](https://www.rfc-editor.org/rfc/rfc5321.html)
- [RFC 7208: Sender Policy Framework (SPF), sections 2.3, 2.4 and 10.1.2](https://www.rfc-editor.org/rfc/rfc7208.html)
- [RFC 9989: DMARC, section 4.4.2](https://www.rfc-editor.org/rfc/rfc9989.html)
- [Spamhaus: Combined Spam Sources (CSS)](https://www.spamhaus.org/blocklists/combined-spam-sources/)
- [Postfix configuration parameters (postconf.5)](https://www.postfix.org/postconf.5.html)
- [Microsoft Learn: Set-SendConnector](https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-sendconnector)
- [Google Workspace Admin Help: Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes)

## Free tools for this guide

- [Reverse DNS (PTR) Lookup](https://iblockspam.com/tools/ptr-lookup): Check PTR records, forward-confirmed reverse DNS and generic-looking host names.
- [Blacklist Checker](https://iblockspam.com/tools/blacklist-checker): Check an IPv4 or IPv6 address, or your mail servers, against public spam blocklists, with policy and delisting links.
- [Email Deliverability Test](https://iblockspam.com/tools/deliverability-test): Send one email and see its SPF, DKIM and DMARC results, reverse DNS, blocklists, TLS and spam verdict.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.

---

Source: iBlockSpam, https://iblockspam.com/blog/helo-ehlo-hostname-explained (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt