5.7.1 is the enhanced status code for "delivery not authorized, message refused". It says the receiving server refused the message on purpose and nothing about why. 550 and 554 in front of it are both permanent failures; which one a server uses is its own habit. The reason is in the words after the code, and those differ completely from one provider to the next.
Below are the versions that come up most, grouped by what they actually mean.
Your sending IP or domain is listed
550 5.7.1 Service unavailable; client host [203.0.113.5] blocked using zen.spamhaus.org
550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent.The first names the blocklist outright, and the blacklist checker shows whether the IP is still on it. The second is Microsoft's wording for an IP its own filters block, and the bounce usually adds a code such as S3150 and a link to Microsoft's troubleshooting page. No public list is involved there, and the block is lifted through Microsoft's sender support form. On shared hosting or a shared ESP pool the IP is the provider's, and so is the fix.
The content looked like spam
550 5.7.1 Message rejected as spam by Content Filtering
550-5.7.1 Our system has detected that this message is likely unsolicited mail
554 5.7.1 High probability of spamGmail's "likely unsolicited mail" is a reputation and content verdict on the message and the sender together. A sudden change in volume, a list with addresses that never opted in, links to domains with a bad record, or a missing unsubscribe header in bulk mail all push toward it. What gets such mail through is sending only to people who asked, with proper authentication and links to your own domain.
The message failed DMARC
550 5.7.1 Email rejected per DMARC policy for example.comThe receiver read your DMARC record, the message failed it, and your policy says reject. SPF or DKIM passed for some other domain, or for none, and DMARC fail shows how to find which. A bounce that says the policy could not be evaluated is a different problem, see 554 5.7.5.
Relay access denied
554 5.7.1 <user@example.net>: Relay access denied
550 5.7.1 Unable to relayThe server you handed the message to does not accept it for delivery elsewhere, because your mail client or application did not log in to it, or logged in to the wrong one. This is a sending setup problem, not a deliverability one: turn on SMTP authentication with the account's credentials, use the submission port (587 or 465) instead of 25, and check that the outgoing server is the provider's.
The recipient's own policy
550 5.7.1 Delivery not authorized, message refused
550 5.7.1 The user or domain that you are sending to (or from) has a policy that prohibited the mailThe recipient's organisation decided not to take it: a rule that blocks outside senders, a distribution list limited to internal or authenticated senders, a country or attachment filter. Nothing on your side changes this; the recipient or their administrator has to allow you.
How the test reports it
Three of the five groups above can be caught before a real send. The sending IP is looked up on public lists such as Spamhaus ZEN, the kind receivers quote in these bounces. The DMARC result covers the third group. For the content group the report has narrower signals than a receiver's filter: links that sit on a malware list, and in a mailing, unsubscribe headers that are missing, not https or not covered by DKIM. Relay errors and the recipient's own policy happen before or outside anything the message carries.