"Relay access denied" is a mail server doing exactly what it was built to do. A server that accepts mail from anyone and forwards it to anyone is called an open relay, and open relays were once the main way spammers sent millions of messages. Today every well-run server refuses that job. It accepts messages for the domains it hosts, and it relays messages to other domains only for clients that have proved who they are, by logging in or by connecting from a trusted address. When you see 554 5.7.1 Relay access denied, 550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain, 550 relay not permitted or 553 sorry, that domain isn't in my list of allowed rcpthosts, the server is telling you that you asked it to deliver to a domain it does not host and it does not consider you an allowed sender. This guide explains the rule, the five usual causes, how to fix each of them in the common mail servers and in applications, and how to avoid the opposite error of making your own server an open relay.
Local delivery and relay: the difference
When your message arrives at a server, the server looks at each recipient. If the recipient's domain is one the server is responsible for, it delivers the message to a mailbox. That is local delivery, and it is allowed from anyone, because receiving mail is the server's purpose. If the recipient's domain belongs to somebody else, the server would have to pass the message on. That is relaying, and it uses the server's own reputation, bandwidth and IP address, so it is allowed only for permitted clients. The error occurs at the RCPT TO step: the first recipient that is outside the server's domains is refused, and the server cannot see any reason to trust the sender.
The five usual causes
1. The client did not authenticate
This is the most common cause on a modern service. The server relays for authenticated users, but the application connected and sent without logging in. Turn on SMTP authentication and supply the credentials. If you also see the "must issue a STARTTLS command first" form of the error, fix the encryption first; see SMTP 530 5.7.0.
2. You are using the wrong server
You pointed the application at the incoming mail server of your mailbox provider, or at your website host's internal mail server, instead of at a server that is meant to relay outbound mail. Incoming servers are set up to accept mail for their own domains only. Use the submission host and port your sending service gives you, normally port 587 or 465. If you are choosing a service, SMTP servers and SMTP services compared explains the options.
3. The connection comes from an address the server does not trust
Some servers relay for clients on a trusted network instead of requiring a login. If your device or application moved to another network, got a new IP address or goes through a NAT or proxy, it falls outside the allowed range. Either authenticate, or add the new address to the allowed list. Only do this for addresses that you control, and keep the list as short as possible.
4. The sender domain triggers an internal-only rule
Some Exchange and Microsoft 365 setups reject mail from outside when the From address uses one of the organisation's own domains, because the system treats the message as spoofing or as an internal message that arrived from outside. The error text may be 550 5.7.54 Unable to relay recipient in non-accepted domain or 550 5.7.64 TenantAttribution style messages. The fix is to use a connector or an authenticated send path that Microsoft recognises for that sender; see which Microsoft 365 sending option to use.
5. A configuration mistake on the server
If you run the server, the restriction list may be misordered, a network range may be missing, or the SASL login may be misconfigured so that valid users are not recognised as authenticated. These are the cases to fix in the server configuration, and they are covered next.
Fixing it on common servers
Postfix
Postfix decides in smtpd_recipient_restrictions. A safe order lists permit rules for trusted clients and authenticated users first, then rejects unauthorised destinations:
# /etc/postfix/main.cf
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_tls_auth_only = yes
mynetworks = 127.0.0.0/8 [::1]/128If you changed these and a legitimate client still gets "Relay access denied", check that permit_sasl_authenticated comes before reject_unauth_destination, that SASL is enabled for the port the client uses and that the client really authenticates (the log line shows sasl_username=). Keep mynetworks narrow. Never set it to 0.0.0.0/0. If Postfix is the sending side and a remote relay refuses it, the issue is in how Postfix logs in; see configuring Postfix to relay through an authenticated host.
Exchange and Microsoft 365
On Exchange, relay is controlled by receive connectors and their permissions. Applications and devices that cannot authenticate need a dedicated connector scoped to their IP addresses, with relay permission granted deliberately, instead of changing the default connector. In Microsoft 365, choose between authenticated client submission, direct send for internal recipients only, and an SMTP relay through a connector tied to your IP address. Using direct send to reach external recipients produces the 5.7.54 error.
Exim and other servers
Exim reports "relay not permitted" when a recipient is outside its local domains and the client has no relay permission. Check the host lists used in the ACLs, and the authenticator definitions. On shared hosting control panels, the setting is often "Authentication required to send" or "Require SMTP authentication for local domains", and the symptom is that a script on another server cannot use this host as a relay. Use the provider's outgoing server, with login, instead.
Applications, plugins and devices
For applications, the settings that matter are the host, the port, the security mode and the credentials. Printers and scanners often have a "no authentication" option aimed at an internal relay; if you have no such relay, choose a service that accepts authenticated submission and enter the user name and password, or run a small local relay as described in sending email from the Linux command line.
Confirm with a manual test
openssl s_client -starttls smtp -crlf -connect smtp.example.com:587
EHLO test.example.com
AUTH LOGIN
(user name in base64, then password in base64)
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
QUITIf RCPT TO for an outside address is accepted after authentication and refused before it, authentication was the missing piece. The steps for testing with swaks, which handles encoding for you, are in how to test an SMTP connection.
Do not fix it by opening the relay
A tempting shortcut is to tell the server to accept everything. Do not. An open relay is found by scanners within hours, abused to send spam and phishing in your name and then listed on blocklists, after which even your legitimate mail is rejected. Fixing that costs far more than fixing the original error. If you run a server, test it from outside your network after every change with a tool that tries to relay a message to an external address, and expect the answer "relay denied". The guide to checking blocklists explains how to see whether you were listed.
Troubleshooting table
| Symptom | Likely cause | Fix |
|---|---|---|
| Error on the first external recipient, local recipients work | Client not authenticated or not trusted | Authenticate, or add the trusted address |
| Works from the office, fails from home or a cloud host | Trust depends on source IP | Authenticate instead of relying on the IP |
| Error right after a password or security change | Account locked or authentication disabled | Re-enable submission for the account and re-test |
| Only some recipients fail | Those recipients are in domains the server treats as local but cannot find | Check accepted domains and routing |
| Fails only for messages From your own domain (Microsoft 365) | Internal-domain rule on an unauthenticated path | Use authenticated submission or a connector |
| Authentication succeeds but still denied | Restriction order wrong in the server | Put authenticated permit before the reject rule |
If authentication is the problem and the login is refused after you provide it, see SMTP error 535.
A relay that is meant to relay Authenticated submission on ports 587 and 465, so your applications never depend on an open relay.
References and further reading
Frequently asked questions
What does relay access denied mean?
The server was asked to deliver to a domain it does not host and does not trust the sender to use it as a relay. Authenticate or use a server that relays for you.
How do I fix 554 5.7.1 relay access denied?
Enable SMTP authentication with valid credentials on the submission port, use the correct outgoing host, or add your trusted network address if you run the server.
Is relay access denied a sign that I am blocked?
Not usually. It is a configuration rule. It is about permission to relay, not about your reputation.
What does 550 5.7.54 unable to relay mean?
Exchange or Microsoft 365 refused to relay to a recipient in a domain it does not accept for your connection. Use authenticated submission or the correct connector.
Should I allow relay for all addresses to fix the error?
No. That creates an open relay, which is quickly abused and leads to blocklisting. Authenticate users or trust only specific addresses.