Skip to content
Webmaster Tools
EmailEmail Deliverability550 5.7.1

550 5.7.1 delivery not authorized

What the 550 5.7.1 bounce means, the common reasons receivers send it (blocklists, spam filters, relay denied, policy), and how to find which one hit you.

What 550 5.7.1 means

A 550 5.7.1 bounce means the receiving server refused the message for a security or policy reason. The basic code 550 is a permanent failure, so nothing will retry it. In the enhanced status code (RFC 3463), 5.7.1 is "delivery not authorized, message refused": the receiver understood the message and decided not to accept it. It is one of the most generic rejection codes, so the text after it matters more than the number.

Typical replies (wording varies by provider and changes over time):

550 5.7.1 Service unavailable, Client host [203.0.113.25] blocked using zen.spamhaus.org
550 5.7.1 Relaying denied
550-5.7.1 Our system has detected that this message is likely unsolicited mail.
550 5.7.1 Message rejected due to content restrictions

Common causes

Text mentions Cause
A blocklist name (Spamhaus, Barracuda, SpamCop) Your sending IP or domain is listed
"Relaying denied" or "relay access denied" The server will not pass mail on for you
"Unsolicited", "spam", "content" A filter scored the message as spam
"Not authorized", "sender denied" The recipient or their admin blocks you
Group or list address Only members or internal senders may post
  • Blocklisted IP. The most common cause on self-hosted servers and shared hosting. Check the IP in the bounce.
  • Relaying denied. Your mail client is sending through a server that does not know you: it is not authenticating, or uses port 25 instead of 587 with a login. Or your own server received mail for a domain it does not handle.
  • Spam filtering of the content or links: a URL shortener or domain with a bad reputation, or a message that looks like phishing.
  • Recipient-side rules: a blocked sender list, a distribution group that only accepts internal mail, or a country block.
  • Missing authentication or reverse DNS: some receivers use 5.7.1 rather than 5.7.26 when SPF, DKIM or PTR checks fail.

How to fix it

  1. Read the full bounce. The diagnostic text after 5.7.1 usually names the reason. Paste the bounce into the Email Header Analyzer to see the path the message took and its authentication results.
  2. Check blocklists for the sending IP. If listed, fix the cause (open relay, compromised account, infected machine, spammy list) before requesting removal at the list's site.
  3. Fix relay errors in the client. Send through your provider's submission port with authentication. In Postfix, allow relaying only for logged-in users:
# /etc/postfix/main.cf
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
  1. Check reverse DNS. The sending IP should have a PTR record whose name resolves back to the same IP:
dig -x 203.0.113.25 +short
dig mail.example.com +short
  1. Authenticate the domain with SPF, DKIM and DMARC.
  2. Ask the recipient to allowlist you if the block is on their side; only their admin can change it.
  • 421 4.7.28: the temporary rate limit that often comes first.
  • 550 5.7.26: rejected because authentication failed.
  • 550 5.1.1: the address does not exist.
  • Port 587: authenticated submission for mail clients.

Run the sending IP through the Blacklist Checker to see which lists, if any, have it.