Postfix ошибка 554

In our role as Website Support Specialists for online businesses, we resolve hundreds of email issues every day.

A commonly encountered email bounce error faced by web hosts, website owners and server owners is:

554 5.7.1 : Relay access denied

‘554 5.7.1 : Relay access denied’ error means that either the sender has failed security checks or the recipient’s mail server is misconfigured, and today, we’ll take a look at:

1. What causes Relay Access Denied error
2. How we fix it for server owners (eg. web hosting provider)
3. How we fix it for mail users
4. How we prevent this error in our customer’s (eg. web hosts) servers.

What causes Relay Access Denied Error?

When a mail is sent, it first goes to the sender’s mail server (aka MX). Then it’s RELAYED to the recipient’s MX, and from there to the recipient.

Here, TWO servers are involved – Sender’s MX and Recipient’s MX. If either one of these servers reject the mail, a Relay Access Denied error is shown to the sender.

Case 1 – Sender’s MX rejects the mail

Every mail server requires its users to provide a username and password to send mails. This is to keep spammers out. But very often valid mail users forget to turn on authentication in their mail clients, and the MX rejects their mail.

Bobcares manages the website support of several businesses. A quick look at the support tickets we handle shows that 95% of ‘Relay Access Denied’ errors are caused by incorrect SMTP settings.

So, when customers come to us facing this error, the first thing we check is their mail client settings. By guiding users with the correct settings specific to each mail client and mail server, we help them send emails without this error.

Case 2 – Recipient’s MX rejects the mail

The recipient’s mail server will accept a mail only if it can verify that the recipient is a valid user in that server. For eg. if the recipient’s account is cancelled or inactive, it won’t accept the mail.

Our Support Specialists have often traced the origin of these errors to:

• Improper sender MX configuration (eg. SMTP auth settings disabled)
• Inactive or cancelled recipient mail address
• Recipient’s DNS MX records pointing to the wrong server (often after a migration)
• Recipient’s user database errors

Help me fix this error!

We’ve seen two variations of this error in web hosting servers:

• 554 5.7.1 Relay Access Denied – The recipient’s mail server logs show this error when a mail is rejected.
• 454 4.7.1 Relay Access Denied – This error is seen in server logs when the recipient server is temporarily unable to accept mails. The mail delivery will be attempted again later.

So, if a website owner has started seeing these errors after a recent config change, or migration, or new server setup, we check the MX configuration of the domain and resolve any errors in that.

Pro Tip : If mails to several mail servers are bouncing, the mail server’s configuration could be incorrect. If mails to only a couple of recipient addresses are bouncing, the issue might be specific to those accounts.

[ Are you losing your sleep over undelivered or delayed emails? Get our professional help to fix your email errors at affordable pricing. ]

How we resolve the error for server owners

Here at Bobcares, our engineers act as the Website Support Team of web hosts, VPS hosts and dedicated server providers. These server owners see “Relay Access Denied” error in two situations:

1. When a mail user tries to send a mail, and gets a bounce.
2. When mails from a remote domain is rejected by the server, and mail users report it to the server owner.

In either case, we’ve seen the error recorded in mail server logs. It looks something like this:

Jan 23 03:10:57 mysev postfix/smtpd[15921]: NOQUEUE: reject: RCPT from mail-wg0-f53.google.com[74.125.82.53]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo=

Here are a few reasons we’ve noticed, and how we resolve them:

1. User authentication system could be broken

All modern mail servers have a way to authenticate a user before it accepts a mail to be sent. So, if we notice ALL of the mail server users getting this error, we immediately check the user authentication settings of mail server.

For example, in Postfix mail server, the below setting enables SMTP authentication. If this is disabled in the configuration file, all the users will receive “554 5.7.1 : Relay access denied“.

smtpd_recipient_restrictions = permit_sasl_authenticated

Such failures in mail server capabilities often happen as a result of mail software upgrades or operating system upgrades.

In our Website Support Services, we prevent upgrade errors or config issues by testing the upgrades in a test environment first, verifying for config conflicts and rigorously testing features post-upgrade.

2. Authentication database might be corrupt

