A 550 5.7.1 bounce means the receiving server accepted your connection, read the message, and refused it for a policy reason rather than a technical one. Your SMTP handshake worked. The refusal happened after that, and that detail is what tells you where to look first.
RFC 3463 classes 5.7.x as Security or Policy Status: failures tied to per-recipient or per-host filtering, not to a bad address or a full mailbox. Code 5.7.1 reads "delivery not authorized, message refused." The receiving server decided this message, from this sender, does not get through.
I see this code most from Gmail and Microsoft, and it traces to one of three causes almost every time. I check them in the order that resolves fastest, not the order that feels most likely.
Google requires senders above 5,000 messages a day to personal Gmail accounts to authenticate with SPF and DKIM, publish a DMARC record, and align the From domain with the SPF or DKIM domain. Miss any one of those and a 5.7.1 refusal is the direct result. This is the fastest cause to rule out, because it resolves against a DNS lookup in minutes, not against a provider's own reputation scoring.
Authentication can pass cleanly and a receiver still returns 5.7.1 because the sending domain or IP already carries a reputation the mailbox provider has scored as risky. This takes longer to confirm than authentication, because it depends on a provider's own reporting rather than a record you control directly.
Less common, but real: a receiving domain's mail administrator has blocked the sending domain or IP directly, independent of anything Google's or Microsoft's automated scoring would produce. This usually shows up as a bounce that is consistent on every message to one specific domain, rather than a rate that moves with content or volume.
An authentication failure and a reputation problem produce an identical bounce string. The mistake I see most is treating every 5.7.1 as a reputation problem and starting a warmup or list-cleanup process before checking whether the DNS records even resolve. Authentication is minutes to confirm. Reputation is an afternoon of reading Postmaster data. Check the fast one first, and only move to the slow one once the fast one comes back clean.
If authentication checks out and the bounce is Gmail-specific, what the Gmail spam filter actually scores covers how to read your own reputation numbers rather than guessing at them.
No. It means this one message was refused. Intermittent 5.7.1 bounces to a single provider, with everything else delivering normally, usually point to a narrower authentication gap than an outright block, which tends to fail on every message to every domain.
Retrying without changing anything reproduces the same refusal, because the cause is a policy decision, not a temporary condition. A 4yz code is worth retrying. A 5yz code is a permanent failure by RFC 3463's own definition, and resending it unchanged wastes the retry.
Not necessarily. A blocklist listing is one possible cause of a 5.7.1 refusal, but a missed authentication requirement or a provider-specific filtering rule produces the identical code with no blocklist involved at all.