Quick way to resolve Relay Access Denied email error

Find your exact error

If the bounce starts with 550 and talks about a user, a blocklist or SPF rather than relaying, it's a different error: see how to fix 550 permanent failure for one or more recipients.

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 isn't the final destination or an allowed relay for the recipient's domain, for example because the domain's MX records point to the wrong server

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 involved - the sender’s outgoing (SMTP/submission) server and the recipient’s incoming server (MX). If one of these servers rejects the mail, then the sender will see the Relay Access Denied error.

Case 1 - The sender’s outgoing server rejects the email

Before the email is actually sent, the sender's outgoing (SMTP) server asks for a username and password to send emails. If your outgoing server 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 outgoing server, then the issue might appear with the recipient’s MX. It will accept mail only if:

• The sender’s outgoing server 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:

• The recipient’s domain isn’t set up on the server as a local or virtual domain (mydestination, virtual_mailbox_domains) or as a relay domain (relay_domains)
• 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. Then make sure SMTP Authentication is turned on in your mail client.

In most mail clients, it's an option called "My outgoing server (SMTP) requires authentication" or similar. Use port 587 with STARTTLS or port 465 with SSL/TLS, and your mailbox username and password (usually the same as for incoming mail).

Where to find it:

If your provider still offers POP before SMTP, treat it as an outdated method: it ties sending to the IP address you last checked mail from, so it breaks as soon as your phone switches networks. Ask your provider to enable SMTP Authentication instead.

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. This is how it looks in a Postfix log (usually /var/log/mail.log or /var/log/maillog):

shell
1Oct 30 15:22:23 exampleserver postfix/smtpd[12345]: NOQUEUE: reject: RCPT from unknown[203.0.113.10]: 454 4.7.1 <example@address.com>: Relay access denied; from=<user@mydomain.com> to=<example@address.com> proto=ESMTP helo=<laptop>

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 - the same relay refusal, just with a temporary error code. Postfix sends it by default (defer_unauth_destination) when the client didn't authenticate, or when the server isn't the destination or an allowed relay for the recipient's domain. Retrying won't help. Turn on SMTP Authentication in the mail client, or fix the MX records and relay domains.

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 /etc/postfix/main.cf. SMTP authentication is turned on by smtpd_sasl_auth_enable, and relaying for authenticated users is allowed in smtpd_relay_restrictions (Postfix 2.10 and later). A typical setup with Dovecot SASL looks like this:

shell
1smtpd_sasl_auth_enable = yes
2smtpd_sasl_type = dovecot
3smtpd_sasl_path = private/auth
4smtpd_sasl_security_options = noanonymous
5smtpd_tls_auth_only = yes
6smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

If you use Cyrus SASL, set smtpd_sasl_type = cyrus instead. Keep in mind that smtpd_tls_auth_only = yes only offers authentication over TLS, so TLS must be configured on the server.
Don't put permit_sasl_authenticated alone into smtpd_recipient_restrictions. Postfix requires reject_unauth_destination (or defer_unauth_destination) in either smtpd_relay_restrictions or smtpd_recipient_restrictions, otherwise it refuses to receive mail.
Check which values are actually applied, then reload Postfix:

shell
1postconf -n | grep -E 'smtpd_(relay|recipient)_restrictions|sasl'
2postfix reload

Your users should send mail through port 587 (STARTTLS) or 465 (SSL/TLS) with their login and password.

That only works if Postfix listens on those ports. On a stock install both services are commented out in /etc/postfix/master.cf. Replace the commented blocks with these:

shell
1submission inet n       -       n       -       -       smtpd
2  -o syslog_name=postfix/submission
3  -o smtpd_tls_security_level=encrypt
4  -o smtpd_sasl_auth_enable=yes
5  -o smtpd_tls_auth_only=yes
6  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
7  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
8submissions inet n       -       n       -       -       smtpd
9  -o syslog_name=postfix/submissions
10  -o smtpd_tls_wrappermode=yes
11  -o smtpd_sasl_auth_enable=yes
12  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
13  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject

submission is port 587 with STARTTLS, submissions is port 465 with TLS from the first byte. Postfix before 3.7 and older guides call the second one smtps, which is the same port. The fifth column is chroot: Ubuntu 24.04 ships y there, Ubuntu 26.04 n; keep what your file has. TLS has to be configured (smtpd_tls_cert_file and smtpd_tls_key_file in main.cf), because smtpd_tls_auth_only offers login only after STARTTLS.

Run postfix check before postfix reload. We tested this on Ubuntu 26.04 with Postfix 3.10 and Dovecot 2.4: on port 587 the server offered login only after STARTTLS, a client that didn't log in got 554 5.7.1 Client host rejected: Access denied, and after login mail to an outside address was accepted on both 587 and 465.

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 - Broken relay settings or mail database

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.

