550 5.7.1: Delivery Not Authorized, Message Refused

A 550 5.7.1 bounce means the receiving mail server refused your message because of a policy: you aren't authorized to send to that recipient, or not from that server, or not with that reputation. The code itself is generic. The text that follows it tells you which policy you hit, and that's the part you need to read.

RFC 3463, which defines these codes, describes X.7.1 as "Delivery not authorized, message refused" and says it can be the result of per-host or per-recipient filtering. The leading 5 makes it a permanent failure: resending the same message the same way won't work.

What the bounce looks like

There's no single 550 5.7.1 message. Every mail server writes its own text. Microsoft's Exchange Online documentation lists these 5.7.1 variants, among others (the first three are the descriptions from its NDR reference, shown here after the codes as they appear in a bounce):

550 5.7.1 Delivery not authorized
550 5.7.1 Unable to relay
550 5.7.1 Client was not authenticated
550 5.7.1 RESOLVER.RST.AuthRequired; authentication required [Stage: CreateMessage]
5.7.1 Service unavailable; Client host [203.0.113.7] blocked using Blocklist 1; To request removal from this list please forward this message to delist@microsoft.com

Other servers use the same code for blocklist hits and spam decisions:

554 5.7.1 Service unavailable; Client host [203.0.113.7] blocked using zen.spamhaus.org
550-5.7.1 This message is likely unsolicited email. To reduce the amount of
550-5.7.1 spam sent to Gmail, this message has been blocked.

What it means: match the text, not the code

If you're not sure how to pull the right text out of a bounce, see how to read a bounce message.

Common causes, most likely first

1. Your IP or domain is on a blocklist the receiver uses. The bounce usually names the list. This is the most common 5.7.1 for bulk senders, especially to business domains.
2. The receiver's spam filter refused the message. Gmail, corporate gateways and many hosted filters use 5.7.1 for "we think this is spam." Reputation, complaints and content drive it.
3. The recipient is restricted. Microsoft says this happens most often with distribution groups set to accept mail only from members or approved senders, and with mail flow (transport) rules that reject matching messages. Nothing about your reputation is involved.
4. A relay or authentication misconfiguration. Your server or app is handing mail to a server that isn't the recipient's and doesn't know you, or is connecting without the login the server requires. This is common with printers, apps and website contact forms set up to send through a company mail server.
5. The recipient's domain is misconfigured. Microsoft lists MX records pointing to the wrong place and domains that aren't fully set up in Microsoft 365. You can't fix this one; the recipient's admin can.

How to fix it

1. Copy the full bounce text from your ESP or mail server logs. Not the summary your platform shows, the actual SMTP response.
2. Match it in the table above. The words after 5.7.1 decide everything that follows.
3. For a blocklist: confirm the listing, find what caused it, fix that, then request removal from the list named. The blocklist playbook walks through it, and which blocklists matter helps you prioritize.
4. For a spam decision: check authentication with the email checker, then look at complaints, list sources and the domains in your links. See why emails go to spam.
5. For a restricted recipient: contact the recipient another way and ask them or their admin to allow your address. For an internal Microsoft 365 group, the group owner can add you as an allowed sender or allow external senders.
6. For relay or authentication errors: configure the sending app or device to log in to the mail server (SMTP AUTH with a real account), or send through a service that's authorized for your domain. Check your SPF record covers it with the SPF analyzer.
7. For a misconfigured recipient domain: tell the recipient. Their MX records or tenant setup need fixing on their end.

How to confirm it's fixed

Send a single test to the address that bounced and check the SMTP response in your logs. For a blocklist, re-check the listing and watch bounces from other domains on the same list. For a spam decision, compare bounce rates by receiving domain over the next several sends, and check headers of delivered mail with the header analyzer.

How to keep it from coming back

• Monitor bounce text by receiving domain, not just bounce counts. A new 5.7.1 pattern at one receiver is an early warning.
• Keep SPF, DKIM and DMARC passing for every service that sends as your domain.
• Make sure apps and devices that send mail authenticate properly instead of relying on open relays or IP allowlists.
• Keep complaint rates and list sources clean, which keeps you off blocklists in the first place.

When to get help

If the bounce text doesn't point to an obvious cause, or 5.7.1 rejections are spreading across many receiving domains at once, it's worth having someone read your logs with you. Get in touch.

FAQ

Is 550 5.7.1 a hard bounce?

Technically yes: it's a permanent failure, and the receiver won't accept that message as sent. But it usually isn't a bad address. The address is fine; the receiver refused the message for a policy reason you can often fix.

Is 550 5.7.1 my fault or the recipient's?

Either. Blocklists, spam decisions and authentication problems are on the sender's side. Restricted groups, transport rules and broken MX records are on the recipient's side. The bounce text tells you which.

What's the difference between 550 5.7.1 and 554 5.7.1?

The enhanced code 5.7.1 means the same thing in both. The basic SMTP code differs by server and by the stage of the conversation where the rejection happened. Read the text the same way. See 554 5.7.1 and SMTP 550 errors.