Is a 5.7.1 my fault or the recipient’s?

It depends on the text. Relay and blocklist refusals point at the sender; allow-list and restricted-group refusals are the recipient side’s choice.

Not until the cause is fixed. A 5.7.1 is permanent, and repeated attempts can make a reputation problem worse.

5.7.1 bounce: delivery not authorized, message refused

5.7.1Delivery not authorized, message refusedPermanent: retrying will not help

Example

554 5.7.1 <user@example.net>: Relay access denied

What it means

RFC 3463 defines X.7.1 as “delivery not authorized, message refused”. The sender is not allowed to deliver to that recipient, and the reason is policy, not a bad address. It is the most common security code in the wild and every major server uses it.

Because it is so broad, the text after the code is everything. “Relay access denied” means you tried to send through a server that is not responsible for the recipient domain. “Client host blocked using zen.spamhaus.org” means a DNS blocklist hit. “Message rejected as spam” or a vendor code points at content filtering. Microsoft, Proofpoint and Mimecast all wrap their own reasons in 5.7.1.

A temporary 4.7.1 means the receiver wants you to come back later: greylisting, a rate limit, or a reputation check under review. Retries handle it. With 5.7.1 you need to find which policy matched before sending again.

Likely causes

Your mail went to a server that does not handle the recipient domain and does not let you relay, often because a client is not authenticated.
Your sending IP or domain is on a DNS blocklist the receiver uses.
The recipient’s filter scored the message as spam or phishing, or it failed the receiver’s SPF, DKIM, or DMARC policy.
The recipient only accepts mail from certain senders (an internal-only group, a restricted mailbox, or an allow list).

How to fix it

Read the full text after 5.7.1 and classify it: relay, blocklist, content, authentication, or recipient restriction.
For relay denied, authenticate to your outbound server on port 587, or fix the MX so mail goes to the right host.
For a blocklist hit, check your IP, fix the cause (compromised account, open relay, missing PTR), then request delisting from that list.
For authentication or content refusals, publish a correct SPF record such as `v=spf1 ip4:203.0.113.10 include:_spf.example.net -all`, sign with DKIM, and align with DMARC.
For recipient restrictions, ask the recipient to have their admin allow your address or domain.

Checks that apply

Your domain or sending IP (fills in the checks below)

Blacklist Check Checks your sending IP or domain against about 40 DNSBLs, including the Spamhaus lists that often sit behind a 5.7.1.
Domain Health Grades SPF, DKIM, DMARC, MX and reverse DNS together, covering the authentication side of 5.7.1 refusals.
Reverse DNS (PTR) Shows whether your sending IP has reverse DNS that matches its forward name, which many 5.7.1 filters require.
Email Header Analyzer Reads the Authentication-Results in a delivered copy so you can see which check failed at the receiver.

FAQ

Is a 5.7.1 my fault or the recipient’s?: It depends on the text. Relay and blocklist refusals point at the sender; allow-list and restricted-group refusals are the recipient side’s choice.
Will resending help?: Not until the cause is fixed. A 5.7.1 is permanent, and repeated attempts can make a reputation problem worse.

All 191 bounce codes