How to correct 554 5.7.1 : Relay access denied email errors, and prevent them in the future

Relay Accessed Denied is a common email error. It means that the server is not allowing an email to be sent to another mail server. The most common causes of this error are:

• The sender did not authenticate to the outgoing mail server
• The recipients server has determined the senders server to be a source of spam, or that it had failed security checks

What exactly is a relay access denied error?
When you send an email, your email client sends the email to your own mail server. Your mail server then sends it on (Relays) to the recipients email server. Their email server then delivers it to the recipient.
If you do not successfully authenticate to your own outgoing mail server before sending the email, then your server will deny the email from being relayed on to the recipients server. This is done to keep a spammer from being able to send mail using your server without proper credentials.
If you do authenticate properly, you can still end up with this error however. The recipients server can deny the relay, if their spam filters have detected the email as spam, or as coming from a spam source (IE: your server is on a blacklist). If this happens, then their server rejects the email, and you will again get a relay access denied error.
What to do when you get this error as a user.
The first thing you should do is verify your email settings with your email provider. Make sure you have the proper Mail server, Username, and Password. Also, check whether or not you need to use SMTP Authentication, or if you need to use POP before SMTP.
If you are using POP before SMTP, you can run into sporadic issues with mobile devices. This is caused by your data network changing due to poor coverage, or if you change from one WiFi hotspot to another. What is happening is your IP address may be changing, so you are now sending email from a new IP address instead of the IP address you originally authenticated with. To prevent this, you can try switching to SMTP Authentication to test if your email provider has that enabled as well. If that fails, then you may need to contact your email provider and ask them to enable SMTP Authentication on the mail server.
Finally, there could be spam filters coming into play on the recipients server. If this is the case, you should have your email provider look through the mail servers log files to get more information on how to prevent this.

What to do when you are the owner of the mail server
There are 2 reasons a server owner may come across this.

• An end user tried to send an email, and they are sent this error in a bounce back
• A person trying to send an email to a user on your server is getting the error, and they have reported it to you

You should see something like this in your log files.
2016-10-10 14:05:23 1btaGg-0004ei-Mf ** [email protected] R=dkim_lookuphost T=dkim_remote_smtp H=someserver.com [192.168.0.1] X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes: SMTP error from remote mail server after RCPT TO:<[email protected]>: 554 5.7.1 <[email protected]>: Recipient address rejected: Access denied
The user authentication system could be failing
If ALL of your end users are getting this error, then this is the most likely case. You’ll need to check over the servers authentication configurations.
For example, if you were running a Postfix server, you should make sure that SMTP authentication is enabled. To do this, check the configuration file, and make sure that “smtpd_recipient_restrictions” is set like this

• smtpd_recipient_restrictions = permit_sasl_authenticated

Occasionally, when server software is updated, it can change configurations. So if your server has been running fine all along, then all of a sudden it stops, then likely the software has been updated recently. For instance, cPanel automatically checks for updates nightly. There have been times where they rolled out an update that has broken things, and either a new update is put out, or you need to manually change some settings.
If you are updating manually, you should look into having a test server setup that you can test your updates on first. Then if everything seems to run fine on your test server, you can roll it out to your live environment.

The authentication database could be corrupt
On servers like Odin Plesk, they store the username, password, and authenticated IP address in a database. That database, like any database could become corrupt for any number of reasons. You can repair the table with a simple command line.

• mysqlcheck -r psa smtp_poplocks -uadmin -p

This will check the table called smtp_poplocks and repair it if it’s broken.

3rd party mail coming to your server is failing anti-spam checks on your server
If your are receiving reports that someone is trying to email one of your end users, but the person sending the email is getting rejected by your servers spam filters, then you may see entries like this in your mail log
2016-10-10 14:05:23 H=(myserver.com) [xx.xx.xx.xx] sender verify fail for <[email protected]>: response to "RCPT TO:<[email protected]>" from senderserver.com [yy.yy.yy.yy] was: 554 <[email protected]>: Relay access denied
2016-10-10 14:05:23 H=(myserver.com) [xx.xx.xx.xx] F=<[email protected]> rejected RCPT <[email protected]>: Sender verify failed
This error indicates that myserver.com rejected an email from senderserver.com because of a spam rule called Sender Verify (Sender Verification Callout)
To correct this, here are 3 possible solutions

1. If this happens often to legitimate email, and is caused by the same anti-spam rule, then you may want to consider disabling that particular rule.
2. If the server sending the email is trustworthy, you can add their server to your servers whitelist. Use caution with this however, as this will allow all mail from their server through without any spam checks at all. So if their server is ever hacked, and used to send out spam to your server, all that spam will get through.
3. Contact the sending server, and request that they re-configure their server to make the server compliant to your anti-spam checks.

Anti-spam checks are something every server should have enabled, however being too aggressive can cause your clients to miss important emails. This is why it’s best to stick to the RFC compliant spam checks, as these are what a majority of service providers are configured with.

Your users are getting bounce backs due to anti-spam rules on the recipients server
If your end users are getting bounced email with an error message like this:

• 454 4.7.1 : Relay access denied

Then your server is likely failing the recipients server anti-spam rules or on their firewall blacklists.
If this is the case, then view the headers of the bounce email. It should give your details as to why it was rejected. Typically, it’s caused by your server ending up on RBL’s (Realtime Blackhole List). There are a couple of sites that you can check your server against many blacklists, such as http://mxtoolbox.com and http://multirbl.valli.org. These lists will tell you any blacklists that you may be one, and will often give links to those RBLS, so you can request delisting. Before you ever try to delist a server however, you should make sure that the cause of the blacklisting has been resolved. IE: if you have a spammer on your server, they have been removed.

The End user’s mail client is configured incorrectly.
Probably 80% of our calls and support tickets regarding email issues in general, not just relay denied errors, are caused by the customer having incorrect settings. If you are certain that your server is working fine, then you should go over the settings with your client to ensure they have everything configured correctly to work with your server.