# 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.

- Published: 2026-11-09
- Author: Koltrix Team
- Category: Email API
- Source: https://koltrix.com/blog/554-5-7-1-relay-access-denied-whats-refusing-you-and-how-to-fix-it

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](https://www.rfc-editor.org/rfc/rfc5321), a permanent "transaction failed". `5.7.1` is the enhanced status code from [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463), 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:

```text
RCPT TO:<lead@example.com>
554 5.7.1 <lead@example.com>: Relay access denied
```

A 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](https://www.rfc-editor.org/rfc/rfc6409), message submission uses port 587, and [RFC 8314](https://www.rfc-editor.org/rfc/rfc8314) 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](/blog/smtp-ports-25-465-587-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:

1. Authentication is enabled in the client, with a username and password the server accepts.
2. The client upgrades with `STARTTLS` before logging in. Many servers do not offer `AUTH` until the connection is encrypted, so a client that skips the upgrade never sees a login option.
3. The login actually succeeded. A `235` reply means authenticated. If the log shows `535` instead, you have a different problem, covered in the guide to [535 5.7.8 username and password not accepted](/blog/gmail-smtp-535-5-7-8-username-and-password-not-accepted).

You can test the sequence by hand with `openssl` and see exactly where it stops:

```bash
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 yet
```

## Why 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](https://www.postfix.org/postconf.5.html#smtpd_relay_restrictions). 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:

```bash
dig +short MX example.com
```

If 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](/blog/microsoft-365-550-5-7-64-tenantattribution-relay-access-denied).

To see which hop actually refused, read the headers and the bounce path. Our guide to [tracing delivery with Received headers](/blog/tracing-delivery-received-headers) shows how.

## A short order of checks

1. Read the full reply and note whether it came from your server or a remote one.
2. Confirm the host and port are your provider's submission settings, not port 25 on a server that is not yours.
3. Turn on authentication and `STARTTLS`, and confirm a `235` reply.
4. If you rely on a trusted network, confirm the sending IP is on the list.
5. For one failing recipient domain, check its MX records.
6. 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](https://docs.koltrix.com/smtp-relay).

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](/blog/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.