Some servers such as Plesk servers store user login details (username & password) and authenticated IP details in databases. For instance, Plesk Qmail servers store details of authenticated IPs in a MySQL database table called smtp_poplocks.

In some cases, these databases could get partially or completely damaged due to file system errors, disk errors, etc. and multiple mail users will be unable to send mails. A quick database integrity check and repair helps us fix this issue.

Databases store critical data such as authentication information, not just for mail services, but for other services such as web, business apps, etc. So, to avoid business downtime, we monitor the database integrity round the clock.

With our 24/7 monitoring and management, we help our customers keep an eye on their servers, and quickly fix server errors any time of the day. This helps our customers maintain high service quality and business uptime.

3. External sending server failed your server’s anti-spam check

In cPanel server management, this is a case where we’ve seen that the mail server users are unable to receive mails from external parties, and the server responds with “Relay Access Denied”.

This happens when the external sending mail server fails your server’s anti-spam check. For example, this Exim mail server (myserv.com) rejected a mail from an external server (otherserver.com) because it failed a anti-spam check called “Sender Verfication Callout”.

2015-06-12 05:12:36 H=(myserv.com) [xx.xx.xx.xx] sender verify fail for : response to "RCPT TO:" from otherserv.com [yy.yy.yy.yy] was: 554 : Relay access denied
2015-06-12 05:12:36 H=(myserv.com) [xx.xx.xx.xx] F= rejected RCPT : Sender verify failed

There are three ways we resolve this:

1. We examine the mail logs and if we notice repeated instances of valid mails being blocked by such an anti-spam check, we update this particular anti-spam rule.
2. If the issue is specific to only one external mail server, we contact their administrator to make their servers compliant to the anti-spam check.
3. In certain cases where we know that the sender is a valid and trust-worthy one, we bypass the check for that server by adding it to our white-list.

Anti-spam checks are necessary, but it can damage your business if not used judiciously. In the mail servers we maintain, we stick to RFC compliant spam checks, and implement only those systems that are validated by a majority of service providers.

For eg., there are a lot of aggressive DNS-based blacklists that frequently spam-list legitimate service providers. We make sure that only trusted, reputed lists are used in our customers’ servers.

[ Are your users complaining about email errors? Get our expert server specialists’ assistance to fix your mail servers. ]

4. The recipient mail account is inactive or misconfigured

A mail server accepts only mails that’s addressed to it’s own users. For eg. the mail server of whitehouse.gov will accept only mails to [employee-name]@whitehouse.gov.

However, we’ve seen two cases where a recipient server cannot confirm a user as valid.

• The recipient mail server’s user database gets corrupt, and it is unable lookup a user as valid.
• The recipient has set the wrong IP as their domain’s MX DNS record, and mails are attempted to be delivered to the wrong server.

This issue cannot be fixed at the sender’s mail server. However, we lookup the error details from the mail server logs and contact the recipient MX administrators to issue a quick resolution.

5. Mail user’s email client configuration wrong

This is by far the most common cause of this error. Once we check the mail logs and confirm that the mail server is working fine (that is, no clogged mail queue, not many bounced mails, etc.), we look at the mail user’s email client configuration and fix it.

More on the common issues is explained in the section below.

How we resolve the error for mail users

“Relay Access Denied” error is returned when the mail server is unable to authenticate the mail user. Here are a few common situations where this error is returned.

1. When the server’s authentication settings have changed

If there has been a recent change in your mail service, like a change in email provider, or if your mail provider migrated you to a new server, it is possible that the method of user authentication has changed.

For instance, you could have been using POP-before-SMTP before, but the new server uses “SMTP authentication” now. So, we first confirm the following details for the mail users:

1. Mail server name – Eg: mail.yourserver.com
2. Mail server IP – Eg: 203.0.130.20
3. User name
4. Password
5. Whether to enable SMTP authentication or not

2. When the authenticated IP changes on mobile devices

In servers that are configured with POP before SMTP, domain owners with mobile devices report intermittent relay errors. This happens when they change the WiFi hotspot or their 4G/3G/2G network changes their IP due to a break in coverage.

