My mail server is in some blacklist cause of spams. I reconfugured postfix. Aften then My customers get this error they can't send emails.

404 4.5.2 <PLLAMNAZIFE>: Helo command rejected: need fully-qualified hostname

In Mail.log:

postfix/smtpd[9853]: NOQUEUE: reject: RCPT from unknown[xx.xx.xx.xx]: 
404 4.5.2 <PLLAMNAZIFE>: Helo command rejected: need fully-qualified hostname; 
from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<PLLAMNAZIFE>

In my main.cf:

   # rules restrictions
smtpd_client_restrictions =
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions = 
        reject_rhsbl_client blackhole.securitysage.com, 
        reject_rhsbl_sender blackhole.securitysage.com, 
        reject_rbl_client zen.spamhaus.org, 
        reject_rbl_client bl.spamcop.net, 
        reject_rbl_client blackholes.easynet.nl, 
        reject_rbl_client cbl.abuseat.org, 
        reject_rbl_client proxies.blackholes.wirehub.net, 
        reject_rbl_client dnsbl.njabl.org

smtpd_helo_required = yes
unknown_local_recipient_reject_code = 550
disable_vrfy_command = yes
smtpd_data_restrictions = reject_unauth_pipelining

9 Answers 9


That error message is appearing because the mail client is sending only a bare hostname ("PLLAMNAZIFE") rather than a fully-qualified hostname (e.g. "PLLAMNAZIFE.example.com") in the HELO/EHLO part of the SMTP transaction, and your Postfix server is configured to reject such mail.

Many mail client programs do not send correctly formatted, fully-qualified, valid hostnames in the HELO/EHLO. Since you have to accept such mail from paying customers and have little or no control over what mail client they use (and because HELO checks aren't really of much use in blocking spam), it's probably best to disable the HELO checks.

To disable HELO checks, remove the following two lines from your Postfix config:


Even better, remove the entire smtpd_helo_restrictions = ... rule and smtpd_helo_required = yes.

  • thank you. I disabled that lines and it's work now. I can send with mozilla thunderbird on my pc. But my customer can't send any mail with outlook on their pc. Is there any way to fix this problem with HELO check config?
    – RedLEON
    Commented Sep 21, 2013 at 8:53
  • if you've removed the helo checks and your customers still can't send mail then it's most likely some other problem, with a different reject reason in the mail log.
    – cas
    Commented Sep 22, 2013 at 1:47
  • They can send now. But I wanna to configure my server as secure
    – RedLEON
    Commented Sep 22, 2013 at 8:43
  • 2
    what makes you think that helo checks enhance security?
    – cas
    Commented Sep 22, 2013 at 13:36

You can bypass HELO restrictions for authenticated users by inserting permit_sasl_authenticated before rejecting rules in the smtpd_helo_restrictions list:

smtpd_helo_restrictions =

The host name variable for your mail server is invalid.

Try and change the value of myhostname field from /etc/postfix/main.cf from the default value to your host name (e.g. yourwebsite.com or mail.yourwebsite.com)


It has taken me ages to work this out

I am running a centos server and was getting email bouncing back reporting the error" Helo command rejected: need fully-qualified hostname"

I ended up enabling "Reference /etc/mailhelo for outgoing SMTP HELO [?]" This was located under "exim configuration manager" then "Domains and IPS" on the VPS server

Then i used putty and remoted onto the server and ran this command "sudo nano /etc/mailhelo"

In that file i created the domains example.com: example.com sub.example.com: example.com example.net: example.net addon.example.net: example.net *: hostname.example.com

(as per http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/EximDifferentIps)

I have tested sending email and all looks good so far


It's not your e-mail server that rejects the client, but an external SMTP server that rejects the message from your SMTP server, the issue is that your SMTP server does not send it's FQDN name in the helo message when communicating with other servers.

This can usually be solved by adding the public IP to hosts file with the FQDN to the /etc/hosts file. Like this: host.domain.com host host.domain.com host

Where is the official IP.

I had this problem and it did not help that the DNS was working both ways forward/reverse on the public IP and I had only my own nameserver in /etc/resolv.conf. Even hostname -f returned the correct one. I still had to put the ip and hostname to /etc/hosts for sendmail to actually use the FQDN instead of just the short hostname.

If you telnet to your server on port 25, make sure the 220 line says the FQDN and not just the host. Like this:

220 host.domain.com ESMTP Sendmail 8.15.2/8.15.2/SuSE Linux 0.8; Mon, 9 Jul 2018 18:19:48 +0200


Sometimes a server has a 'hiccup'. Caused for instance by mail attacks.

First try restart the server. Than set the mail in the server to off an after 15 seconds back on.

Sometimes the HELO cmd rejected is caused because mail cannot load new anti-virus definitions; like AmaVis that is used on Apple servers. A restart and off/on the mail app in the server solves this problem. Cheers.


I was getting non-domain name when running hostname -f. So I googled for no domain in "hostname -f". It turned out I needed to edit /etc/hostname (I'm on Debian) to resolve the problem. After that both hostname -f and helo were using fully qualified hostname.


If you want to reject HELO with bad hostnames, but still allow your users to be able to send even if their clients don't send FQDNs with HELO, you can leave these lines in place as you have them:


But make sure they are preceded by:


This way, when one of your users authenticates, they'll be permitted to send email regardless of the validity of their HELO command, and only non-authenticated connections (which should only be other SMTP servers relaying mail to you, because you're obviously requiring all of your users to authenticate, right?) will be subject to the valid HELO requirement.


I had this error pop up today for a client. As it turned out, it was nothing like the above.

The server had been working fine for ages, but I assumed incorrectly it must be the server/postfix settings.

But, it was simply the client forgetting to check this box in Outlook:

"My outgoing server (SMTP) requires authentication"

..in "Settings" / "..More Settings" under the problem account.

So, when the specified client account would send outbound email, it would act like a relay with no authentication before sending. It would also send the windows machine name as HELO. The windows machine hostname is not a FQDN that resolves and was therefore rejected. If you see a client machine sending a single hostname like the Question, you check the sender's client settings before assuming it's the server (like I did).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .