Skip to content
ReputeCastReputeCast Docs

Gmail 550 5.7.1: blocked for spam, reputation or policy

How-to guide
For:
Publishers and marketers, Workspace admins
Needs permission:
providers:view, deliverability:view, reports:view
In the app:
Sending providers, then Events & sync

Gmail 550 5.7.1 is a permanent refusal that Gmail uses for several reasons: the message looks unsolicited, the sending IP address or domain has a very low reputation, or a policy forbids the message. Gmail’s text tells you which one it is, and each needs a different fix.

What Gmail means

Section titled “What Gmail means”

These are the texts newsletter senders meet most often with 550 5.7.1:

This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.

This message is likely suspicious due to the very low reputation of the sending IP address. To best protect our users from spam, the message has been blocked.

The same text exists for “the very low reputation of the sending domain”. Other 550 5.7.1 texts include:

  • “The user or domain that you are sending to (or from) has a policy that prohibits the email that you sent.” Gmail adds gcdp to errors that come from a custom rule a Google Workspace administrator created.
  • “The IP you’re using to send email is not authorized to send email directly to our servers. Use the SMTP relay at your service provider instead.”
  • “This message is not RFC 5322 compliant”, with the header that is missing, duplicated or malformed.
  • “This email has been rate limited.”

Source: Gmail SMTP errors and codes, Google Workspace Help. Checked October 2026.

Why it happens

Section titled “Why it happens”
  • Likely unsolicited. Gmail’s filters judge the mail as unwanted: contacts who didn’t opt in or stopped reading, a high spam rate, or content that looks like spam.
  • Low reputation. The sending IP address or domain has a history of unwanted mail, or is new and sends a lot at once.
  • Policy. The recipient’s Google Workspace administrator blocks the message (gcdp), or Gmail doesn’t accept direct delivery from the IP address, which can happen when you send from your own server.
  • Headers. The message breaks RFC 5322, for example with a missing or duplicate From header.

How ReputeCast classifies it

Section titled “How ReputeCast classifies it”

The bounce class follows Gmail’s text:

Gmail’s text Bounce class
Likely unsolicited email, or not RFC 5322 compliant (both mention spam) spam_block
Very low reputation of the sending IP address or domain reputation
A policy prohibits the email, the IP isn’t authorized, rate limited, or the bare code policy_block

All three classes share the report row Blocked · policy or reputation. The refusal is about the sender, so most built-in adapters record a soft bounce and nothing is suppressed; some sending providers report it as permanent and then the address is suppressed. See when ReputeCast suppresses an address.

Before you begin

Section titled “Before you begin”
  • providers:view to read the event log.
  • deliverability:view for the domain, IP and blocklist checks.
  • reports:view to compare campaigns.

Find the cause and fix it

Section titled “Find the cause and fix it”
  1. Read Gmail’s text. Open Sending providers, then Events & sync, filter Event type to Soft bounce or Hard bounce, and search for a Gmail recipient. Original code · diagnostic shows which 550 5.7.1 you got.
  2. For likely unsolicited, look at who received the campaign. Send only to contacts with consent, exclude those who stopped opening (keep your list healthy), and check the content warnings the composer shows.
  3. For low reputation, open Deliverability, then Health: check the domain and IP health and whether the IP address or domain is on a blocklist. If the IP address or domain is new, slow down and warm it up.
  4. For a policy with gcdp, the recipient’s organization blocks the message. Nothing in your setup causes it; the recipient can ask their administrator to allow your mail.
  5. For IP not authorized, send through a sending provider instead of delivering straight from your own server, or relay your server’s mail through one.
  6. For not RFC 5322 compliant, look at the header Gmail names. If you send through the generic HTTP adapter or a community adapter, check the headers its mapping adds.

Check that it worked

Section titled “Check that it worked”
  • The next campaign’s report has fewer or no 550 5.7.1 entries in Original codes.
  • Deliverability shows no blocklist listing for your sending IP addresses and domains.

Troubleshooting

Section titled “Troubleshooting”
  • Only one sending provider’s mail is blocked. Its IP addresses are the likely cause. Route the Gmail share through another sending provider with a route while you fix it.
  • You see both the unsolicited and the low-reputation texts. Work through step 2 before step 3: both texts say Gmail is protecting its users from spam.
  • Gmail’s complaints are high too. Read bounces, complaints and provider limits.
Section titled “Related”
Report a problem with this pageReputeCast websiteHostReputeContent licensed under CC BY 4.0