554 5.7.1: Message Refused or Relay Access Denied

A 554 5.7.1 bounce means the receiving server refused your message for a policy reason and won't accept it in its current form. In practice it shows up in two very different situations: a server refusing to relay mail for you ("Relay access denied"), usually because your app or mail client isn't authenticating, or a receiving server rejecting you outright, most often because your IP is on a blocklist it uses. The text after the code tells you which one you have.

Both are permanent failures, so the message won't be retried. Fix the cause and resend.

What the bounce says

The relay version, which is Postfix's wording and the one most people are searching for:

554 5.7.1 <jane@example.net>: Relay access denied

The blocklist version, also in Postfix's format, with the list named at the end:

554 5.7.1 Service unavailable; Client host [203.0.113.7] blocked using
zen.spamhaus.org; https://check.spamhaus.org/query/ip/203.0.113.7

And plain policy refusals, which say little beyond "no":

554 5.7.1 <sender@example.com>: Sender address rejected: Access denied

Other systems wrap the same idea in their own text. iCloud, for example, returns 554 5.7.1 [CS01] for its reputation blocks (see the iCloud CS01 guide).

What it means

The two halves of the code come from different standards. The 554 is the basic SMTP reply. RFC 5321 uses it for a failed transaction, and also allows a server to answer a new connection with 554 instead of a greeting, which is how some servers say "I won't talk to you at all." The 5.7.1 is the enhanced status code from RFC 3463: "Delivery not authorized, message refused," meaning the sender isn't authorized to send to that destination. The leading 5 marks it as permanent.

So 554 5.7.1 is a generic "refused by policy." It's common because Postfix, one of the most widely used mail servers, uses 554 by default for relay, access table and DNSBL (blocklist) rejections. Exchange tends to use 550 for the same refusals (see 550 5.7.1).

Cause 1: relay access denied

Relaying means asking a server to pass along a message for a domain it doesn't host. A properly configured server only does that for its own network or users who log in. Otherwise it would be an open relay. (Postfix's default defers unknown clients with a temporary error; most configurations use the stricter reject_unauth_destination, which produces the permanent 554.)

Common causes, most likely first:

1. SMTP authentication isn't turned on. The mail client, website plugin, printer, scanner or app is set to send without a username and password, or with the wrong ones.
2. Wrong port or server. The app is pointed at port 25 (server to server, no auth expected) instead of the submission port 587, or at the wrong hostname entirely.
3. The sending machine's IP changed. The server trusted your office IP, and the office got a new one.
4. It's the recipient's problem, not yours. If you get "Relay access denied" sending to a normal external address, the recipient domain's MX record may point at a server that doesn't think it hosts that domain. Microsoft documents this exact cause for its own "Unable to relay" errors.

How to fix it

1. Read who generated the bounce. If it came from your own outbound server or provider, it's your configuration. If it came from the recipient's MX, it's theirs.
2. Turn on SMTP authentication in the sending client or app, use port 587 with STARTTLS, and use the full mailbox address as the username.
3. If you run the server, add the trusted machine's IP to the allowed networks (in Postfix, mynetworks) only if it really is yours, or better, give it its own login. Don't widen the relay rules to make an error go away.
4. If the recipient's server is refusing, tell their admin. Their MX or accepted-domains configuration is wrong, and nothing on your side will fix it.
5. On Microsoft 365, the equivalent errors have their own codes: 550 5.4.1 and 5.7.64 for connector or accepted-domain problems, and 5.7.57 for an app using smtp.office365.com without authenticating.

Cause 2: blocklist or policy rejection

If the bounce names a blocklist (zen.spamhaus.org, bl.spamcop.net, b.barracudacentral.org), your sending IP or a domain in your message is listed, and the receiver refuses mail from it.

How to fix it

1. Note the list and the IP or domain from the bounce. The bounce usually includes a lookup URL.
2. Check whether it's widespread. If many receiving domains bounce you with the same list, the listing is real and affecting you. If one tiny receiver uses an obscure list, it's trivia. See which blocklists actually matter.
3. Find the cause before you request removal. Compromised accounts, a purchased or old list, spam traps, or a hacked web form. The blocklist playbook walks through it.
4. Request delisting through the list's own process: Spamhaus, SpamCop, Barracuda. Legitimate lists don't charge.
5. If you're on an ESP's shared IP, the ESP has to handle it. See shared IP listed.

If the bounce says "Access denied" with no list, the recipient's admin has blocked your address, domain or IP in a local table. Only they can lift it, so contact them through another channel.

How to confirm it's fixed

For relay errors, send a test from the same app or device and confirm it arrives. For blocklist rejections, re-check the list's lookup page, then watch bounces from affected receivers for a few days; blocklist data is cached. For any bounce you can't decode, see how to read a bounce message.

How to keep it from coming back

• Give every app and device that sends mail its own authenticated account, and keep a list of them.
• Monitor your sending IPs against the major blocklists, and keep list hygiene tight: most real listings trace back to list quality.

When to get help

If you're on a blocklist that keeps coming back after removal, or you can't work out which system is sending the rejected mail, it's worth a second pair of eyes. Get in touch.

FAQ

Is 554 5.7.1 the same as 550 5.7.1?

Close. Both carry the same enhanced code, "delivery not authorized." The basic code differs mostly by server software: Postfix tends to use 554 for policy refusals, Exchange and Gmail tend to use 550. Read the text after the code; that's where the actual reason is.

Can I just retry later?

Not without changing something. It's a permanent failure, so the same message from the same setup will be refused again.

I'm the recipient and people get "Relay access denied" sending to me. What's wrong?

Your domain's MX record probably points at a server that isn't configured to accept mail for your domain, or your domain was removed from its accepted domains. Check the MX record and the server's domain list.