Provider deliverability · Gmail (personal Gmail + Google Workspace recipients)

Your email has been blocked because the sender is unauthenticated: the Gmail fix

Samuel Chenard

By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 17, 2026

Gmail returns "blocked because the sender is unauthenticated" when a message passes neither SPF nor DKIM for your domain. Under Google's February 2024 sender requirements, unauthenticated mail is spam-foldered or, as here, refused outright. The fix is DNS: publish SPF and DKIM for every service that sends as your domain, confirm both pass and align, then re-send.

The 30-second check

The notice names the problem for you: authentication. Run the domain from your From address through the free DMARC checker below. In one pass it shows whether your SPF, DKIM, and DMARC records exist, what they currently say, and which check Gmail could not verify when it refused the message.

Check your domain now

Enter your sending domain and the check runs instantly on the next page. Free, no signup.

Why Gmail is blocking your email

Likely causeWhat's happening
A service sends as your domain with no passing SPF or DKIMThe literal meaning of the notice. Gmail checked the connecting IP against your SPF record and looked for a DKIM signature that validates for your domain; neither passed, and Google's sender guidelines state that unauthenticated mail "might be marked as spam or rejected with a 5.7.26 error" (checked 2026-07-17). The usual culprit is a CRM, invoicing app, scan-to-email copier, or ticketing system nobody ever added to DNS.
DKIM signs the provider's domain instead of yoursMany platforms sign with their own default domain (like sendgrid.net) until you finish their custom-domain setup. The signature is cryptographically valid, but not for your domain, so when SPF also misses, Gmail still counts the message as unauthenticated.
Your SPF record ends in -all and the sending IP isn't listedGmail documents a separate variant of this rejection for SPF hard fails: your record explicitly tells receivers to refuse mail from unlisted IPs, and Gmail takes you at your word. A migrated mail host, a provider that changed IP ranges, or a flattened SPF record that drifted out of date all land here.
Your own DMARC policy ordered the rejectionIf your domain publishes p=quarantine or p=reject and the message fails both aligned SPF and aligned DKIM, Gmail's bounce says the mail was refused due to the domain's DMARC policy. That is enforcement working as designed. The fix is authenticating the legitimate source, never weakening the policy.
You crossed Gmail's bulk-sender line without the full stackGoogle counts 5,000+ daily messages to Gmail accounts across your primary domain and all its subdomains together, per its sender-guidelines FAQ (checked 2026-07-17). Bulk senders must pass both SPF and DKIM, publish DMARC, and align the From domain. Marketing, transactional, and notification streams on three subdomains can cross the line while each looks small on its own.
Forwarding broke SPF and no DKIM signature survivedA forwarder re-sends the message from its own IP, which your SPF record doesn't cover. If the forwarder also modified the body (footers, subject tags), the DKIM signature breaks too, and the forwarded copy arrives at Gmail with nothing passing.
Gmail's late-2025 enforcement ramp caught a stream it used to tolerateGoogle's sender-guidelines FAQ says Gmail began ramping up enforcement on non-compliant traffic in November 2025 (checked 2026-07-17). Streams that skated through 2024 and 2025 with partial authentication are now the ones producing sudden rejection notices with no change on the sender's side.
Triage flow for Gmail's sender-is-unauthenticated block: check SPF coverage for the sending service, check that DKIM signs your own domain, check whether your DMARC policy ordered the rejection, meet the bulk-sender bar at 5,000+ messages a day, then confirm spf, dkim, and dmarc all pass on a test before re-sending.

How to fix it, step by step

  1. Run your sending domain through the DMARC checker

    Use the free checker above (also at /tools/dmarc). It reads your live SPF, DKIM, and DMARC records the same way Gmail does and shows which leg is missing or failing, so you start from evidence instead of the bounce text alone.

  2. Identify the message stream that tripped the notice

    Gmail's rejection includes the domain and IP it evaluated. Match that IP to a sending service, then pull your DMARC aggregate reports for the complete list of sources sending as your domain; the unauthenticated one is usually a line-of-business app nobody documented.

  3. Add every legitimate sender to your SPF record

    Include each platform's documented include: mechanism or IP range. Workspace's own servers need include:_spf.google.com (v=spf1 include:_spf.google.com ~all if Google is your only sender, per Google's SPF setup doc). Verify with the free checker at /tools/spf and stay under the 10-DNS-lookup limit.

  4. Turn on DKIM signing with your own domain at each service

    Generate DKIM keys for your domain in each service (for Workspace, in the Admin console), publish the CNAME or TXT records they give you, and enable signing. A signature for the provider's default domain doesn't count. Confirm each selector resolves at /tools/dkim.

  5. Meet the bulk-sender bar if you send 5,000+ a day

    Publish a DMARC record (Google accepts p=none as the minimum), align the From domain with SPF or DKIM, add one-click unsubscribe to marketing mail, and keep your Postmaster Tools spam rate below 0.3%, ideally below 0.10%. Google counts the 5,000 across your primary domain and all subdomains.

  6. Test against a live Gmail mailbox, then re-send

    Send a test to any Gmail address, open Show original, and confirm spf=pass, dkim=pass, and dmarc=pass. Because 550 rejections are permanent, the blocked messages will not retry on their own; re-send them once headers pass, and keep DMARC reports flowing so the next gap surfaces as a report line, not a bounce.

Related free tools: SPF checker · DKIM checker · Email security score · Domain reputation

If you send in volume: Gmail's published rules

Google's Email sender guidelines (in force since February 1, 2024, checked 2026-07-17) require every sender to authenticate with SPF or DKIM, plus valid forward and reverse DNS and TLS transmission. Senders of 5,000+ daily messages to Gmail accounts must pass both SPF and DKIM, publish a DMARC record (minimum p=none) with the From domain aligned, support one-click unsubscribe on marketing mail, and keep the user-reported spam rate in Postmaster Tools below 0.3% (Google's stated goal is below 0.10%). The 5,000 counts across your primary domain and all subdomains combined, and Google's FAQ notes Gmail began ramping up enforcement on non-compliant traffic in November 2025.

