Short answer
550 5.7.1 means the receiving server refused the message for a security or policy reason. In RFC 3463 terms, 5 is a permanent failure, .7 is the security or policy subject and .1 is "delivery not authorized, message refused". The text after the code tells you which policy: a low-reputation IP or domain, a blocklist listing, a message that looks unsolicited, a malformed header, or a relay the server won't allow.
It is almost always about the sender, not the recipient's address. Don't suppress the address; fix the cause the text names, then send again.
On this page
What 550 5.7.1 means
RFC 5321 defines 550 as "requested action not taken: mailbox unavailable", which covers both a missing mailbox and a command "rejected for policy reasons". The enhanced code narrows it down: 5.7.1 is a policy refusal. The receiver understood the message and decided not to accept it from you.
Because the same code covers many policies, the human-readable text after it is what you act on. Read the full bounce, not just the numbers.
Common causes, by receiver
| Receiver | What the 550 5.7.1 text usually says | What it points to |
|---|---|---|
| Gmail | "This message is likely unsolicited email", "very low reputation of the sending IP address" or "...sending domain" | Reputation or spam filtering. Check Google Postmaster Tools for your domain. |
| Gmail | "not RFC 5322 compliant" (duplicate headers, missing or multiple From:, missing Message-ID) | A malformed message. Usually a bug in how the email is built. |
| Gmail | "The user or domain that you are sending to (or from) has a policy that prohibits the email" | A Google Workspace admin rule on the recipient's side. |
| Outlook.com / Microsoft 365 | "Unfortunately, messages from [IP] weren't sent... part of their network is on our block list (S3150)" | The sending IP is on Microsoft's own block list. |
| Microsoft 365 | "Delivery not authorized", "Unable to relay" or "Client was not authenticated" | A restricted distribution list or transport rule, or a server that isn't the destination for that domain. |
| Many servers | "blocked using" a list such as Spamhaus | A DNS blocklist listing for the sending IP or domain. |
Wording from Google's Gmail SMTP error reference and Microsoft's NDR reference. Microsoft's S-codes are quoted from real bounces; Microsoft doesn't publish a legend for them.
Yahoo tends to use 553 or 554 for permanent policy rejections rather than 550 5.7.1, and 421 with a TSS code for temporary deferrals; see 554 5.7.1.
How to fix it as a sender
- 1
Read the full text
Find the sentence after
5.7.1. It names the policy, and sometimes the list or the IP. - 2
Check authentication
Make sure SPF, DKIM and DMARC pass for your From domain with the SPF checker, DKIM checker and DMARC checker. Unauthenticated mail draws policy blocks.
- 3
Check blocklists
Look up the sending IP and your domain with the blocklist checker. If it's listed, follow that list's removal process after fixing whatever caused the listing.
- 4
Check the message
If the text mentions RFC 5322, inspect a sent copy with the email header analyzer: one From header, a valid Message-ID, no duplicated headers.
- 5
Look at what you sent before the block
A sudden volume jump, a list with old addresses, or mail people didn't expect lowers reputation. Slow down, clean the list and send only what recipients asked for.
Retry or suppress?
How Groundmail handles 550 5.7.1
Groundmail reads the receiver's whole reply, not only the code. When a 550 5.7.1 reply says the refusal is about the sender (a blocklist listing, a reputation or spam-policy block, or Gmail's authentication and unsolicited-mail refusals), the bounce is recorded with bounce_type: "block". The address is fine, so it is not suppressed and the bounce doesn't count toward your bounce rate; you can send to it again once the cause is fixed. The receiver's reply is in bounce_reason on the email and on the email.bounced or email.failed webhook, so you can see exactly what it said.
Blocks on our shared IPs are our job: we monitor the pool and its listings and work with mailbox providers and blocklist operators to clear them. Blocks caused by your own domain (missing authentication, a DMARC policy your mail fails) need a DNS fix on your side, and the domain page in the dashboard shows the status of each record.
Frequently asked questions
Is 550 5.7.1 a hard bounce?
It's a permanent (5xx) failure, so the message won't be retried. But it's a block, not a bad address: the refusal is about the sender's reputation, authentication or content. Treat it differently from an unknown-user bounce and don't suppress the recipient.
Why do I get 550 5.7.1 from Outlook with S3150?
The sending IP is on Microsoft's block list. If you send through a provider, the provider owns that IP and needs to request removal. If it's your own server, fix the cause and use Microsoft's sender support process.
Can the recipient fix 550 5.7.1?
Sometimes. If the text says the recipient's domain has a policy that prohibits the email, or the address is a restricted distribution list, their admin controls that. Reputation and blocklist refusals are fixed on the sender's side.
What's the difference between a soft bounce and a hard bounce?
A soft bounce is a temporary failure, usually a 4xx reply (mailbox busy, rate limited, try again later); the sending server retries it. A hard bounce is a permanent failure, a 5xx reply, where retrying the same message won't help. Among hard bounces, it matters whether the problem is the address (unknown user: suppress it) or the sender (a block: fix the cause, keep the address).
Sources
Facts on this page about other companies' products, prices and policies come from these public pages. They change, so check them before you decide.