A 554 5.7.1 relay access denied error means the SMTP server refused to forward your message to an external domain because you weren't authenticated or weren't on its list of permitted senders. Mail servers only relay for clients they trust. Log in with SMTP AUTH on port 587, or if you run the server, permit the sending IP or require authentication. It's an authorization failure, not a reputation or content problem.
What does 554 5.7.1 relay access denied mean?
The string usually reads 554 5.7.1 <[email protected]>: Relay access denied. Relaying is when a server accepts your message and forwards it on to a domain it doesn't host. Servers refuse to do that for just anyone, because an open relay gets abused by spammers within hours. So the server says: I'll only relay if you prove you're allowed to.
The "5.7.1" enhanced code, defined in the SMTP standard, RFC 5321, means "delivery not authorized, message refused." It's permanent. The server isn't asking you to retry. It's telling you that, as you connected, you have no right to use it as a relay.
Why am I getting relay access denied?
Relay denied comes from a handful of authorization gaps. The split between internal and external recipients is the biggest clue.
| Cause | What's happening |
|---|---|
| No SMTP authentication | You connected and sent without logging in, so the server treats you as an untrusted client |
| Sending to external domains | The server accepts its own domains but won't relay to outside recipients without auth |
| Sending IP not permitted | On self-hosted servers, your IP isn't in mynetworks or the permitted relay list |
| Wrong port | Sending on port 25 (server-to-server) instead of 587 (authenticated submission) |
| Auth not offered before STARTTLS | The server only allows AUTH after encryption, and your client skipped it |
If mail to your own domain works but mail to Gmail bounces with 554 5.7.1, that's the tell: the server hosts your domain so it accepts those without auth, but it won't relay to outsiders until you log in.
The pattern we hit most often in client setups is an app library that silently falls back to port 25 when the STARTTLS handshake on 587 fails. The credentials are correct, the password is right, but the connection never reaches the AUTH stage, so Postfix sees an anonymous session and returns 554 5.7.1 on the first external RCPT TO. Pin the port and require TLS explicitly and the bounce disappears.
How do I fix 554 5.7.1 relay access denied?
If you're a client sending through someone else's server, the fix is almost always authentication.
- Turn on SMTP authentication. In your mail client or app config, enable "My server requires authentication" and enter valid credentials.
- Use port 587 with STARTTLS. This is the submission port built for authenticated clients. See SMTP ports 25 vs 465 vs 587 vs 2525 for the differences.
- Confirm the login succeeds. A failed login shows as 535 authentication failed, not 554. Fix that first if you see it.
- Check the username and password. Use the exact credentials the provider issued, in the format they require (often the full email address).
If you run the server yourself (Postfix, for example), the fix is on the server side.
- Require SMTP AUTH for relaying. Set
smtpd_relay_restrictions = permit_sasl_authenticated, reject_unauth_destinationso authenticated clients can relay and nobody else can. - Add trusted IPs to
mynetworks. Only for application servers on your own network. Never add public ranges, that creates an open relay. - Reload and test. Our Postfix relay access denied fix covers the exact config lines.
How do I confirm relaying works now?
After authenticating, send one test message to an external address like a Gmail account you control. A 250 2.0.0 Ok: queued reply means the server accepted the relay. If you still get 554 5.7.1, your client isn't actually authenticating, so check that AUTH happens before the MAIL FROM command, not after.
You can prove the AUTH step manually with swaks or a raw session. A correct authenticated submission looks like this:
EHLO client.example.com
STARTTLS
AUTH LOGIN -> 235 2.7.0 Authentication successful
MAIL FROM:<[email protected]> -> 250 2.1.0 Ok
RCPT TO:<[email protected]> -> 250 2.1.5 Ok
If the 235 authentication success line is missing and you jump straight to MAIL FROM, the server treats you as anonymous and returns 554 5.7.1 on the RCPT TO. That's the smoking gun: no 235, no relay.
Prevent relay access denied from recurring
Relay denied recurs when credentials, ports, or server config drift. Lock each one down.
- Store credentials in the app config, not a person's head. A rotated or mistyped password silently breaks AUTH and the symptom looks like a relay problem.
- Pin port 587 with STARTTLS. Apps that fall back to port 25 lose authenticated submission and get denied.
- On self-hosted Postfix, keep restrictions tight.
smtpd_relay_restrictions = permit_sasl_authenticated, reject_unauth_destination. Never widenmynetworksto public ranges, that creates an open relay. - Monitor for auth failures. A spike in 535 authentication failed often precedes a wave of relay-denied bounces from the same broken credential.
How BulkEmailSetup helps
A dedicated SMTP server gives you authenticated relay configured correctly, so your app or client logs in once and sends to any domain without tripping 554 5.7.1. No open-relay risk, no guesswork about permitted networks. See plans on our pricing page.
Frequently asked questions
What does 554 5.7.1 relay access denied mean?
It means the SMTP server refused to relay your message to an external domain because you weren't authenticated or weren't authorized to use it as a relay. The server only accepts mail for its own domains unless you log in first.
How do I fix relay access denied?
Enable SMTP authentication in your client, use port 587 with STARTTLS, and log in with valid credentials before sending. If you run the server, add the sending IP to the permitted networks or require SMTP AUTH for relaying.
Why does relay denied happen only for some recipients?
Because the server accepts mail for its own hosted domains without auth but refuses to relay to outside domains. Internal recipients work; external recipients trigger 554 5.7.1 until you authenticate.
Is 554 5.7.1 the same as being blocklisted?
No. Relay denied is an authorization problem on the sending server, not a reputation block at the receiver. A blocklist rejection usually reads 550 5.7.1 with a blocklist URL, not relay access denied.
