SMTP 550 5.7.1: A Permission Problem, Not an Address Problem

550 5.7.1 is a permanent rejection on policy grounds. The recipient almost certainly exists. Something about the sender, the connection, or the message broke a rule on the receiving side: no permission to send to that recipient, no permission to relay through that server, no authentication, or a reputation block. Retrying the identical message reproduces the identical answer.

The spec-level story is short. RFC 5321's definition of 550 covers a command "rejected for policy reasons", and RFC 3463 reserves the whole X.7 range for security and policy failures. Everything else about this code is what the big providers built on top of it, and they built a lot.

What triggers a 550 5.7.1?

Microsoft's own troubleshooting article for this code says it "typically indicates a security setting in your organization or the recipient's organization is preventing your message from reaching the recipient". Its NDR reference table files three functionally different causes under the single code: delivery not authorized (the sender is not on a distribution group's allowed-senders list), unable to relay (the sending system is not permitted to relay to a destination it is not the final stop for), and client was not authenticated (the receiver requires SMTP AUTH before it accepts a submission).

Gmail is broader still. Its own error table lists more than a dozen distinct 5.7.1 strings, covering domain and recipient policy blocks, SMTP relay credential mismatches, spam and reputation blocks, rate limits, and malformed messages: a missing From: header, multiple From: headers, a missing Message-ID:, duplicate headers, a unicode character in a header that does not allow one.

So the number narrows the problem down far less than the text after it does. Read the text.

• Gmail, policy: 550 5.7.1 The user or domain that you are sending to (or from) has a policy that prohibits the email that you sent. Contact your domain administrator for assistance. Gmail appends gsmtp to every error, and gcdp when the block came from a Google Workspace administrator's own custom rule.
• Microsoft, blocklist: 5.7.1 Service unavailable; Client host [xxx.xxx.xxx.xxx] blocked using Blocklist 1; To request removal from this list please forward this message to delist@microsoft.com
• Postfix: the equivalent refusal reads "Relay access denied". Postfix's own documentation uses that phrase in three separate places and documents the directive behind it, reject_unauth_destination, whose default reply code is 554. Postfix does not print the enhanced code next to that phrase anywhere in its own reference, though that is the pairing real server logs carry.

Does it mean your domain is blocked?

Sometimes, and this one is documented rather than folklore. Gmail publishes two 5.7.1 strings tied explicitly to reputation, one for "the very low reputation of the sending IP address" and one for the sending domain. Microsoft publishes the Blocklist 1 string above, with delisting by email as the remedy.

But reputation is one cause among several filed under this code, not the default reading. Microsoft's stronger reputation signals are separate sub-codes: 5.7.708, "Access denied, traffic not accepted from this IP", which its docs tie to a low-reputation sending IP and say is more likely to hit new trial tenants, and 5.7.750 for sending from a domain that was never registered in the tenant. If your bounce carries one of those rather than a plain 5.7.1, that is the clearer signal.

What should a sender do?

Read the exact wording, then match it to a cause. The fixes have nothing in common with each other.

Do not simply retry. RFC 5321 puts 5yz replies in the do-not-repeat class, and Microsoft is blunter: "Typically, you can't fix the problem yourself. You'll need the recipient or the recipient's email admin to fix the configuration on their end."

Do not start with SPF, DKIM and DMARC. Gmail does not return 550 5.7.1 for an authentication failure. It has a dedicated code, 550 5.7.26, and a temporary 4.7.26 variant for when a DNS lookup failure blocked the check. A 5.7.1 from Gmail means something else.

If the text mentions relay, credentials, or a destination that is not final, it is a relay configuration problem on your side. Gmail's own instruction for its relay case is to authenticate with SMTP AUTH or present a registered domain name in HELO or EHLO. Gmail's relay-denial wording appears under both 5.7.0 and 5.7.1 depending on which check failed, so match the string, not the number.

What should a receiving admin check?

Distribution group restrictions and transport rules first. Microsoft's documented fix for the restricted-group case is to add the sender to the group's allowed-senders list, allow external senders if the sender is outside the organization, or modify the mail flow rule doing the blocking.

Then connection filtering and blocklists. Then your own domain's records: Microsoft lists SPF problems, MX problems, incomplete domain enrollment and misconfigured hybrid connectors as admin-side causes of a 5.7.1, and notes it does not support more than one MX record for a domain enrolled in Exchange Online.

On Postfix the relevant knobs are smtpd_relay_restrictions, which defaults to permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, and the choice between reject_unauth_destination and defer_unauth_destination. The second rejects the same requests with a temporary code instead of a permanent one.

Which codes get confused with 550 5.7.1?

• 550 5.1.1. Addressing, not policy. The mailbox does not exist.
• The 4.7.x family. Same condition class, opposite instruction. The leading 4 makes it temporary, so the message stays queued. Postfix's defer_unauth_destination is the clean illustration: identical refusal, non-permanent code, admin's choice.
• 550 5.7.26. Gmail's authentication code, for SPF, DKIM and DMARC failures specifically.

The full SMTP reply code list covers the rest.