Every SMTP conversation begins with the client introducing itself. The command is EHLO (or the older HELO) followed by a name. It looks like a formality, and for years many applications sent whatever name came to hand: localhost, the machine's short hostname, a Windows computer name, or even an IP address with no brackets. Receiving servers have become strict about this greeting because it is cheap to check and spammers often get it wrong. The result is a family of errors such as 504 5.5.2 <name>: Helo command rejected: need fully-qualified hostname, 550 5.7.1 <name>: Helo command rejected: Host not found, 501 5.5.4 Invalid domain name and 550 5.7.25 style reverse DNS failures. They appear at the start of a session, long before the message is sent, and they are almost always fixed on the sending side. This guide explains what the greeting is for, what receivers check, and how to set a correct name on the common platforms.
What EHLO is for
RFC 5321 requires the client to identify itself with EHLO, followed by the fully-qualified domain name of the client, or, if it has none, an address literal in brackets such as [203.0.113.25]. The server answers with a list of the extensions it supports, such as STARTTLS, AUTH and SIZE. HELO is the original form without the extension list. Clients that speak modern SMTP should use EHLO first, and fall back to HELO only if the server does not understand it. The name you give appears in the Received header that the receiving server adds, and many servers check it against DNS and against the connecting IP address, because a mismatch is a common sign of malware or misconfiguration.
What receivers check
| Check | What the server tests | Typical error |
|---|---|---|
| Syntax | Is the name a valid hostname or a bracketed address literal? | 501 5.5.4 Invalid domain name, "Helo command rejected: invalid hostname" |
| Fully qualified | Does it contain at least one dot, like a full domain name? | 504 5.5.2 Helo command rejected: need fully-qualified hostname |
| Existence | Does the name resolve to an address in DNS? | 550 5.7.1 Helo command rejected: Host not found |
| Impersonation | Does it claim to be the receiving server or one of its domains? | "Helo command rejected: you are not me" |
| Match with IP | Does the name resolve to the connecting IP, or does the IP PTR point to it? | Reverse DNS or policy rejection, sometimes with a spam score instead of a bounce |
Not every server applies every check. Postfix, for example, offers reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname and reject_unknown_helo_hostname as separate options in smtpd_helo_restrictions. Large providers combine the result with other signals instead of rejecting on one test. This is why a server can work with some recipients and fail with others.
Choose a good EHLO name
A good name has four properties. It is a fully-qualified domain name that you control, such as mail1.example.com. It has an A record that points to the sending IP address (and an AAAA record if you send over IPv6). The sending IP has a PTR record that points back to the same name. And it is stable, so that reputation systems associate it with your traffic. Do not use localhost, localhost.localdomain, the short name of the machine, a name in a private zone that the Internet cannot resolve, or the name of the receiving server. If your server sends from several IP addresses, give each its own name (mta1.example.com, mta2.example.com) with matching forward and reverse records. The full picture of forward and reverse records is in reverse DNS and PTR records for email, and the effect on reputation is described in email reputation.
How to see what your server sends
The quickest check is a manual session to a server you control, or one that echoes your greeting. Your own logs also show the name used, and the receiving server's bounce quotes it in the error. You can also run:
# What name does the machine think it has?
hostname -f
# Does that name resolve to your sending IP?
dig +short A mail1.example.com
# Does the IP resolve back to the same name?
dig +short -x 203.0.113.25
# Watch the greeting in a real session
openssl s_client -starttls smtp -crlf -connect mx.example.net:25If the first command prints a short name, or something such as ip-10-0-0-5.internal, that is the likely source of the problem. Cloud servers frequently have internal default names that are not valid on the public Internet.
Fix it in your mail server
Postfix
Postfix uses myhostname for the greeting by default. Set it to the public name, and, if you use a relay, make sure smtp_helo_name is correct for outgoing connections:
# /etc/postfix/main.cf
myhostname = mail1.example.com
smtp_helo_name = $myhostname
smtp_tls_security_level = may
# then
sudo postfix reloadIf you also operate Postfix as the receiving server and see these errors in your logs for other people's mail, the restrictions that produce them live in smtpd_helo_restrictions. Be careful with strict settings: applications and devices on your own network often send poor greetings and will be refused. Apply strict helo checks only after the sender is authenticated or trusted, and consider using them as scoring signals instead of rejections.
Exim
Exim uses primary_hostname, and the outgoing greeting can be set per transport with helo_data. Set it to your fully-qualified name, and in a multi-IP setup use the name that matches the interface in use.
Microsoft Exchange and Windows SMTP
On Exchange, the connector or the send connector has a FQDN setting that defines the name used in the greeting. Set it to a public name with matching DNS records. On the legacy IIS SMTP service, the fully-qualified domain name is a property on the Delivery tab of the virtual server. A default Windows computer name without a domain is the usual cause of "need fully-qualified hostname".
Applications and libraries
Many libraries let you set the name or detect it automatically. PHPMailer has the Hostname and Helo properties, Python's smtplib.SMTP accepts a local_hostname argument, Nodemailer has the name option, and Java Mail uses mail.smtp.localhost. If you do not set it, the library asks the operating system for the name, which on containers and cloud machines is often a short or internal name. If the application sends through an authenticated relay, the greeting matters less, because the relay re-sends the message with its own identity; but a clearly invalid greeting can still cause the relay to refuse the connection. Examples for several languages are in sending email from an app.
When the error comes back from a relay or smart host
If your server sends through a provider, the provider's server is the one that reads your greeting. Some providers are lenient, while others require a valid name from you before they accept authentication. If the error appears at the relay, fix the greeting as described, and check that you are connecting to the correct submission port and that your client authenticates. If the error mentions an authentication or relay problem, see SMTP 530 5.7.0 and relay access denied.
Relationship with SPF and reputation
SPF can also check the EHLO name. The standard recommends that receivers check SPF for the HELO identity as well as for the envelope sender, and a bounce message with an empty envelope sender is checked against the HELO name. For a mail server this means that the name you announce should have its own SPF record, for example v=spf1 a -all on mail1.example.com. It costs nothing and improves trust. See the SPF record guide and SPF softfail vs fail.
Troubleshooting table
| Symptom | Likely cause | Fix |
|---|---|---|
| Need fully-qualified hostname | Short hostname or Windows name used | Set a full public name in the server or application |
| Host not found | Name has no A or AAAA record | Add the record, or use a name that already resolves |
| Invalid domain name | Spaces, underscores or an unbracketed IP | Use a valid hostname or an address literal in brackets |
| Accepted by some providers, rejected by others | Different strictness on name matching | Match forward name, IP and PTR |
| Error only from a container or cloud instance | Internal default hostname | Override the name explicitly |
| Works, but mail lands in spam | Greeting does not match the PTR | Align HELO, PTR and A record names |
| Error after changing hostnames | Old DNS records still point elsewhere | Update A and PTR, wait for DNS caches, restart the mail service |
Finish with a real test: send a message to a mailbox that shows full headers, read the Received line to confirm the name you announced, and check the authentication results. The guides on reading headers and testing an SMTP connection show how.
A correct identity on every connection Dedicated sending IPs come with matching hostnames and reverse DNS, so receivers see a consistent identity.
References and further reading
Frequently asked questions
What does Helo command rejected need fully-qualified hostname mean?
The name your server sent in HELO or EHLO is not a full domain name, such as a short hostname. Set a fully-qualified public hostname.
What should I use as my EHLO name?
A fully-qualified hostname you control that resolves to the sending IP, with the IP PTR pointing back to it.
What is the difference between HELO and EHLO?
EHLO is the extended form that lets the server list its supported extensions. Modern clients send EHLO first and use HELO only as a fallback.
Why does my cloud server send a bad greeting?
Cloud instances often have internal default hostnames. Override the name in the mail server or application settings.
Does the HELO name affect deliverability?
Yes. A valid name that matches forward and reverse DNS is a trust signal, and a mismatch can contribute to rejection or spam placement.