554 5.7.1 Relay access denied: what is refusing you and how to fix it
554 5.7.1 Relay access denied means a server will not carry your message to that recipient because you are not logged in or trusted. Check port, login, domain.
On this page(9 sections)
- What does "554 5.7.1 Relay access denied" mean?
- Which server said it?
- Why does the wrong port cause it?
- Why does a missing login cause it?
- Why does a trusted-network setting cause it?
- Why does the recipient's domain cause it?
- A short order of checks
- How does this look when sending through Koltrix?
- Bottom line
Your app, printer or mail client tries to send a message and gets "554 5.7.1 Relay access denied" back. Nothing was delivered, and the text does not say what to change. The cause is almost always one of four things: you reached the wrong server, you reached the right one without logging in, the server does not trust where you connected from, or the recipient's domain is not one the server handles.
This guide explains what the error states, how to tell which of the four you have, and a short order of checks that finds it in a few minutes.
What does "554 5.7.1 Relay access denied" mean?
It means the SMTP server you spoke to refused to accept a message for a recipient on another domain, because it only does that for senders it has authenticated or trusts. SMTP (Simple Mail Transfer Protocol) is the protocol servers and clients use to hand mail along. Relaying is a server accepting a message for a recipient that is not one of its own users and passing it on toward their mail server.
The two numbers are separate. 554 is the basic reply code from RFC 5321, a permanent "transaction failed". 5.7.1 is the enhanced status code from RFC 3463, where class 5 is permanent failure and subject 7.1 is "delivery not authorized, message refused". The words "Relay access denied" are the server's own text, and Postfix is one well-known server that uses that exact phrase.
A server that relayed for anyone would be an open relay and a spam source, so refusing is the correct default. The error usually appears at the RCPT TO step, before any message content is sent, so the cause is who you are and where you connected, not what you wrote.
Which server said it?
Find the answer in the bounce or the client log before changing anything, because the fix depends on the server.
| Where you see it | What it usually means |
|---|---|
| Straight from your own client or app, in the SMTP session | The server you configured would not relay for you. Fix the connection settings. |
| In a bounce from a mail server you did not configure | A hop on the way, or the recipient's server, said it. The recipient domain may point at the wrong server. |
| Only for one recipient domain | That domain's MX records point at a server that is not set up to accept mail for it. Not your fault, but you can confirm it. |
| For every recipient | Your login, port or trusted-network setup. |
The session log shows it plainly. A refused submission looks like this:
RCPT TO:<[email protected]>
554 5.7.1 <[email protected]>: Relay access deniedA refusal at RCPT TO that names the recipient points at relay policy. Compare it with a refusal at MAIL FROM, such as 553 5.7.1 Sender not authorized, which is about the sender address and a different fix.
Why does the wrong port cause it?
Port 25 is for server-to-server delivery, and submitting from an application belongs on a submission port with login, so connecting to the wrong one is the most common cause. Under RFC 6409, message submission uses port 587, and RFC 8314 describes port 465 with TLS from the first byte. A server listening on port 25 expects other mail servers and applies relay rules to you as if you were a stranger.
If you point a client at a company mail server's port 25 from outside the office network, the server sees an unauthenticated stranger asking it to deliver to a third party, and answers with this error. Move the client to the provider's submission port and enable login. Our guide to SMTP ports 25, 465, 587 and 2525 lists which port goes with which security mode.
Why does a missing login cause it?
Because relaying is allowed for authenticated users, a client that connects to the right port but never logs in is treated like any other stranger. Many clients skip login without a visible error when the box is unticked or the credentials field is empty, and the first sign is this bounce.
Check three things:
- Authentication is enabled in the client, with a username and password the server accepts.
- The client upgrades with
STARTTLSbefore logging in. Many servers do not offerAUTHuntil the connection is encrypted, so a client that skips the upgrade never sees a login option. - The login actually succeeded. A
235reply means authenticated. If the log shows535instead, you have a different problem, covered in the guide to 535 5.7.8 username and password not accepted.
You can test the sequence by hand with openssl and see exactly where it stops:
openssl s_client -starttls smtp -connect mail.example.com:587 -crlf
EHLO test.example.net
# look for "250-AUTH" in the reply; if it is absent, login is not offered yetWhy does a trusted-network setting cause it?
Some servers relay without a login for clients on a trusted list, such as the office network or the application server, and refuse everyone else. If an app worked from one machine and fails from another, or worked until its IP address changed, the trusted list is the likely cause.
In Postfix, relay policy for the SMTP server is set by smtpd_relay_restrictions, whose documented default permits mynetworks and authenticated clients and defers other destinations. See the Postfix parameter reference. Exchange, Microsoft 365 connectors and hosted relays have their own equivalents, usually an allowed-IP list or a connector bound to specific addresses.
Two cautions. Do not add a wide range such as everything on the internet to a trusted list, because that creates an open relay. And prefer login over IP trust where you can, since addresses change and shared hosting or NAT puts many machines behind one address.
Why does the recipient's domain cause it?
If the server answering for a domain does not recognize that domain, it refuses mail for it, and the result looks the same as a policy refusal. This is typical after a domain moves between providers, or when its MX records still point at an old host.
Look up where the domain says mail should go:
dig +short MX example.comIf the result names a host that no longer runs mail for the domain, the fix sits with whoever manages the recipient's DNS. For your own domains, confirm the MX records point at the provider that hosts the mailboxes. Microsoft 365 has a related case where a connector rejects mail from your tenant, described in the post on 550 5.7.64 TenantAttribution.
To see which hop actually refused, read the headers and the bounce path. Our guide to tracing delivery with Received headers shows how.
A short order of checks
- Read the full reply and note whether it came from your server or a remote one.
- Confirm the host and port are your provider's submission settings, not port 25 on a server that is not yours.
- Turn on authentication and
STARTTLS, and confirm a235reply. - If you rely on a trusted network, confirm the sending IP is on the list.
- For one failing recipient domain, check its MX records.
- Retry with a verbose client log and read the step where it fails.
How does this look when sending through Koltrix?
Koltrix gives you two ways in. The REST API is POST https://api.koltrix.com/api/v2/emails with an API key, and it returns errors as JSON, so there is no relay policy to trip over. The SMTP relay is smtp.koltrix.com on port 2525 with STARTTLS, with username apikey and an API key with the send scope as the password. Ports 587 and 465 on that host are not the relay and do not accept API keys. Sending MAIL FROM before login is answered with 530 5.7.0 Authentication required. Details are in the SMTP relay documentation.
If a bounce for a Koltrix message says "Relay access denied", it came from the recipient's side, so the message log shows it as a bounce from that domain's server rather than a setting in your workspace. Check that domain's MX records, then retry later in case it is mid-migration. For choosing between the two sending routes, see SMTP relay vs HTTP API.
Bottom line
"554 5.7.1 Relay access denied" is a server declining to carry your message for a recipient on another domain. Check in this order: port, login and STARTTLS, the trusted-network list, then the recipient's MX records. The first two explain most cases from applications and printers. If only one recipient domain fails, the problem is on their side and your settings are fine.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
