Error 550 5.7.1: "policy" does not mean just one thing

The 550 5.7.1 code is a permanent refusal for a policy reason on the receiving server. The code alone tells you almost nothing: it is the sentence that follows it that says whether the problem is your reputation, your content, your IP address or a rule set by the recipient.

In brief

  • 550 is a permanent refusal: resending the same message as is does not help.
  • 5.7.1 means "refused for security or policy reasons". The seven causes below all carry this code.
  • Read the sentence after the code, and the name of the server that refuses. At Google, every refusal contains "gsmtp".
  • At Gmail, most 5.7.1 errors are fixed on the sender side (reputation, content, authentication). At Microsoft, many are fixed on the recipient side.

Reading the refusal message

A refusal message has three parts: the three-digit SMTP code (550), the enhanced code made of three numbers (5.7.1) and a text. The first digit says whether the error is temporary (4) or permanent (5). The text is the only part that tells the causes apart.

Also look at who is refusing. Google marks its refusals with "gsmtp" in the text. For Microsoft, the server name contains "protection.outlook.com". If the refusal comes from a company server, the message carries no signature of this kind: the text is what counts.

The causes, and how to tell them apart

At Gmail: message judged unsolicited

How to recognize it: The text says “This message is likely unsolicited email.” A link to an explanation page from Google is attached to the refusal.

What to do:

  1. Open the link in the refusal and read Gmail's sender guidelines again.
  2. Check the spam rate in Google Postmaster Tools: Google asks you to stay below 0.30% and recommends aiming for less than 0.10%.
  3. Reduce the volume per mailbox and per day, clean the list (nonexistent addresses, unengaged contacts) and remove typical spam content: misleading subject lines, shortened links, needless attachments.

At Gmail: IP or domain reputation too low

How to recognize it: The text says “This message is likely suspicious due to the very low reputation of the sending IP address.” The same sentence exists for the sending domain.

What to do:

  1. Find out whether the IP is shared: on a shared plan, the bad reputation may come from other customers and not from you.
  2. If the IP is yours, or if the domain is new, ramp up the volume gradually instead of sending several hundred messages on the first day.
  3. Monitor the reputation of the domain and the IP in Postmaster Tools before going back to full volume.

At Gmail: direct sending from an unauthorized IP

How to recognize it: The text says “The IP you're using to send email is not authorized to send email directly to our servers.”

What to do:

  1. Do not send directly from a server or a personal computer: go through the SMTP relay of your mailbox provider or your sending tool.
  2. Check that the sending IP has a correct reverse DNS (PTR), using the command in the next section.

At Gmail: non-compliant message headers

How to recognize it: The text mentions a missing Message-ID header (“Messages missing a valid Message-ID: header are not accepted”), a missing or duplicated From, or duplicated or malformed headers.

What to do:

  1. Fix the header mentioned so that it complies with the RFC 5322 standard. A valid Message-ID and a single From are enough in most cases.
  2. If the message is sent by a script or a custom development, test the raw message before sending rather than after the refusal.

At Gmail: relay or rate limit reached

How to recognize it: The text says “Daily SMTP relay sending limit exceeded for this customer” or “This email has been rate limited.”

What to do:

  1. Wait for the daily limit to reset or contact the administrator of the Google Workspace account.
  2. Spread your sending over several days and several mailboxes instead of sending everything from a single one.

At Microsoft: IP on the blocklist

How to recognize it: The text contains “Service unavailable; Client host [IP address] blocked using Blocklist 1; To request removal from this list please forward this message to delist@microsoft.com.”

What to do:

  1. Forward the full refusal message to delist@microsoft.com, as the message says.
  2. You can also use Microsoft's delist portal for the blocklist, described in the Microsoft documentation linked at the bottom of the page.
  3. This is not a penalty for a specific message: it is the IP address that is blocked. If it is shared with other customers, tell your provider.

At Microsoft: unauthorized sender, relay or authentication

How to recognize it: The texts “Delivery not authorized”, “Unable to relay” or “Client was not authenticated” also come with a 5.7.1. The first often appears when you write to a distribution group restricted to its members, or when a transport rule on the recipient side rejects the message.

What to do:

  1. “Delivery not authorized”: you cannot fix anything on your own. Contact the recipient through another channel so that they ask their administrator to accept your messages.
  2. “Unable to relay” or “Client was not authenticated”: the receiving server requires authentication or does not accept the targeted domain. Check the MX record of the recipient domain and the SMTP credentials used to send.

Check your DNS

Four commands are enough to rule out the causes that depend on your DNS configuration. Run them from a terminal (Linux, macOS, or Windows with WSL).

Read the SPF record of the sending domain

dig +short TXT yourdomain.com

Expected result: A single line starting with v=spf1. No line: no SPF. Two v=spf1 lines: the SPF is invalid and always fails.

Read the DMARC record

dig +short TXT _dmarc.yourdomain.com

Expected result: A line starting with v=DMARC1 and containing a policy p=none, quarantine or reject.

Read the reverse DNS (PTR) of the sending IP address

dig +short -x 203.0.113.10

Expected result: A hostname. No answer: no PTR. The IP 203.0.113.10 is an example: replace it with the one in the Received header of your message.

Read the DKIM key (replace the selector with the one your provider uses)

dig +short TXT selector._domainkey.yourdomain.com

Expected result: A public key (p=...). Some providers publish a CNAME instead of a TXT record: in that case dig shows the CNAME target, then the key.

Check your whole domain at once

The free diagnostic reads your SPF and your DMARC and looks for a DKIM signature, with no account. It is the fastest way to find out whether authentication is the problem.

Test my domain now

What not to do

  • Resending the same message in a loop: a 550 is final, and every new attempt weighs on your reputation.
  • Changing the sending domain after every refusal. Reputation follows the IP, the domain and the content: if one of the three stays bad, the problem follows you.
  • Interpreting an S-numbered Outlook.com code (such as S3150) from forums. Microsoft does not publish a legend for these codes; go through its sender support portal.

Frequently asked questions

What does 550 5.7.1 mean in one sentence?

The recipient's server permanently refused your message for a security policy reason: reputation, content judged unwanted, unauthorized IP or a rule specific to the recipient. The text that follows the code says which one.

Should I resend the message after a 550 5.7.1?

Not as is. A 5xx code is permanent. First fix the cause given in the refusal text, then send a new message.

Does a 550 5.7.1 mean I am on a blacklist?

Not always. At Microsoft, a text saying "blocked using Blocklist 1" does point to an IP address blocklist. At Gmail, most 5.7.1 errors concern content, reputation or headers, not a public blacklist.

What is the difference with 550 5.7.26?

5.7.26 is reserved for authentication failures (SPF, DKIM, DMARC). 5.7.1 covers everything else in the recipient policy. If your message contains "authenticate" or "SPF", read the page on 5.7.26.

Official sources

Messages and fixes taken from the official documentation on October 21, 2026. Providers sometimes change their wording: if there is a discrepancy, the official page prevails.

Read next

Error 550 5.7.26Gmail rejects a message without valid SPF or DKIM, or rejected by the DMARC policy.Error 421 and 451Temporary refusals: deferral, rate limiting, reputation being built. When to retry and when to slow down.

Set up authentication at your mailbox provider

Other errors

Prospect without damaging your domain

Fluenzr sends from your own mailbox, warms up its sending history and monitors its reputation.

Start my 14-day trial