Before touching the database, check the relay settings. In Plesk, go to Tools & Settings > Mail Server Settings and make sure that under Relay options, relay after authorization is selected ("authorization is required") with SMTP as the authorization method.
If the settings look right but users still get the error, let Plesk reconfigure the mail settings for all domains and mailboxes:

shell
1plesk repair mail

The utility runs in interactive mode: it tells you about each issue it finds and asks before fixing it. You can also run it for a single domain, for example plesk repair mail example.com.

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 (Exim format):

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

This happens due to Sender Verification Callout or simply Sender Verify spam rule. And it indicates that your server rejected an email from myserver.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 - The recipient server doesn't accept mail for the recipient's domain

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

It means the server that got the message doesn't consider itself the final destination or an allowed relay for the recipient's domain. Check where the domain's MX records point:

shell
1dig MX recipientdomain.com +short

Make sure they point to the right server. On that server, the domain must be listed as a local, virtual or relay domain. In Postfix, that's mydestination, virtual_mailbox_domains or relay_domains.

If the bounce says something else, like "blocked using ..." or "Client host rejected", 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 RBLs, so you can request that they delist you from those RBLs.

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.

Microsoft 365: 550 5.7.64 TenantAttribution

You see 550 5.7.64 TenantAttribution; Relay Access Denied SMTP when an on-premises server, a scanner or an app relays mail out through Microsoft 365, and Microsoft 365 can't match the connection to a connector in your tenant. According to Microsoft's article on this error, there are two causes:

• The inbound connector identifies your server by certificate, and the certificate your server presents no longer matches the one in the connector, for example after a renewal with a different name.
• The connector identifies your server by IP address, and the server now sends from a different IP.

To fix it, open the Exchange admin center, go to Mail flow > Connectors, and edit the connector from your organization's email server to Microsoft 365. Make the certificate name (TlsSenderCertificateName) match the certificate your server sends, or update the IP addresses. In a hybrid setup, Microsoft recommends rerunning the Hybrid Configuration Wizard and selecting the new certificate. The sender's domain must also be verified in your Microsoft 365 tenant; otherwise the bounce carries an extra ATT36 error.

A single app or device can log in instead: SMTP AUTH to smtp.office365.com on port 587 with a licensed mailbox. Microsoft turns SMTP AUTH with a password off by default for existing tenants at the end of December 2026, so for anything new use a connector or OAuth.

Exchange Server: relay for apps and devices

On-premises Exchange doesn't relay anonymous mail to outside domains. A printer, a monitoring system or an app that sends without logging in gets 550 5.7.1 Unable to relay.

Microsoft's documented fix is a dedicated receive connector that accepts relay only from the IP addresses of those devices (Allow anonymous relay on Exchange servers). In the Exchange Management Shell:

shell
1New-ReceiveConnector -Name "Anonymous Relay" -TransportRole FrontendTransport -Custom -Bindings 0.0.0.0:25 -RemoteIpRanges 192.168.5.10,192.168.5.11
2Set-ReceiveConnector "Anonymous Relay" -PermissionGroups AnonymousUsers
3Get-ReceiveConnector "Anonymous Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

Replace the IP addresses with your devices. Never add whole subnets you don't control: this connector is an open relay for every address in -RemoteIpRanges.

cPanel and Exim: Please turn on SMTP Authentication

On cPanel servers, Exim refuses a client that didn't log in with this message:

shell
1550 Please turn on SMTP Authentication in your mail client, or login to the IMAP/POP3 server before sending your message. mail.server.tld [198.51.100.0]:44583 is not permitted to relay through this server without authentication.

If you see it when sending, the fix is on the client side: turn on authentication for the outgoing server, use your full email address as the username, and send on port 587 or 465. If a website on the same server sends the mail, make it send through an authenticated SMTP account.

If the message comes back when someone sends mail to a domain hosted on that cPanel server, the server thinks the domain's mail lives elsewhere. cPanel's article on this error covers exactly that case: the domain is listed in /etc/remotedomains instead of /etc/localdomains. In cPanel, open Email Routing for the domain and select Local Mail Exchanger, if the mailboxes really are on this server.

If you run mail servers for other people

On a hosting server, Relay Access Denied usually shows up in waves: after a migration, a control panel update or a new batch of customers with old mail client settings. Catching that on the first ticket, not the fiftieth, is what managed infrastructure support is for. For a hosting company in Iceland, we run cPanel servers and mail around the clock. FTP users on the same servers hit a similar login problem: see how to fix 530 Login authentication failed.