Check your standing with Gmail

Bounce codes you may be seeing

Blocks in this cluster surface as specific SMTP codes. Match yours below; the linked guides cover each code's verbatim provider messages and full fix.

The real root cause: unenforced authentication

This is the cleanest diagnosis in deliverability: no reputation mystery, no content filter to second-guess, just authentication that fails. It is also a preview of the world DMARC enforcement builds on purpose. When Gmail refuses unauthenticated mail claiming to be your domain, that is exactly what your own p=reject policy does to phishers who spoof you. The goal is to end up on the right side of that transaction: SPF and DKIM passing and aligned for every real sending service, DMARC reports confirming it week after week, and a policy enforced at p=reject so the only mail Gmail blocks in your name is mail you never sent. Monitoring shows you which senders fail; enforcement is what turns this bounce from your problem into a spoofer's.

Enforce it — don't just monitor it

Palisade's AI agent takes domains all the way to enforcement: hosted SPF, DKIM, DMARC, and MTA-STS records, DMARC reports monitored continuously, and policies advanced to p=reject automatically. Your first domain is free, and the full product is open for 15 days, no card.

Start free trialBook a demo

Free 15-day trial · No credit card · Your own domain free forever (NFR)

Fixing this across every client domain

One unauthenticated-sender bounce is a ten-minute DNS fix. Across a managed fleet it is structural: every client has a scan-to-email copier, a legacy CRM, or an invoicing tool sending unauthenticated, and Gmail's enforcement ramp finds them one ticket at a time. Palisade hosts and manages the SPF, DKIM, DMARC, and MTA-STS records for every client domain, surfaces unauthenticated senders from DMARC reports before Gmail starts bouncing them, and walks each domain to p=reject automatically. Tickets land in ConnectWise, HaloPSA, or Autotask through native PSA integrations, pricing runs $9 per domain per month (dropping to $7 at 100+ domains and $5 at 1,000+), and your own MSP domain is a free NFR domain to prove it on first.

Frequently asked questions

It means the message passed neither SPF nor DKIM for the sending domain, so Gmail could not verify it really came from you. Google's exact notice reads: "This email has been blocked because the sender is unauthenticated." The fix is publishing correct SPF and DKIM records for every service that sends as your domain.

Yes. The notice is the human-readable text inside Gmail's 550 5.7.26 rejection, which covers unauthenticated mail in several variants: no SPF or DKIM pass, an SPF hard fail, or a rejection ordered by the domain's DMARC policy. The full code breakdown, with every verbatim variant, lives in our 550 5.7.26 guide.

One passing check meets Gmail's baseline: all senders must authenticate with either SPF or DKIM. Bulk senders (5,000+ messages a day to Gmail accounts) must pass both, plus publish DMARC. Set up both regardless; SPF breaks under forwarding while DKIM usually survives it, and DMARC needs an aligned pass from at least one.

Google's sender-guidelines FAQ says Gmail began ramping up enforcement on non-compliant traffic in November 2025, so streams that slipped through with partial authentication now get refused. A newly added sending service, an expired DKIM key, or crossing the 5,000-a-day bulk threshold can also flip a working stream into blocked overnight.

No. This rejection happens during the SMTP conversation, before the message reaches any folder or filter the recipient controls, and asking every recipient's Workspace admin for an exception leaves all other Gmail recipients still blocked. The durable fix sits entirely on your side: SPF and DKIM records that pass and align for your From domain.

As soon as the records propagate, typically minutes to a few hours depending on your DNS TTLs. This is a per-message authentication verdict, so there is no reputation sentence to wait out. Because 550 is a permanent failure, bounced messages will not retry on their own: verify passing headers on a test, then re-send.

Google does not publish how rejected mail feeds its reputation models, so nobody can honestly quantify it. What is documented: Postmaster Tools tracks your domain reputation, IP reputation, and user-reported spam rate, and unauthenticated streams drag those dashboards down. Fix authentication first, then watch Postmaster Tools confirm the recovery.

Workspace covers Google's servers in SPF only if your record includes include:_spf.google.com, and signs DKIM with your domain only after you generate and publish a key in the Admin console. Domains that skipped either step, or that route some mail through printers and apps outside Google, still fail authentication and hit this block.

Related guides

Why are my emails going to spam in Gmail?Why does Gmail mark new domain emails as spam?Why is Yahoo blocking my emails?Why are my emails being blocked?550 5.7.26550 5.7.1421 4.7.0p=reject-all vs ~alladkim / aspfselector
Email deliverability, fixed: the full guide