Gmail "Message blocked" 550-5.7.1 - How to Fix

Mail to Gmail recipients bouncing with "Message blocked" and error 550-5.7.1? Gmail rejected the message as likely unsolicited. Here is what the bounce means and how to fix the underlying cause.

The Error

The bounce your sender receives looks like this:

Message blocked

Your message to user@example.com has been blocked. See technical details below.

550-5.7.1 [203.0.113.10] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked. Please visit
550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError
550 5.7.1 for more information. d15-20020a170902b18f00b001d4 - gsmtp

The IP address in square brackets is the sending server Gmail evaluated. Note it - it identifies which of your systems is affected when more than one sends mail.

Why This Happens

Gmail rejected the message during the SMTP conversation, before delivery. This is different from spam filtering: a filtered message still lands in the recipient's spam folder, while a 550-5.7.1 message is refused outright and never reaches the mailbox at all.

The decision is driven by the reputation of your sending domain and IP, and the biggest single input is whether your mail is properly authenticated. In rough order of how often each is the culprit:

1. SPF, DKIM or DMARC failing - by far the most common cause
2. Poor IP reputation - often a shared IP at a hosting provider whose other tenants send badly
3. A high complaint rate - recipients marking your mail as spam
4. A new or dormant domain suddenly sending volume - no established reputation to draw on
5. Forwarding that breaks authentication - SPF fails when the sending IP changes but the envelope sender does not

Google now requires bulk senders to authenticate with SPF and DKIM, publish a DMARC policy, support one-click unsubscribe, and keep spam complaints below 0.30 percent. Domains that used to deliver on reputation alone increasingly do not.

Fix 1: Check Your Authentication Results

Diagnose before changing anything. Send a test message from the affected system to a Gmail address you control. If it is not rejected, open it, click the three-dot menu, and choose Show original.

The summary at the top shows:

SPF:   PASS with IP 203.0.113.10
DKIM:  'PASS' with domain example.com
DMARC: 'PASS'

Anything other than PASS is your starting point, and each failure mode has its own cause. SPF: SOFTFAIL means the sending IP is not authorised but your record ends in ~all, covered in Received-SPF: softfail. SPF: PERMERROR is a record that could not be evaluated at all, usually too many DNS lookups. A DKIM failure splits two ways — no key for signature when the selector is not published, and body hash did not verify when something modified the message in transit. And if SPF and DKIM both pass while DMARC still fails, the problem is alignment rather than authentication.

If the message is rejected outright and you cannot inspect it, check the published records directly:

dig +short TXT example.com | grep spf
dig +short TXT google._domainkey.example.com
dig +short TXT _dmarc.example.com

Fix 2: Publish a Correct SPF Record

For a domain sending through Google Workspace, publish a single TXT record at the domain root:

v=spf1 include:_spf.google.com ~all

Three things go wrong here regularly:

• Two SPF records. A domain must have exactly one. Two produces a permanent error and everything fails. Merge them into a single record with multiple include: mechanisms.
• More than ten DNS lookups. SPF permits ten, counting each include and the lookups it triggers. Exceeding the limit is a permanent error even though the record looks correct. Consolidate or flatten.
• A missing sender. Every service that sends as your domain - marketing platforms, ticketing systems, application servers - needs its mechanism in the record.

~all (softfail) is the right starting point. -all (hardfail) is stricter and appropriate once you are confident every sender is listed.

Fix 3: Enable DKIM in Google Workspace

DKIM is not on by default for a Workspace domain, and this catches out a lot of administrators.

1. Sign in to the Google Admin console.
2. Go to Apps > Google Workspace > Gmail > Authenticate email.
3. Select your domain and click Generate new record. Choose 2048-bit.
4. Publish the supplied TXT record at the host google._domainkey on your domain.
5. Wait for DNS to propagate - usually under an hour.
6. Return to the same page and click Start authentication.

Step 6 is the one people miss. Publishing the record without starting authentication leaves DKIM inactive.

DKIM matters more than SPF for forwarded mail, because a DKIM signature survives a change of sending IP while SPF does not.

Fix 4: Publish DMARC and Read the Reports

Add a TXT record at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=none changes no delivery behaviour - it only asks receiving servers to send you aggregate reports. Use those reports to find sending sources you had forgotten about, fix their authentication, and only then tighten:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com

and eventually p=reject.

Going straight to p=reject before the reports are clean will bounce legitimate mail from services you did not know were sending as your domain. That is the standard way this improvement becomes an outage.

Fix 5: Check Reputation in Postmaster Tools

Add and verify your domain in Google Postmaster Tools. It reports domain and IP reputation, spam complaint rate, and authentication pass rates as Gmail actually sees them - which is more useful than any external tester.

Look for:

• Domain reputation below High
• Spam rate above 0.10 percent, and certainly above 0.30 percent
• Authentication below 100 percent on SPF, DKIM or DMARC

If your application or server sends directly from a shared hosting IP, route it through the Google Workspace SMTP relay service or a dedicated sending provider instead. You inherit the reputation of whatever IP you send from, and on shared infrastructure that is not under your control.

Verify the Fix

# Confirm the published records
dig +short TXT example.com | grep spf
dig +short TXT google._domainkey.example.com
dig +short TXT _dmarc.example.com

Then send a test message to a Gmail address and use Show original to confirm:

SPF:   PASS
DKIM:  PASS
DMARC: PASS

All three passing, with delivery to the inbox rather than a bounce, is the confirmation that matters.

Prevention

• Audit SPF whenever you add a service that sends as your domain. An unlisted sender is the most common regression.
• Keep DMARC aggregate reports flowing to a monitored address and read them monthly, not only when something breaks.
• Send bulk and transactional mail from separate subdomains so a marketing campaign's complaint rate cannot damage the reputation of your password reset emails.
• Include a working one-click unsubscribe header on bulk mail. It is a requirement for bulk senders and it lowers complaint rates, which is what the rejection is ultimately measuring.
• Watch Postmaster Tools for reputation drift rather than waiting for the first bounce report.

Summary

1. Diagnose: send a test to Gmail, use Show original, read SPF, DKIM and DMARC
2. SPF: exactly one record, v=spf1 include:_spf.google.com ~all, under ten lookups
3. DKIM: generate in the Admin console, publish google._domainkey, then click Start authentication
4. DMARC: begin at p=none with rua, tighten only once reports are clean
5. Reputation: monitor Postmaster Tools and relay application mail rather than sending from shared IPs