Quick answer
An Outlook 5.7.1 bounce means delivery was not authorized and the message was refused. The receiving system applied a rule rather than a reputation score: a transport rule, a blocked-sender entry, a connection filter, or a tenant allow/block list maintained by the recipient organization, and in some cases an enforced DMARC policy. Start by confirming your own authentication is clean, checking DMARC, SPF, and DKIM alignment, then turn to the recipient organization's policy, because the rule that refused the message often lives on their side and cannot be changed from yours.
What the 5.7.1 code means
A 5.7.1 code is a policy rejection. The receiving system refused the message because of a rule, not because a filter scored the content as spam and not because authentication failed at the protocol level. On a Microsoft 365 tenant or an on-premises Exchange Server, the rule is frequently a transport rule, a blocked-sender list, a connection filter, or a tenant allow/block list entry that the receiving organization's administrators maintain. Because the rule lives on the recipient side, the sender often cannot fix a 5.7.1 without contacting the receiving organization.
The complication is that 5.7.1 is also returned for some DMARC enforcement and authentication-policy rejections, which is the part the sender can fix. That overlap is why the diagnosis order matters. Rule out your own authentication first, because it is the part under your control, before concluding the block is purely recipient-side.
Why Outlook returns 5.7.1
Microsoft surfaces differ in who owns the filtering decision, which the Outlook pillar describes in detail. A 5.7.1 from a Microsoft 365 tenant usually traces to an administrator-defined rule on that tenant: a transport rule that matches your sending domain or a phrase in the message, a blocked-sender entry, or a connection filter that blocks your IP range. An on-premises Exchange Server adds the possibility of a relay restriction, where the server refuses to relay mail it does not consider authorized.
The sender-fixable slice of 5.7.1 is authentication. When the recipient enforces DMARC and your message does not produce an aligned SPF or DKIM pass for the visible From domain, some Microsoft configurations return 5.7.1 rather than the more specific 5.7.135. So an alignment problem can present as either code, and confirming alignment is part of triaging a 5.7.1 just as it is for a 5.7.135 failure.
How to diagnose a 5.7.1
Read the diagnostic text in the NDR first. A 5.7.1 bounce frequently carries a human-readable reason alongside the code: a phrase such as "message rejected for policy reasons", "unauthenticated email", or a named transport rule. That phrase tells you whether the cause is authentication, a content or sender rule, or a relay restriction, and it sometimes names the receiving organization's policy directly.
Then confirm your authentication is clean from your side. Resolve your DMARC, SPF, and DKIM records and check alignment against the visible From domain. The Relaymetry DMARC checker reads the published DMARC policy and the alignment-relevant records so you can rule authentication in or out before contacting anyone. If a real header shows DMARC, SPF, and DKIM all passing and aligned, the remaining cause is a recipient-side rule, and the next step is to contact the receiving organization rather than to keep editing your own DNS.
What to change
If authentication is the cause, align at least one method with your From domain and publish a DMARC record, the same remediation as a 5.7.135. If your authentication is clean and aligned, the block is a recipient-side rule that you cannot edit. Contact the receiving organization's administrators and ask them to review their transport rules, blocked-sender entries, and connection filters for your domain or IP, or to add a tenant allow entry for your sending identity. Do not retry the same message repeatedly against a recipient-side rule, because retries will not clear a rule and may add noise to the recipient's logs.