Does 554 5.7.1 Relay Access Denied mean my mail was flagged as spam?

No, and this is the most common wrong turn. 554 5.7.1 is decided before content filtering ever runs — the server refused to *relay* the message, meaning it declined to forward mail it isn't responsible for. RFC 3463's enhanced status X.7.1 is 'Delivery not authorized, message refused': the sender isn't authorized to send through this server to this destination. Spam rejections use different codes — 5.7.1 can also carry a policy block, but 'Relay access denied' specifically is a routing-authorization refusal, not a reputation or content verdict. Reworking your subject line or warming up your IP does nothing here. The server never got far enough to judge the message; it refused to carry it at all.

I can send mail but incoming mail bounces with 554 5.7.1. Why?

Because there are two completely different failures wearing this one code, and yours is the inbound one. When *incoming* mail to your own domain bounces 554 5.7.1 Relay access denied, your mail server doesn't know it's supposed to accept mail for that domain. To the server, an address it isn't authoritative for looks exactly like a stranger asking it to relay to a third party — so it refuses. The domain is missing from the server's list of local or hosted domains (Postfix `mydestination`/`virtual_mailbox_domains`, Exchange accepted domains). The fix is on the *receiving* side: add the domain as one the server is responsible for. This is the opposite of the outbound case, where your client failed to authenticate before sending.

How is 554 5.7.1 different from 550 5.7.1?

They share the enhanced status 5.7.1 ('Delivery not authorized, message refused') but differ in the SMTP basic code, and the difference is a hint about timing. The 5xy basic code 554 is 'Transaction failed' — often returned at the end of the SMTP conversation, after the message body, and it's the classic wording for relay refusal ('554 5.7.1 Relay access denied', '554 5.7.1 Unable to relay'). 550 is 'Mailbox unavailable / action not taken', more often returned earlier at RCPT TO, and Microsoft's phrasing '550 5.7.1 Unable to relay' is the same relay-authorization problem in Exchange's dialect. Read them the same way: the server is refusing to carry mail it isn't authorized to carry. Check authorization — authentication for outbound, accepted domains for inbound — not the mailbox.

Views: 12

554 5.7.1 Relay Access Denied: Fix the Bounce

554 5.7.1 Relay Access Denied means a server refused to forward your mail. Find why in 3 checks: auth, MX, allowed senders. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Mail bounces with a permanent rejection carrying 554 5.7.1 and the words Relay access denied or Unable to relay. The message was refused outright — the server declined to forward it. This is not a spam verdict and not a missing mailbox. It’s an authorization refusal: the server decided it isn’t allowed to carry this particular message to this particular destination, and said so.

Symptoms

The bounce (NDR) reads 554 5.7.1 Relay access denied, 554 5.7.1 <address>: Relay access denied, or on Microsoft systems 550 5.7.1 Unable to relay.
Outbound: your own outgoing mail to external recipients bounces the moment you try to send through a particular server or SMTP host.
Inbound: mail to your domain bounces 554 5.7.1, even though the mailbox exists and other domains on the same server work.
A script or app that sends through an SMTP relay suddenly fails after a config change, a password rotation, or a move to a new host.
The same message sends fine through a different provider or from a different network.

What This Error Actually Means

“Relay” is the old word for the thing SMTP servers do: accept a message and forward it toward a mailbox they don’t host themselves. In the early internet, every server relayed for anyone — that’s how mail moved. Then spammers discovered that an open relay is a free, anonymous laundering service for junk mail, and the whole ecosystem slammed the door. Sendmail 8.9 in 1998 turned relaying off by default; every modern MTA followed. Today a server relays only for senders it trusts, and refuses everyone else with 554 5.7.1.

The enhanced status is RFC 3463’s X.7.1, “Delivery not authorized, message refused”: the sender is not authorized to send to the destination through this server. The 554 basic code is “Transaction failed” — a hard, permanent no. Retrying the identical message changes nothing.

The trap is that one error covers two mirror-image situations, and they have opposite fixes:

