Defaults.Exposed › Fixes › Guides
Gmail "550-5.7.1 Message Blocked" — Decode the Bounce and Fix It (2026)
Published 2026-07-08
Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.
Gmail returns 550-5.7.1 when it blocks a message for policy reasons rather than a missing record: a sending or receiving domain’s policy, an IPv6 connection without reverse DNS, or suspected spam. Of the 12,145,313 domains that authorise Google’s own servers in SPF, only 18.5% enforce DMARC, according to the Defaults.Exposed census of 261 million domains.
550-5.7.1 is Gmail’s oldest catch-all rejection, and the fix depends on the sentence after the code in your bounce. Below: a decoder table for the exact wording, then the fix path per variant — policy rejections, IPv6 servers without reverse DNS, spam or content blocks — plus the look-alike codes people confuse it with, including the 5.7.26 family Google now uses for the DMARC-policy rejection that older references filed under 5.7.1.
What does Gmail’s 550-5.7.1 actually mean?
In the SMTP enhanced-status scheme (RFC 3463), every 5.7.x code means “permanent failure, policy reasons”. Gmail uses 550-5.7.1 as its legacy policy family: sender- or recipient-policy blocks, spam-reputation blocks, and — the variant that surprises most admins — mail arriving over IPv6 from a server with no reverse-DNS (PTR) record.
Google has been re-coding variants over time. The DMARC-policy rejection (“not accepted due to domain’s DMARC policy”) now sits under 550-5.7.26 in Google’s current reference, though older bounces in the wild may still show it as 5.7.1; the content-security block is now coded 552 5.7.0. Two other siblings get confused with 5.7.1: 550-5.7.26, the authentication-requirements family (its own guide), and 550-5.7.25, the missing PTR code on any IP version. Whatever the code, decode the text below.
Which 550-5.7.1 variant do you have?
Match the wording in your non-delivery report (NDR). Google adjusts these strings between years — match the gist, not the punctuation.
| Your bounce reads like… | What it means | Your fix path |
|---|---|---|
| ”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.” | Your server delivered over IPv6 with no (or non-matching) reverse DNS | PTR record for the IPv6 address, or relay via your provider’s smarthost (below) |
| “The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.” | A policy block — the recipient’s, or your own domain’s | Contact the receiving admin; if your own domain’s DMARC is the policy in play, see below |
| ”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.” | Spam/reputation block on your content, IP, or domain | Postmaster Tools + list hygiene + one-click unsubscribe (below) |
| “This message is likely suspicious due to the very low reputation of the sending domain” (or “…sending IP address”) | Reputation block — domain or IP | Same reputation path (below) |
| “Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.” — coded 550-5.7.26 in Google’s current reference; older bounces may still show 5.7.1 | Your own DMARC policy told Gmail to reject an unauthenticated message | Find the unauthenticated source — do not loosen the policy first (below) |
| “…blocked because its content presents a potential security issue.” — now coded 552 5.7.0 | Content/policy block (attachment type, link reputation) | Remove the flagged content class; check links and attachments |
| Code is 550-5.7.25, “the sending IP address doesn’t have a PTR record” | Missing reverse DNS on any IP version | Same rDNS fix as the IPv6 variant |
| Code is 550-5.7.26 | Authentication-requirements family, not 5.7.1 | See the 550-5.7.26 guide |
| Code is 421-4.7.0, “Try again later, closing connection.” | Temporary deferral — rate or reputation, not a permanent block | Slow down, fix authentication and spam rate; it usually clears |
How do you fix a 550-5.7.1 bounce?
- Run the free scan at defaults.exposed — it grades your SPF, DKIM and DMARC as the world sees them, before you touch DNS, and shows whether the DMARC variant is even possible for your domain.
- Read the full NDR text against the decoder table — the sentence, not the code, identifies the cause.
- DMARC variant: find which sending source failed authentication and fix that source (next section).
- IPv6/PTR variant: add matching reverse DNS for the server’s IPv6 address, or relay through your provider’s smarthost.
- Spam/policy variant: Postmaster Tools, spam rate below 0.10% (Google’s hard requirement ceiling is 0.30%), list hygiene, RFC 8058 one-click unsubscribe.
- Re-send a test to a Gmail mailbox and re-scan — confirm the bounce is gone and the grade reflects it.
The bounce mentions your DMARC policy — why that’s your policy working
Google’s current reference codes this string as 550-5.7.26, but older bounces and third-party docs still show it under 5.7.1 — either way the mechanics are identical. It reads backwards until you see it: 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 exactly what you asked — reject. Your fence held. The question is what got caught in it: a forgotten legitimate sender (a CRM, an invoicing tool, a newsletter platform) or an actual spoof.
So don’t loosen the policy as step one. Find the unauthenticated source. Two traps account for most cases:
- SPF passes, but on the wrong domain. Receivers evaluate SPF against the Return-Path (RFC5321.MailFrom) domain, not the From header. A SaaS tool sending “from” you usually passes SPF on its own bounce domain, which doesn’t align with your From domain — so DMARC still fails. Walkthrough: DMARC fails but SPF and DKIM pass.
- DKIM passes, but with the default signature. Google Workspace’s
gappssmtp.comand Microsoft’sonmicrosoft.comdefaults verify fine and align with nothing. See DKIM passes but DMARC still fails.
This variant is rarer than you’d think: 27,640,987 of 261,086,232 domains — 10.59% — enforce a DMARC policy of quarantine or reject, according to the Defaults.Exposed census (2026-06-29). The other 89.41% never see this bounce because they have no fence to hold. Fixing the source, not the policy, is covered end-to-end in the DMARC fix guide.
The bounce mentions IPv6 sending guidelines — the reverse-DNS fix
Modern servers often connect to Gmail over IPv6 by default, and Google requires the connecting IPv6 address to have a PTR record that resolves to a hostname which resolves back to the same address (forward-confirmed reverse DNS). Miss that, and every message gets 550-5.7.1 regardless of how clean your SPF is.
Three fixes, in order of preference:
- Set the PTR record for your server’s IPv6 address — done where the IP lives (your VPS host or ISP control panel, not your domain’s DNS zone), with a matching AAAA record pointing back.
- Relay through your provider’s smarthost. If you can’t control rDNS, route outbound mail through your email provider’s or ISP’s relay, which already has proper rDNS.
- Prefer IPv4 transport as a stopgap. It usually hides the symptom because your IPv4 address has a PTR — a workaround, not a fix. Set the IPv6 PTR when you can.
The bounce says “likely unsolicited email” — the reputation path
Here authentication may be fine, but Gmail’s filters don’t trust the mail. Authentication is the floor, not the ceiling — among the 12,145,313 domains authorising _spf.google.com, only 8.0% lock SPF down with a strict -all, so a passing check says little on its own. (Full comparison: which email provider gives the strongest SPF defaults.)
The reputation checklist:
- Register in Google Postmaster Tools and watch the spam-rate dashboard — keep it below 0.10%, and never let it reach the 0.30% ceiling Google’s bulk-sender guidelines set as a hard requirement.
- Clean your list. Drop non-engagers and anything purchased or scraped; send only to people who asked.
- Implement RFC 8058 one-click unsubscribe on bulk mail — required by Google’s rules, and every unsubscribe that isn’t a “spam” click protects your rate.
- Keep authentication aligned (SPF and DKIM on your own domain) so reputation accrues to a domain you control.
Frequently asked questions
Is 550-5.7.1 the same as 550-5.7.26? No. 550-5.7.26 is Gmail’s authentication-requirements family (SPF/DKIM missing or failing) — and Google’s current reference also files the DMARC-policy rejection there. 550-5.7.1 is the older policy family: recipient- and sender-policy blocks, IPv6-without-PTR, spam and reputation blocks. The bounce text, not the number, tells you which fix applies (as of 2026-06-29 and current Google guidelines).
Should I set my DMARC policy back to p=none to stop the bounces? That stops them by tearing down the fence. Only 10.59% of the 261,086,232 domains in the Defaults.Exposed census (2026-06-29) enforce DMARC at all; if you’re one of them, keep it and fix the unauthenticated source — loosening the policy re-opens exact-domain spoofing.
Why does Gmail block my mail when my SPF record passes every checker? Checkers test the record; Gmail tests the message. SPF is evaluated against the Return-Path domain, not the visible From address, so a pass on a vendor’s bounce domain does nothing for your DMARC alignment — and reputation blocks ignore SPF entirely. The free scan shows which layer actually fails.
Does 550-5.7.1 mean my IP is on a blacklist? Not necessarily. Gmail runs its own reputation system; you can be blocked by Google while on no public blocklist. Check Postmaster Tools for Google’s view — and note that fixing authentication prevents future damage but doesn’t by itself reset a poor sending reputation.
Send the owner the report
Once the bounce is fixed, re-run the scan and forward the graded report to the business owner or client whose mail was bouncing. It shows, in plain English, what was broken, what you fixed, and where the domain now stands against the 261-million-domain baseline — exactly what they need for the insurance renewal or client security questionnaire that asks “do you authenticate your email?”. A bounce fixed silently is invisible work; a before-and-after report is proof.
Check your domain → · Gmail 550-5.7.26 — the fix in requirement order → · Fix DMARC → · How we grade → · Aggregate data only. Data stored and processed in the EU.