The email server would be referring to the old IP as the authenticated one, while the domain owner’s mobile device would be using the new IP address.

We prevent these issues by enforcing SMTP password authentication. For example, in Parallels Plesk servers, we disable POP3 authorization and SMTP authentication is turned on by default.

3. When the domain owner tries to connect to the wrong server

This situation happens with newly registered domain owners. They would either try sending mails before the account setup is complete, use their ISP’s mail servers, or keep using their old hosting server’s host name or IP address.

Since the change needs to happen at the domain owner’s device, we focus on lightning fast resolution using step-by-step instructions customized for their mail client.

We maintain a repository of step-by-step email configuration settings for all mail clients, in all popular operating systems and mobile devices. So, we are able to usually give a resolution in as little as 10 minutes.

[ Is your business getting affected by lost or delayed mails? Get our professional help to fix your email errors. ]

4. When an external party fails your server’s spam check

If users are unable to receive mails from an external party, it is possible that their servers failed an anti-spam check. We check the details from the mail server logs and get it resolved by contacting the remote mail server administrators.

5. When the mail server is broken

It is possible that the user authentication system might be broken in the mail server, or your mail was tagged as spam. More on that is described in the section above.

Mail service is perhaps the most important online service that aids day-to-day business transactions. A contract that needs to be signed, a quote that needs to be sent, market trend data that needs to be presented – none of these can wait – We know!

That is why Bobcares engineers give high priority in resolving email errors. We use server logs, user reports and test routines to quickly identify the cause of mail errors, and fix them in as little as 10 minutes. If you’d like to know how you can better support your mail users, we’d be happy to talk to you.

Messages from localhost is working normally, but when I try to send mail from i.e. gmail to my domain (as in virtual domain mapping) postfix is denying it with error (554 5.7.1 : Client host rejected: Access denied).

main.cf:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = ***

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = *** my hostname ***
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, $mydomain, localhost
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous noplaintext
smtpd_tls_security_level = may

virtual_alias_domains = *** my virtual alias domains ***
virtual_alias_maps = hash:/etc/postfix/virtual
smtpd_tls_auth_only = yes

smtpd_client_restrictions = permit_mynetworks, reject
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, permit
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_end_of_data_restrictions = check_policy_service unix:private/policy
smtp_sasl_auth_enable = no
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, hash:/etc/postfix/sender_access, permit
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, check_helo_access hash:/etc/postfix/sender_access, reject_non_fqdn_hostname, reject_invalid_hostname, permit
smtpd_recipient_restrictions = reject_unauth_pipelining, reject_unauth_destination, reject_non_fqdn_recipient, permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/sender_access, reject_rbl_client relays.ordb.org, reject_rbl_client list.dsbl.org, reject_rbl_client sbl-xbl.spamhaus.org, check_policy_service unix:private/spfpolicy, check_policy_service inet:127.0.0.1:10023, permit
transport_maps = hash:/etc/postfix/transport

This morning, in order to correct a problem with a name mismatch in the security certificate, I followed the recommended steps from How to fix mail server SSL?, but now, when attempting to send an email from a client (in this case the client is Windows Mail), I receive the following error.

The rejected e-mail address was
’email@gmail.com’. Subject ‘This is a
test. ‘, Account: ‘mail.domain.com’,
Server: ‘mail.domain.com’, Protocol:
SMTP, Server Response: ‘554 5.7.1
: Relay access
denied’, Port: 25, Secure(SSL): No,
Server Error: 554, Error Number:
0x800CCC79

Edit: I can still retrieve emails from this account, and I send emails to other accounts at the same domain. I just can’t send emails to recipients outside of our domain.

I tried disabling TLS altogether but no dice, I still get the same error.

When I check file mail.log, I see the following.

