Defaults.Exposed › Rešenja › Guides

Gmail 550 5.7.26 "The Sender Is Unauthenticated": The Fix, in Requirement Order (2026)

Objavljeno 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.26 when your message fails SPF and DKIM authentication checks. Fix it by making at least one of SPF or DKIM pass for your sending domain — most senders are missing this: of the 12,145,313 domains that authorise Google’s servers via _spf.google.com, only 18.5% enforce DMARC, according to the Defaults.Exposed census of 261,086,232 domains.

The fix is DNS work, not a support ticket: confirm your sending IP has reverse DNS, get SPF or DKIM passing for the domain Gmail actually checks, then make DKIM align with your From address and publish a DMARC record. Below is the full requirement order, plus a decoder table for the 550 5.7.26 family and its sibling codes.

What does Gmail error 550 5.7.26 mean?

Since Google’s 2024 sender requirements, every sender to Gmail — not just bulk senders — must pass at least one of SPF or DKIM for the sending domain. Fail both and Gmail rejects at SMTP time with 550 5.7.26 rather than delivering to spam.

The current full-text version reads: “This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass, SPF [domain] with ip: [ip] = did not pass.” Older bounces in the wild may still carry Google’s previous wording (“This mail is unauthenticated, which poses a security risk…”), and there is a rate-limit sibling — 421 4.7.26 This email has been rate limited because it is unauthenticated — with the same cause.

550 5.7.26 is not a single message but part of a family of codes, and the wording tells you which leg failed: Google’s current reference keeps three 5.7.26 strings (unauthenticated, SPF hard fail, DMARC policy) and moves the bulk-sender SPF-only and DKIM-only failures to their own codes, 5.7.27 and 5.7.30. Read the exact text before you touch DNS — it is your first diagnostic.

The scale of the gap is why this bounce is so common: 12,145,313 domains authorise Google’s mail servers in their SPF record (of 138,927,207 domains worldwide that publish SPF), yet only 18.5% have an enforcing DMARC policy and just 8.0% use strict SPF (-all). Most Google-hosted senders don’t meet Google’s own bulk-sender rules — and Gmail now enforces the basics on everyone.

Which 550 5.7.26 variant — or sibling code — do you have?

Match the bounce text you were sent against this table. Quoted fragments follow Google’s current SMTP error reference — always check them against your actual NDR, since Google revises the wording periodically.

How do you fix 550 5.7.26, in requirement order?

Google publishes no literal “check order” — but its requirements stack logically, so work through them in this requirement order. Most senders are unblocked after step 3; finish the list anyway, because the later steps are what keep you out of spam once you’re out of the bounce.

1. Run the free scan first. It reads your live SPF, DKIM, DMARC and DNS setup and shows exactly which leg is failing — diagnose before you touch DNS.
2. Give your sending IP reverse DNS (PTR). The connecting IP must have a PTR record whose hostname resolves back to the same IP. Mainstream providers handle this for you; it bites people sending from their own servers (and is the whole story behind sibling code 550 5.7.25).
3. Get SPF or DKIM passing. One guardrail first: receivers evaluate SPF against the Return-Path (RFC5321.MailFrom) domain, not the From header — check which domain your mail actually bounces to before deciding SPF “should” pass. Add your real sending services to that domain’s SPF record (full SPF walkthrough), or enable DKIM signing at your provider (full DKIM walkthrough). Either one passing clears the basic 550 5.7.26 block.
4. Make DKIM align with your From domain. For bulk sending — and for DMARC — Gmail wants authentication for the domain in your From address, not a vendor default. Google Workspace users: publish your own DKIM key (Workspace DKIM setup); a default gappssmtp.com signature passes DKIM but doesn’t align — a trap with its own guide. Aligned DKIM also survives forwarding, which SPF never does.
5. Publish a DMARC record. Google’s sender requirements ask for at least p=none with a reporting address. It’s a five-minute DNS edit — see “DMARC policy not enabled” for the honest first step and what p=none does and doesn’t protect.
6. Send over TLS. Any modern mail server or provider does this by default; if you run your own MTA, confirm outbound TLS is on — bulk mail without it now bounces with its own code, 550 5.7.29.
7. Add RFC 8058 one-click unsubscribe (List-Unsubscribe + List-Unsubscribe-Post headers) for marketing and subscribed mail.
8. Keep your spam rate below 0.10% in Google Postmaster Tools — and never let it reach 0.30%. Google’s requirement ceiling is 0.3%; its recommendation is to stay under 0.10%. Register your domain there; it’s Google’s own report card on you, and the spam-rate threshold is the requirement no DNS record can fix.

One thing this list won’t do: get you off a third-party blocklist. Authentication stops Gmail’s unauthenticated rejections; an IP with a spam history is a reputation problem with its own cleanup path — fixing auth prevents relapses, it doesn’t delist you.

Do the bulk-sender rules apply if you send less than 5,000 emails a day?

The full checklist — aligned authentication, DMARC published, one-click unsubscribe, spam rate — formally applies at 5,000+ messages a day to Gmail, and the bulk-only codes (5.7.27, 5.7.29, 5.7.30) come from that tier. But the authentication basics (SPF or DKIM passing, valid PTR) are enforced on everyone, which is why small senders hit 550 5.7.26 too. Treat steps 1–5 as mandatory at any volume, steps 7–8 as mandatory the moment you send in bulk. The full requirement set for both providers is in our data article on the Google and Yahoo sender requirements.

Frequently asked questions

Does 550 5.7.26 mean my domain or IP is blocklisted? No. It’s an authentication failure, not a reputation judgement — Gmail is saying “prove who you are”, not “we know you’re a spammer”. That’s good news: it’s fully fixable in DNS. The bad news is how normal it is — across the census of 261,086,232 domains (as of 2026-06-29), only 10.59% have an enforcing DMARC policy.

Will fixing SPF alone stop the bounces? Usually yes, for the basic variant — Gmail requires at least one of SPF or DKIM. But SPF is evaluated against the Return-Path domain and breaks under forwarding, so aligned DKIM (step 4) is the durable fix. Only 8.0% of the 12,145,313 Google-hosted sender domains use strict SPF (data as of 2026-06-29), so either way you’ll be ahead of the pack.

I use Google Workspace — why is Google bouncing my own mail? Because Gmail authenticates the domain, not the mailbox provider. A Workspace domain with no SPF record and no custom DKIM key sends mail Google itself can’t verify — of 12,145,313 domains that authorise Google’s servers, only 18.5% have enforcing DMARC (data as of 2026-06-29). Being a Google customer and meeting Google’s rules are different things.

How long after the DNS fix will Gmail accept my mail? As soon as the new records are visible — typically minutes to a few hours, up to 48 hours for slow TTLs. Auth fixes act immediately on the 550 5.7.26 check; spam-rate and reputation recovery (421-4.7.0, 5.7.28) take days to weeks of clean sending.

Send the owner the report

If you’re fixing this for a client, don’t close the ticket with “bounces resolved”. Re-run the free scan after your DNS changes and forward the graded report to the business owner. It shows, in plain English, that their domain now authenticates its email and where it still falls short — the evidence they need for cyber-insurance renewals and supplier security questionnaires. You fixed the bounce; the report proves it.

Check your domain free

See which leg of SPF, DKIM and DMARC Gmail is failing you on — privately and owner-only.

Check your domain → · Fix SPF → · Gmail “550-5.7.1 message blocked” → · How we grade → · Aggregate data only. Data stored and processed in the EU.