Gmail 550-5.7.1 message blocked

Gmail 550-5.7.1 message blocked

Gmail returns 550-5.7.1 when it refuses a message on policy grounds, and the code stops there. The sentence after it names the cause: your own DMARC policy, an IPv6 connection with no reverse DNS, a rule on the recipient’s side, or a spam or reputation filter. Each of those has a different fix, so open the non-delivery report, find the full line, and match the wording below before you change anything.

Why the number on its own tells you nothing

RFC 3463 defines the enhanced status codes that follow the three-digit SMTP reply, and every 5.7.x code means the same thing: permanent failure, for policy reasons. 550-5.7.1 is Gmail’s legacy policy family. You’ll see it written as 550-5.7.1 in a raw SMTP transcript and as 550 5.7.1 in most bounce messages, and they’re the same code.

Google has moved some of its most-quoted strings to other codes over the years, so a fix you find filed under 5.7.1 may be for a bounce your server no longer receives. The DMARC-policy rejection now sits under 550-5.7.26 in Google’s current reference, and the content-security block is coded 552 5.7.0. Older bounces in the wild can still carry those strings under 5.7.1, which is why the wording identifies your fix and the code doesn’t. Google adjusts the strings between years as well, so match the gist and ignore the punctuation.

Match the sentence in your bounce

Find the line in your NDR that starts with the code and read what follows it.

Three look-alike codes end up filed under 5.7.1 by people searching for help. 550-5.7.26 is the authentication-requirements family, where SPF and DKIM both failed. 550-5.7.25 is “the sending IP address doesn’t have a PTR record”, on any IP version, and it takes the same reverse DNS fix as the IPv6 variant. 421-4.7.0 “Try again later, closing connection.” is a temporary deferral rather than a permanent block: slow your sending rate, fix authentication and spam rate, and it normally clears on its own. The email delivery code router covers the rest of the family.

The IPv6 variant: a PTR record you set outside your DNS zone

This is the variant nobody expects, because SPF and DKIM can be perfect and the mail still bounces. Modern servers connect to Gmail over IPv6 by default when they have an address, and Google requires that connecting IPv6 address to have a PTR record that resolves to a hostname, and that hostname to resolve back to the same address. That’s forward-confirmed reverse DNS, and it needs a matching AAAA record pointing back at the IP. Miss any part of it and Gmail refuses the message with this string.

Most readers go looking for the PTR in the wrong place. Reverse DNS lives with the IP address, so you set it in the control panel of whoever gave you that address: your VPS host or your ISP. Your domain’s DNS zone has no say in it, and adding records there won’t help. Of the 173,216,907 domains where reverse DNS could be checked in the September 2026 census, 38,367,943 (22.2%) have no PTR record at all, so if you’ve never set one, you’re in a large crowd.

There are three ways out, and they go in this order.

Set the PTR for your server’s IPv6 address in the host’s or ISP’s panel, and check that the hostname it names has an AAAA record pointing back at the same address. A PTR pointing at a hostname whose AAAA points elsewhere fails the check.

If you can’t control reverse DNS, relay outbound mail through your provider’s or ISP’s smarthost. Its IPs already carry correct reverse DNS, and your server hands the mail to it instead of talking to Gmail directly.

As a stopgap only, prefer IPv4 transport. Your IPv4 address probably has a PTR, so the bounce stops, and the IPv6 problem sits there untouched. Set the IPv6 PTR when you can.

The DMARC variant: your own policy doing what you told it

Google’s current reference codes this string as 550-5.7.26, and older bounces and third-party write-ups still show it under 5.7.1. The mechanics are identical either way. Gmail checked a message claiming to be from your domain, found that neither SPF nor DKIM passed with alignment, looked up your DMARC record, and did what the record asked. The question is what got caught: a legitimate sender you’d forgotten about (a CRM, an invoicing tool, a newsletter platform) or a real spoof.

So don’t loosen the policy as step one. Setting p=none stops the bounces by removing the protection, and it reopens exact-domain spoofing for anyone who wants it. Of the 316,600,902 domains in the September 2026 census, 36,598,026 enforce a DMARC policy of quarantine or reject; if you’re one of them, keep it. The DMARC pillar walks through the record itself.

Two traps account for most of these bounces. The first is SPF passing on the wrong domain. Receivers evaluate SPF against the Return-Path domain (RFC5321.MailFrom), and the visible From header plays no part in that check. A SaaS tool sending “from” you usually passes SPF on its own bounce domain, which doesn’t align with your From domain, so DMARC fails even though an SPF checker shows green.

The second is DKIM passing with the default signature. Google Workspace’s gappssmtp.com and Microsoft’s onmicrosoft.com defaults verify fine and align with nothing, so DMARC treats the message as unsigned. The gappssmtp signing piece shows how to turn on a signature in your own domain’s name.

The order of operations matters. Find the sending source that failed authentication, add it to SPF or give it an aligned DKIM key, and confirm the bounce has gone. Only then do you think about the policy, and by that point you’ll usually want to leave it where it is.

The spam and reputation variant

Here authentication may be fine, and Gmail’s filters don’t trust the mail anyway. Authentication is the floor for reputation, so a passing SPF check on its own does nothing to lift a content or reputation block. Gmail runs its own reputation system, which means a domain or IP can be blocked by Google while appearing on no public blocklist. Postmaster Tools is where Google’s own view of your domain is visible, and it’s the first place to look.

Register your domain in Google Postmaster Tools and watch the spam-rate dashboard. Keep the rate below 0.10%, and never let it reach the 0.30% ceiling that Google’s bulk-sender guidelines set as a hard requirement. Once you’re over that line, the block stays until the rate comes down.

Drop non-engagers from your list, along with anything purchased or scraped. Send only to people who asked to hear from you, because each “report spam” click counts against the rate and each quiet unsubscribe doesn’t.

Implement RFC 8058 one-click unsubscribe on bulk mail. Google requires it, and it gives recipients a way to leave that costs you nothing in reputation.

Keep SPF and DKIM aligned on your own domain, so the reputation you build accrues to a domain you control rather than to a vendor’s bounce domain. Fixing authentication stops future damage; it doesn’t by itself reset a poor sending history, so expect the recovery to take weeks of clean sending.

Fix it, then prove it

The fixes on this page are free. A PTR record costs nothing at the host, an SPF include or a DKIM key costs nothing in DNS, and Postmaster Tools is a free dashboard. The expensive part is guessing, which is why the free scan earns its place before you edit anything: it shows which layer is failing as the world sees it, so you fix the right one first.

Once the bounce is gone, send a test to a Gmail mailbox and read the headers for a pass on both SPF and DKIM with alignment. Then run the scan again to confirm the grade moved with the fix, and keep the report, because the next time a bounce arrives you’ll want to know what the domain looked like when it was working.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.