Quick way to resolve Relay Access Denied email error

Relay Access Denied is a relatively standard error. It indicates that the server is not letting an email be sent to another mail server.

The most common reasons for this error are:

• The sender did not authenticate to the outgoing mail server due to some misconfigurations
• The recipient's server has determined the sender's server to be a source of spam, or that it has failed security checks

Reasons for getting a relay access denied error

Firstly, let's take a look at the entire process of sending an email. When you send an email, your email client forwards the email to your own mail server. Then your mail server transmits it to the recipient's relay email server.

After that, their email server delivers the email to the recipient.

So there are 2 servers (aka MX) involved - sender’s MX and recipient’s MX. If one of these servers rejects the mail, then the sender will see the Relay Access Denied error.

Case 1 - Sender’s MX rejects the email

Before the email is actually sent, the sender's MX server asks for a username and password to send emails. If your MX can’t successfully authenticate you before sending the email, it will deny the email from being relayed to the recipient’s MX.

Why does it happen? Such precautions are taken to keep spammers out, so they can’t send mail using your server without proper credentials. Sometimes it happens even with trustworthy email users if they forget to turn on the appropriate authentication in their mail clients.

Case 2 - Recipient’s MX rejects the mail

If the email was successfully sent from the sender’s MX, then the issue might appear with the recipient’s MX. It will accept mail only if:

• The Sender’s MX passed all security checks/spam filters
• The recipient’s MX doesn’t have any misconfigurations

The most common misconfigurations on the recipient’s MX are:

• SMTP authentication settings are disabled
• The recipient’s email is invalid/inactive/cancelled
• DNS MX records are pointing to the wrong server
• MX has some database errors

Solution for Relay Access Denied error on the user side

First, contact your email service provider for assistance and verify your email settings with them. You will need to check that you have proper credentials, such as the Mail Server address, Username, and Password. Further, verify whether or not you should use SMTP Authentication, moreover it might be that you need to use POP before SMTP you should also consider this point by verifying settings with your email provider.

So, if you are using POP before SMTP, you may run into occasional problems with mobile devices. This is caused by your data network changing due to reduced coverage, whether you're switching between different WiFi hotspots.

In such case, your IP address may be changing, as a result, you will send an email from a new IP address instead of the IP address you first authenticated with. To counter this issue, try switching to SMTP Authentication. This will let you test whether your email provider has enabled this feature as well. If it fails, then you should reach out to your email provider and request that they enable SMTP Authentication on the mail server.

And lastly, there is always a possibility that spam filters will activate on the recipient's server. If so, you should ask your email provider to review the mail server's log files and provide more information on how to resolve this issue.

Solution for Relay Access Denied error on the mail server side

There are two most common situations in which a server owner may face such or similar errors:

• The first one, when end users attempt to send an email, they may receive and send this error in a bounce back
• The second one, a person trying to send an email to a user on your server gets an error and they report it to you

You should find something close to this message in your log files.

shell
12018-10-30 15:22:23 1brcGf-0006ac-Mf ** example@address.com
2R=dkim_lookuphost T=dkim_remote_smtp H=exampleserver.com [192.168.0.1]
3X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
4CV=yes: SMTP error from remote mail server after RCPT
5TO:&LTexample@address.com>: 554 5.7.1
6&LTexample@addrss.com>: Recipient address rejected: Access denied

Moreover, pay attention to the error code. We have noticed a couple of versions of that error:

• 554 5.7.1 Relay Access Denied – You can see this error code in the recipient's mail server logs when an email is rejected.
• 454 4.7.1 Relay Access Denied – This error code is observed inside server logs when the recipient server is temporarily incapable of receiving emails. In such a case, another attempt to send the mail will be made later.

Case 1 - User authentication failed

If all your end users began receiving this error, then it's most likely this case. You should review the server authentication configurations. For example, if you are using a Postfix server, you must ensure that SMTP authentication is enabled.

To do this, check the configuration file and make sure that the “smtpd_recipient_restrictions” is configured as follows:
smtpd_recipient_restrictions = permit_sasl_authenticated

From time to time, when updating server software, there is a possibility that it will change configurations. Therefore, if your mail server was running smoothly all the time, and then it suddenly stopped, most likely the reason is the latest software update.

For example, cPanel control panel automatically checks for updates during nighttime. Sometimes, new updates that have just been rolled out can break everything. In such a situation, you can either wait for a new update or manually change some settings.

If you are used to updating your server manually, you should consider setting up a test server that mirrors your live server. Using such a test server to check updates first is a good practice. Next, if everything works as expected in your test environment, you can proceed to roll it out to your live environment.

Case 2 - Authentication database is corrupted

On servers similar to Plesk usernames, passwords, and authenticated IP addresses are stored in the database. Like any other database, this can become corrupted for numerous reasons. But you can always rely on a simple command line to restore a table:

shell
1mysqlcheck -r psa smtp_poplocks -uadmin -p

This command will perform the check of the table called "smtp_poplocks" and fix it if it turns out that it's broken.

Case 3 - External mail server failed anti-spam check on your server

Such a situation may occur when someone is sending an email to your end users and the sender's emails may be rejected by spam filters configured on your mail server. In this case, you'll probably find such entries in your mail logs:

shell
12022-09-09 14:05:23 H=(myserver.com) [xx.xx.xx.xx] sender verify fail for &LTmyuser@mydomain.com>:
2response to "RCPT TO: &LTmyuser@mydomain.com>"
3from senderserver.com [yy.yy.yy.yy] was: 554
4&LTmyuser@mydomain.com>: Relay access denied
52016-10-10 14:05:23 H=(myserver.com) [xx.xx.xx.xx] F=&LTmyuser@mydomain.com> rejected RCPT
6&LTsenderuser@senderdomain.com>: Sender verify failed

This happens due to Sender Verification Callout or simply Sender Verify spam rule. And it indicates that examplesrv.com rejected an email from sendersrv.com based on this rule.
There are three possible ways to resolve such an issue:

• You should investigate mail logs. If this happens with trustworthy mailbox and emails from this address are blocked due to anti-spam check too often. Then it's better to consider updating and disabling that anti-spam rule.
• If you are sure that the server which is sending the email is totally trustworthy, you can simply whitelist this server. But use this with caution, because this will allow all emails from that server to pass through without any anti-spam checks. So, if by any chance the whitelisted server will be hacked and used to send spam, then all that spam will pass through your server.
• Reach the owner of the sending email server, and request him to re-configure his server in such a way as to be compliant to your anti-spam rules and checks.

Every mail server should have anti-spam checks enabled. But, you should also consider that if you'll be too offensive with those checks. Then some of your customers may lose important emails. So, we suggest sticking to the IETF | RFC's compliant spam checks, which are a reference for most server owners and users.

Case 4 - Anti-spam rules on the recipient server are bouncing back your user's emails

If your end users are sending emails and in response, they are receiving them back with such an error code:

• 454 4.7.1 : Relay access denied

Most likely that your server is not passing the recipient's server anti-spam rules and checks. As well as it may get on the firewall blacklist on the recipient's side.

In such a situation you should firstly review the headers of the bounced emails. It should bring you more details and info on why the email was rejected. Usually, it’s provoked when your server gets on RBL’s (Real-time Blackhole List). Such sites as MxToolbox and MultiRBL will help you to figure this out and check if your server is located in blacklists.

Info that you will get from those sites will tell you about any blacklists that you may be on and usually refer to these RBL's, so you can request them to delist you from those RBL's.

However, before asking to delist your server you should make sure and resolve the origin of getting blacklisted. For example, if a spammer was detected on your server then you have to remove him before asking to remove your server from the blacklist.