What does Gmail error 550-5.7.26 mean?

It is Gmail's authentication rejection, and it covers three distinct problems. In one variant the sender has no working authentication at all — Gmail requires every sender to authenticate with SPF or DKIM. In another, the sending domain's SPF record has a hard-fail (-all) policy and the sending IP is not in it. In the third, the message fails the From domain's own DMARC policy. The bounce message itself names the variant and prints the authentication results; the fix differs for each, so the first step is always reading your exact bounce text.

My email works to most people but Gmail rejects it, sometimes only after forwarding. Why?

Forwarding changes the sending IP, so the forwarded copy fails SPF — that is expected behaviour, not a misconfiguration you can fully repair. What survives forwarding is a DKIM signature made with your From domain, if it stays intact. Microsoft states it plainly in its SRS documentation: rewriting the sender does not make forwarded mail pass DMARC; the only reliable way is DKIM signed with the From domain with the signature intact. If your mail is DKIM-signed by your domain and still fails after a list or forwarder modifies it, the remaining fix belongs to the forwarder (ARC adoption), not to your DNS.

Will deleting my DMARC record or relaxing it stop the 5.7.26 rejections?

It trades the error, not the outcome. Relaxing your policy silences the DMARC variant by removing the protection the policy exists for, and deleting DMARC can simply move you to a different rejection (senders without authentication hit Gmail's other authentication errors, and bulk senders are required to have DMARC). The correct fix is making a legitimate check pass with alignment — usually DKIM signed by your own domain, which you control.

Gmail · 550-5.7.26 · Authentication

Gmail rejected your email — 550-5.7.26: decode which of the three errors you actually have

First published 20 October 2026 · Error texts below are quoted from Google's own SMTP reference and verified against live bounce captures; the forwarding limits are quoted from Microsoft's and Google's documentation, not folklore.

550 5.7.26 “This mail is unauthenticated…”

The bounce already contains your diagnosis — Gmail prints the authentication results inside it. Most “fixes” on the internet skip reading them and prescribe for the wrong variant. This page starts with the reading.

Variant A: nothing authenticatesVariant B: SPF hard failVariant C: DMARC policy

The fast answer — match your bounce text first

If your bounce says…	Your variant	Your fix starts at
“…sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM,” with results like `DKIM = did not pass, SPF = did not pass`	A — No authentication	Fix 1: give the sending system SPF and DKIM, properly.
“…has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks with the ip…”	B — SPF hard fail	Fix 2: the sending IP is not in your record (or isn't your sender at all).
“Unauthenticated email from [domain] is not accepted due to domain's DMARC policy.”	C — DMARC policy	Fix 3: a sender of yours fails alignment under your own policy.
A 421/451 4.7.26 instead of 550	The temporary siblings	Rate-limiting or a temporary DNS problem on the authentication path — retries can legitimately succeed; if it persists past a day, treat it as the variant above it resembles.

Fix 1 (Variant A) — authenticate the thing that actually sent it

Identify the real sender from the bounce. The results line names the domain and IP Gmail evaluated. The sender is often not your mailbox: a website form, an invoicing tool, a CRM — something sending as your domain with no authentication arranged.
If it's your Google Workspace or Microsoft 365 mail: complete the base setup — SPF, DKIM, DMARC — for your domain. (Our complete guides: Workspace on Cloudflare, Workspace on GoDaddy, Microsoft 365 DKIM.) Gmail's bar for ordinary senders is SPF or DKIM; for bulk senders (5,000+/day to Gmail) it is SPF and DKIM and DMARC — set up all three regardless.
If it's a tool: use the tool's own domain-authentication flow (every serious sender platform has one) so it DKIM-signs with your domain, and add its SPF include to your single SPF record if it asks. A tool that can do neither must send from its own domain, not yours.
Verify: resend to a Gmail address; open the delivered message → Show original — spf=pass and/or dkim=pass naming your domain, and dmarc=pass.

Fix 2 (Variant B) — respect the hard fail you wrote

Your record ends -all: you told the world “any IP not listed is a forgery.” Gmail believed you. Either the IP in the bounce is a legitimate sender missing from your record — add its include: (inside your one SPF record, watching the lookup budget) — or it genuinely isn't yours, in which case the rejection is your SPF working as designed and there is nothing to fix.
Do not “fix” this by softening -all to ~all. That converts a clear signal into a shrug for every receiver, for all your mail, forever — to accommodate one sender you could have listed properly in two minutes.
Verify: the sender's next message passes SPF in Show original.

Fix 3 (Variant C) — your policy, your sender, your alignment

This bounce exists because your DMARC policy is already enforcing (quarantine/reject) and some sender of yours fails it. Find the sender: your DMARC aggregate reports list failing sources by IP and disposition — the rollout guide's Stage 1 reading method applies verbatim.
Authenticate that sender so it passes aligned: DKIM signed with your domain is the durable fix; SPF alignment breaks under forwarding (below).
Verify: reports show the source passing; a live test to Gmail shows dmarc=pass.

The forwarding truth — read this before chasing ghosts

If the failures happen only when mail is forwarded or passes through a mailing list, understand the mechanics before changing anything:

Forwarding changes the sending IP → the forwarded copy fails SPF by design. No DNS edit on your side changes that arithmetic.
What can survive is DKIM signed with your From domain, signature intact. Microsoft's own SRS documentation says it without varnish: rewriting the envelope sender “doesn't resolve the issue of forwarded messages not passing DMARC checks… the only reliable way for DMARC to pass is [DKIM signed with the From domain].” So your one real lever is: make sure your mail leaves DKIM-signed by your domain (for Microsoft 365 that means turning custom-domain DKIM on — it is off by default; for Workspace, completing the Authenticate-email step).
If your DKIM is right and a list/forwarder still breaks the signature by modifying the message, the remaining mechanism is ARC — and ARC is adopted by the forwarder, not by you. Google is explicit that ARC doesn't judge reputation and the original sender cannot add it. When the trail ends there, the honest answer is: the forwarder must adopt, or that path stays broken. Anyone selling you a DNS record that “fixes forwarding” is selling fiction.

The anti-fixes (each one trades the error, not the outcome)

Tempting move	What actually happens
Relax DMARC to p=none / delete it	Variant C goes quiet because the protection is gone; unauthenticated sending can still hit Gmail's other authentication rejections, and bulk senders are required to publish DMARC.
Soften SPF `-all` → `~all`	Every receiver downgrades your forgery signal, permanently, for one sender's sake.
“Just resend, it's a soft bounce”	550 is permanent for that message. Resends that “work” were the 451 temporary sibling, or took a different path.
Add any SPF record when the failing leg is DKIM alignment	Passing-but-unaligned SPF changes nothing in the results Gmail grades.

FAQ — issues behind this error

Google's own pages cite a “5.7.32” alignment code. Is that my error too?

It's a sibling in the same family (alignment-specific rejections), and Google's own pages are inconsistent about its exact form — one lists 421 5.7.32, another 4.7.32. Decode it the same way: read the printed results, identify the failing leg, fix that leg.

Postmaster Tools shows my domain — what am I looking for?

Google Postmaster Tools' authentication graphs: SPF, DKIM and DMARC pass rates for your domain's traffic to Gmail. A sudden DKIM-rate drop dated to a change you made is the fastest confirmation of which fix mattered.

None of the variants match — the bounce is from a tool's own domain.

Then the domain in the results is the tool's, and the authentication to repair is the tool's, inside the tool. Your DNS cannot authenticate mail sent as someone else's domain.

Sources

Google — SMTP error reference (support.google.com/mail/answer/3726730: the three 5.7.26 variants and the 4.7.26 siblings), Email sender guidelines (answer/81126, authentication section), the dedicated DMARC-policy bounce help page (answer/2451690), ARC guidance · Microsoft Learn — SRS documentation (forwarding and DMARC), custom-domain DKIM (verified in this site's earlier research: custom domains are unsigned until enabled).

Verification note: all three error variants and the temporary siblings were confirmed in Google's live SMTP reference on 20 October 2026 and cross-checked against independent live bounce captures, which carry a longer wording than the reference table — both forms are described in this guide so your bounce matches one of them.

Did this fix work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.