Outbound — You are trying to send through a server that doesn’t consider you a trusted sender. You skipped authentication, or you’re connecting from an IP the server doesn’t relay for. The server sees a stranger asking it to deliver to a third party and refuses.
Inbound — Someone is sending to your domain, but your server doesn’t know it’s responsible for that domain. To the server, a recipient it isn’t authoritative for is indistinguishable from a relay request to an outsider, so it refuses the same way.

Same words, same code, completely different root cause. Figure out which direction the failing mail is going before you touch anything.

Top 3 Causes

Outbound: no SMTP authentication (the classic case) — Your mail client or app connects to the sending server and tries to deliver to an external recipient without logging in first. Since the server only relays for authenticated users (Postfix permit_sasl_authenticated), an unauthenticated session gets 554 5.7.1. Usual triggers: SMTP AUTH turned off in the client, a wrong or rotated password, using port 25 (often reserved for server-to-server) instead of the submission port 587, or a service account whose credentials expired.
Outbound: sending from an IP the server won’t relay for — The server relays for a fixed set of trusted networks (Postfix mynetworks) and your source IP isn’t on it. This bites when an app moves to a new host, a NAT/egress IP changes, a cloud instance gets a fresh address, or a relay was locked to an office IP range that you’re now outside of. The message is legitimate; the sending IP just isn’t recognized.
Inbound: the recipient domain isn’t configured as local — Mail to your domain bounces because the receiving server has no entry making it responsible for that domain. In Postfix the domain is missing from mydestination, virtual_mailbox_domains, or relay_domains; in Exchange it isn’t an accepted domain; after a migration the MX points at a host that was never told about the domain. The server treats your recipients as third parties and refuses to relay to them.

Diagnose with DechoNet

Email Check on the recipient domain shows where its MX records actually point. For the inbound case, this reveals whether mail for your domain is landing on a server that even claims to host it — a leftover MX after a migration is a classic cause of your own domain bouncing 554 5.7.1.
Email Header Analyzer reads the bounce and tells you which host refused and in which direction. Confirm the code is 5.7.1 relay refusal (not 5.1.1 missing mailbox, not a 5.7.x authentication/DMARC block) and identify the reporting server — that decides whether the fix is yours or the receiver’s.
DNS Check shows the domain’s MX priorities and recent changes. A demoted, duplicated, or stale MX quietly catching mail for a domain no host is configured to accept produces inbound 554 5.7.1 for a perfectly valid address.

Resolution Checklist

First, decide the direction. Is the failing mail outbound (you sending out) or inbound (someone sending to your domain)? The bounce’s reporting host tells you. Everything below forks on this.
Outbound: enable SMTP authentication in the client or app, and use the submission port 587 with STARTTLS (or 465 implicit TLS), not port 25. Confirm the username and password are current.
Outbound: if you send from a server or script without login, confirm the source IP is on the relay’s allowed-networks list. Moved hosts, new cloud IPs, and changed egress addresses are the usual break.
Inbound: on the receiving server, confirm the domain is configured as one it accepts mail for — Postfix mydestination/virtual_mailbox_domains, Exchange accepted domains. Add it if missing, then reload.
Inbound: verify the MX record points at the host that is actually configured to accept the domain. Clean up stale MX entries left by a migration.
Re-send after each change. 554 is permanent, so nothing clears until the underlying authorization is fixed.

When to Escalate

If the failing mail is outbound through a provider’s relay and your credentials and port are correct, escalate to that provider — your account may not be authorized to relay, or the IP may be blocked on their side.
If the failing mail is inbound to a domain you don’t administer, forward the exact bounce to the receiving domain’s postmaster. The 554 5.7.1 and the reporting host name tell them precisely that their server isn’t configured to accept mail for that domain — a fix only they can make.
If you own the receiving server, the domain is listed as accepted, and valid recipients still bounce 554 5.7.1, hand your MTA vendor the SMTP transcript. A correctly configured local domain that the server still treats as foreign points at a config-load or routing fault on their side.