550 5.7.1: Delivery not authorized: refused for policy reasons

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code 550: “Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)” (RFC 5321 §4.2.3).
• Enhanced code 5.7.1: “Delivery not authorized, message refused” in the IANA registry (RFC 3463), in the group security or policy status (RFC 3463 §3.8).

A 550 5.7.1 reply means the receiving server refused your message because of a policy. The code is used for many different policies, so the words after it are what tell you which one, and what to fix.

What it means

RFC 3463 §3.8 defines X.7.1 as "delivery not authorized, message refused": the sender is not allowed to deliver to this host or this recipient, because of filtering. The 550 basic code is a permanent refusal (RFC 5321 §4.2.1). Some servers send the same enhanced code as 554 5.7.1. The meaning is the same: a policy said no, and retrying unchanged will not help.

Telling the causes apart

Look for these clues in the text after the code:

• "Relay" or "unable to relay": you sent through a server that does not accept mail for that domain from you, usually because the app did not sign in. Microsoft uses 5.7.1 for this, and for a client that was not authenticated.
• "Not authorized" or "not allowed to send to": the recipient (or its group) blocks you. Microsoft 365 has its own codes for groups: 5.7.124 and 5.7.133.
• "Unsolicited", "reputation" or "spam": a content or reputation filter. Gmail uses 550 5.7.1 for likely unsolicited mail and for very low IP or domain reputation.
• Header words ("From", "Message-ID", "header"): a malformed message. Gmail rejects a missing or invalid From header, multiple From addresses, a missing Message-ID, and duplicate or badly encoded headers.
• "Not allowed to send directly": your IP should hand mail to its provider's relay instead.
• "IPv6": IPv6 sending without a PTR record or authentication.
• A blocklist name or IP ban: see 5.7.606 for Microsoft.

How providers use it

Gmail lists all of the above, plus a domain policy that prohibits the mail, relay credentials that do not match the sending domain, and a daily relay limit (Google's SMTP error reference). Microsoft's meanings are in its NDR reference. Yahoo documents permanent policy refusals with plain 553 or 554 codes, for DMARC or DKIM failures, prohibited content or a blocklist listing (Yahoo's error codes).

How to fix it

1. Relay: turn on SMTP authentication in the sending app, or send through the server that handles your own domain.
2. Recipient restriction: ask the recipient to have their admin allow you.
3. Reputation: fix authentication (SPF, DKIM, DMARC) and follow Google's sender guidelines.
4. Headers: send exactly one valid From address and a Message-ID.

What to do with the address

Usually keep it: most 5.7.1 refusals are about the sender or the message. Remove it only when the text says the recipient itself was rejected.

Related codes

• 421 4.7.0: Temporarily refused: reputation, DNS or TLS
• 550 5.7.26: Unauthenticated: SPF and DKIM failed, or DMARC rejected it
• 5.7.606: Banned sending IP (Microsoft)
• 5.7.133: The group or mailbox takes no mail from outside (Microsoft 365)

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.