Gmail 550 5.7.1: Every Variant of the Message and What Each One Means

550 5.7.1 is Gmail's catch-all code for "rejected by policy", and Gmail uses it for at least six unrelated problems. A spam judgement, a reputation block, a broken From header and a rule set by the recipient's admin all come back as 550 5.7.1. The fix depends entirely on the text after the code. This page lists every variant from Google's own list, sorts them by who has to act, and covers the two you can't find elsewhere on our site in depth: "likely unsolicited email" and "a policy that prohibits the email".

Paste the full bounce into Bounce Doctor to see which variant you have and what it points at.

Every variant, sorted by cause

From Google's Gmail SMTP errors and codes page (last updated 26 October 2026, read 2 November 2026):

Variant (shortened)	Group	Who fixes it
"This message is likely unsolicited email."	Content / spam judgement	You: targeting, content, volume
Likely suspicious due to the very low reputation of the sending IP	Reputation	You: slow down, rebuild
Likely suspicious due to the very low reputation of the sending domain	Reputation	You: slow down, rebuild
"The IP you're using to send email is not authorized to send email directly to our servers."	Sending IP	You: use a relay
Doesn't meet IPv6 sending guidelines for PTR records and authentication	Sending IP	You: IPv6 PTR and auth, or IPv4
Not RFC 5322 compliant: duplicate headers, multiple From headers, From missing	Message format	You or your developer
No valid address in From; several addresses in From; non-compliant From domain	Message format	You or your developer
"Messages missing a valid Message-ID: header are not accepted."	Message format	You or your developer
Unicode or encoded-word syntax in a header that doesn't allow it	Message format	You or your developer
"This email has been rate limited."	Rate limit	You: lower volume
Daily SMTP relay sending limit exceeded for this customer	Rate limit (Workspace relay)	You or your Workspace admin
The user or domain has a policy that prohibits the email	Recipient policy	The recipient's admin

The detailed guides:

• Reputation: Gmail 421 4.7.0 and 550 5.7.1 low reputation
• Sending IP: Gmail 550 5.7.1 not authorized to send directly
• Message format: Gmail 550 5.7.1 not RFC 5322 compliant
• Recipient policy across providers: recipient only accepts internal mail

Triage in three questions

1. Does the text mention reputation, spam or "unsolicited"? Then it's about how Gmail sees your mail. Look at volume, complaints and the list.

2. Does it mention an IP, IPv6, a header, Message-ID or From? Then it's mechanical. Something in how the mail is sent or built is wrong, and it will fail the same way every time until it's fixed.

3. Does only one recipient domain return it, with the word "policy"? Then it's that organisation's rule, and nothing on your side will change it.

If you're still unsure, look at the spread. A reputation or content block hits many Gmail and Workspace domains at once. A recipient policy hits one domain and nobody else.

"This message is likely unsolicited email"

This is the one cold senders see most, and the one with the least official detail. Google doesn't publish what triggers it. What the code tells you is that Gmail's filters judged the message spam strongly enough to refuse it, rather than accept it and file it in the spam folder.

It is related to, but different from, two other codes:

Code	What Gmail did
421 4.7.28 "unusual rate of unsolicited email"	Deferred mail because of a spike from your IP, domain or a URL
550 5.7.1 "very low reputation"	Rejected because the sender's reputation is very low
550 5.7.1 "likely unsolicited email"	Rejected this message as unwanted

In practice, these are the patterns that sit behind it for outreach:

Pattern	Why it reads as unsolicited
A list that doesn't match the offer	People mark it as spam, and Gmail learns from that
The same message to many people at once	Identical content in a burst looks like a campaign nobody asked for
A link domain or tracking domain shared with spammers	Gmail judges URLs as well as senders
A new domain with no history sending at full volume	No positive signals to balance the risk
Long sequences to people who never replied	Each extra step adds complaints and no replies

What to do:

1. Pause the campaign that produced it. A 550 means more of the same will fail.
2. Check the spam rate in Postmaster Tools if your domain has enough volume to show data. Google's sender guidelines FAQ (read 2 November 2026) says bulk senders stay ineligible for mitigation while their user-reported spam rate is above 0.3%. Our Postmaster Tools guide explains the dashboards.
3. Narrow the targeting. Send to the people most likely to want the message, not the whole export.
4. Change the message. Write fewer links (none in a first touch is safest), use your own custom tracking domain instead of a shared one, and make each email specific to the recipient.
5. Shorten the sequence and stop it on any reply, including "not interested".
6. Restart at lower volume, spread through the day. Our guide on cold emails per day per inbox has sensible numbers.
7. Verify the list. Invalid addresses and old addresses that have become spam traps are signals of a list nobody built with care. Removing them won't lift a content block on its own, but it removes one reason for it.

Don't move the same campaign to a fresh domain. Gmail judges behaviour, and the pattern will follow you.

"The user or domain has a policy that prohibits the email"

This variant means a rule on the recipient's side stopped the message. In Google Workspace, admins can block senders, restrict which outside domains their users may receive mail from, or set content rules. Any of those can produce this rejection.

How to recognise it:

• Only one recipient domain returns it, or one address.
• Other mail to Gmail and other Workspace domains goes through normally.
• Your authentication and reputation checks are fine.

What to do:

• Suppress the address in your campaign. Retrying won't help, and the admin has made a choice.
• If you have a real relationship with the organisation (you're a supplier, a partner or an existing customer), ask your contact to have their IT team allow your domain.
• For cold outreach, reach the person another way, or move on. Don't try to get round the block with a different domain; that is the kind of behaviour that gets you blocked more widely.

Microsoft 365 has its own codes for the same kind of rule, such as 550 5.7.133 for groups that only accept internal mail. Our recipient only accepts internal mail guide covers both providers.

"This email has been rate limited" and the relay limit

The plain "This email has been rate limited" variant means Gmail is limiting how much mail it accepts. Google notes that limits apply to sending and receiving. Lower the volume to Gmail and spread it out.

The daily SMTP relay sending limit variant is different. It comes from Google Workspace's SMTP relay service, used by organisations that route mail from their own servers or apps through Google. It means your Workspace organisation has used up its relay allowance for the day. The Workspace admin can see the relay settings; the long-term fix for high-volume sending is a dedicated sending service rather than the Workspace relay. Our guide to Gmail sending limits covers the per-user limits that sit alongside it.

What not to do with any 550 5.7.1

• Don't retry in bulk. It's permanent, and repeated rejected attempts add to the signals Gmail is already using against you.
• Don't delete the contact for a content or reputation rejection. The mailbox is fine. Suppress it for now, fix the cause, and decide later.
• Do delete or suppress for a recipient policy. The organisation has said no.
• Don't assume it's DNS. Only the format and sending-IP variants are mechanical. Spam and reputation variants need changes to what you send and to whom.

The full set of Gmail codes, including the authentication ones that use 5.7.26, 5.7.27 and 5.7.30, is in our Gmail bounce codes reference.

Where SimpleVerifier fits

A 550 5.7.1 is about the message, your sending or a recipient rule, not about whether the mailbox exists, so verification won't reverse one. What it does is make sure the next send isn't dragged down by bad addresses. SimpleVerifier runs a live mailbox check on each address and returns safe to send, send with care, check again later or do not send, with the reason. Catch-alls stay risky, never guessed valid.

The first 100 checks are free with a Google sign-in on the verify page. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.