Jul 18 08:24:41 company imapd: LOGIN, user=user_name@domain.com, ip=[::ffff:111.111.11.11], protocol=IMAP
Jul 18 08:24:42 company imapd: DISCONNECTED, user=user_name@domain.com, ip=[::ffff:111.111.11.11], headers=0, body=0, rcvd=83, sent=409, time=1
Jul 18 08:25:19 company postfix/smtpd[29282]: connect from company.university.edu[111.111.11.11]
Jul 18 08:25:19 company postfix/smtpd[29282]: NOQUEUE: reject: RCPT from company.university.edu[111.111.11.11]: 554 5.7.1 <email@gmail.com>: Relay access denied; from=<user_name@domain.com> to=<email@gmail.com> proto=ESMTP helo=<UserPC>
Jul 18 08:25:19 company postfix/smtpd[29282]: disconnect from company.university.edu[111.111.11.11]
Jul 18 08:25:22 company imapd: DISCONNECTED, user=user_name@domain.com, ip=[::ffff:111.111.11.11], headers=13, body=142579, rcvd=3289, sent=215892, time=79

File main.cf looks like this:

#
# Postfix MTA Manager Main Configuration File;
#
# Please do NOT edit this file manually;
#

#
# Postfix directory settings; These are critical for normal Postfix MTA functionallity;
#

command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
program_directory = /usr/lib/postfix

#
# Some common configuration parameters;
#

inet_interfaces = all
mynetworks = 127.0.0.0/8
mynetworks_style = host

myhostname = mail.domain.com
mydomain = domain.com
myorigin = $mydomain

smtpd_banner = $myhostname ESMTP 2.4.7.1 (Debian/GNU)
setgid_group = postdrop

#
# Receiving messages parameters;
#

mydestination = localhost, company 
append_dot_mydomain = no
append_at_myorigin = yes
transport_maps = mysql:/etc/postfix/transport.cf

#
# Delivering local messages parameters;
#

mail_spool_directory = /var/spool/mail
mailbox_size_limit = 0
mailbox_command = procmail -a "$EXTENSION"

biff = no

alias_database = hash:/etc/aliases

local_recipient_maps =

#
# Delivering virtual messages parameters;
#
virtual_mailbox_maps=mysql:/etc/postfix/mysql_virt.cf
virtual_uid_maps=mysql:/etc/postfix/uids.cf
virtual_gid_maps=mysql:/etc/postfix/gids.cf
virtual_mailbox_base=/usr/local/virtual
virtual_maps=mysql:/etc/postfix/virtual.cf
virtual_mailbox_domains=mysql:/etc/postfix/virtual_domains.cf


#
# SASL paramters;
#
smtp_use_tls = yes
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s

smtp_tls_CAfile = /etc/postfix/ssl/smptd.pem
smtp_tls_cert_file = /etc/postfix/ssl/smptd.crt
smtp_tls_key_file = /etc/postfix/ssl/smptd.key

smtpd_tls_CAfile = /etc/postfix/ssl/smptd.pem
smtpd_tls_cert_file = /etc/postfix/ssl/smptd.crt
smtpd_tls_key_file = /etc/postfix/ssl/smptd.key

smtpd_sasl_auth_enable = yes

smtpd_sasl_security_options = noanonymous

smtpd_sasl_local_domain =

broken_sasl_auth_clients = yes

smtpd_sender_restrictions =
        permit_sasl_authenticated
        permit_mynetworks

smtpd_recipient_restrictions =
        permit_sasl_authenticated
        check_recipient_access hash:/etc/postfix/filtered_domains
        permit_mynetworks
        reject_unauth_destination

As a side note, my employer wants to be able to send emails from clients (Thunderbird and Outlook) both from within our local network and outside it.

The key to understanding your problem is the following two lines.

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth_destination
mynetworks = 127.0.0.0/8 [::1]/128

mynetworks lists only localhost, and there is nothing in your connection transcript to indicate that you are connecting to localhost (in fact, there’s plenty to indicate that you are not). And you are not authenticating through SASL.

So you are almost certainly hitting the reject_unauth_destination at the end, meaning that the mail transaction is denied.

Either connect to your mail server over the loopback interface, or augment mynetworks to include the IP address you are connecting from, or authenticate to the mail server using SASL. Then relaying will work much better.

Also, a good place to start for these matters is often the server’s logs. It is rare that they don’t include details about why the mail transaction was denied, and they will often point you toward a solution.