550 5.7.26 from Gmail — unauthenticated email rejected

A 550 5.7.26 from Gmail is a permanent rejection: the message bounced because Gmail could not confirm it was authenticated, and it will not be retried. Since the February 2024 sender rules and the move to permanent rejections in late 2025, this is one of the most common bounces a self-hosted sender meets — and the good news is that, unlike a vague reputation block, the code names the problem precisely. The catch is that 5.7.26 has two different wordings with two different fixes, and treating one as the other wastes time. This page shows you how to tell them apart and fix each, with the specifics that matter when you run your own PowerMTA or KumoMTA.

The two faces of 5.7.26

The code is the same; the sentence after it is the diagnosis. Read your bounce and match it to one of these.

The message says…	What it means	The fix
"…blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM."	Neither SPF nor DKIM passed for this message at all.	Add authentication — publish SPF and sign with DKIM so at least one passes.
"Unauthenticated email from [domain] is not accepted due to domain's DMARC policy."	A signature passed, but its domain did not align with your From, and your DMARC policy is reject.	Fix alignment — make the SPF or DKIM domain match the visible From domain.

Both are permanent and both are about identity, but the first means "you authenticated nothing" and the second means "you authenticated the wrong domain." The decoder below turns your exact wording into the steps to take.

Why Gmail sends 5.7.26

Gmail introduced enforced sender rules in February 2024 and, for non-compliant mail, moved from temporary deferrals to permanent rejections over the course of 2025. The baseline that drives 5.7.26 is simple: every sender must authenticate with SPF or DKIM, and bulk senders must additionally publish DMARC and align it. When a message arrives that authenticates with neither, or that fails DMARC under a reject policy, Gmail rejects it at the SMTP layer rather than filing it to spam — the message never reaches the inbox or the spam folder, it bounces back to you. The broader requirement set behind this is covered in the 2026 bulk sender requirements; 5.7.26 is the specific bounce you get when the authentication piece is unmet.

The reason this code became so visible is the way enforcement tightened. When the rules first took effect, Gmail leaned on temporary 4xx deferrals that merely delayed non-compliant mail and let it retry, which masked the problem — messages were slow but eventually trickled through. Over the course of 2025 that changed to permanent 5xx rejections, so the same unauthenticated mail that used to limp through now bounces outright with 5.7.26. If you authenticated nothing and only recently started seeing hard bounces, this shift is usually why: the underlying gap was always there, and enforcement simply stopped being forgiving about it. The practical implication is that there is no waiting it out — the message will not eventually arrive, so the fix has to come first.

Fix A — nothing authenticated ("requires SPF or DKIM")

This variant means the message carried no passing SPF and no passing DKIM. On a self-hosted setup you fix it in two places: DNS and your MTA. Publish an SPF record that names every IP your MTA sends from, and sign outgoing mail with DKIM, publishing the public key in DNS.

# SPF — TXT at your domain, naming your sending IPs
v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 -all

# DKIM public key — TXT at selector._domainkey.example.com
v=DKIM1; k=rsa; p=MIIBIjANBgkq...

The frequent self-hosted mistakes here are an SPF record that lists an old host or a control-panel IP rather than the actual PowerMTA or KumoMTA egress IP, and a DKIM key that the MTA signs with but whose public half was never published — so the signature is present but cannot be verified. PowerMTA signs through its domain-key directive and KumoMTA signs in its Lua policy; in both cases confirm the selector and key in DNS match what the MTA is using. The authentication guide walks through both records. Getting one passing clears this variant, but set up both — DKIM survives forwarding where SPF breaks.

Fix B — authenticated but not aligned ("DMARC policy")

This variant is subtler and catches careful operators: a signature passed, yet the message still failed DMARC because the passing domain did not match the visible From, and the From domain's DMARC policy is p=reject. DMARC only counts SPF or DKIM if it aligns with the From domain. So a DKIM signature whose d= is a different domain, or an SPF pass on an envelope/return-path domain that differs from the From, both authenticate something — but not the From identity DMARC checks.

The fix is alignment, not more authentication. Set your DKIM d= to your From domain, and make sure the envelope/return-path domain used for SPF matches it too. If you send from a subdomain, remember it inherits the organisational DMARC policy unless you publish its own, so an unsigned or misaligned subdomain stream gets rejected under the parent's p=reject. The p=reject troubleshooting guide covers the usual misaligned streams in detail. You can confirm alignment by reading the Authentication-Results header of a delivered seed:

Authentication-Results: mx.google.com;
  spf=pass (...) smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass (p=REJECT) header.from=example.com

The point is that header.d and smtp.mailfrom match header.from. When they do, DMARC passes and 5.7.26 clears; when they do not, it rejects no matter how cleanly the underlying SPF or DKIM passes on its own domain.

A worked example: tracing a 5.7.26

Consider a common self-hosted situation. You send a newsletter from news@example.com through PowerMTA. DKIM is configured, signing with d=mail.example.com. The envelope sender — the return-path PowerMTA uses for bounces — is bounce@send.example.com, which has its own SPF record that correctly lists the sending IPs. You publish p=reject at _dmarc.example.com. Everything looks set up, yet Gmail returns "Unauthenticated email from example.com is not accepted due to domain's DMARC policy."

Read the header and the cause is plain. SPF passes — but on send.example.com, the envelope domain, which does not match the From domain example.com. DKIM passes — but on mail.example.com, which also does not match example.com. Both mechanisms authenticate something, so the "requires SPF or DKIM" variant does not apply; but neither aligns with the visible From, so DMARC fails, and because the policy is reject, the message bounces with 5.7.26. The fix is one change: set the DKIM signing domain to d=example.com (the same selector key, published under example.com), so header.d matches header.from. DMARC then passes on the DKIM side regardless of the envelope domain, and the rejection clears. Nothing about the SPF setup was wrong; it simply was not the thing DMARC was measuring.

This is the pattern that traps experienced operators: every individual check is green in isolation, and the missing piece is alignment with the one domain Gmail cares about — the one your recipients see.

SPF or DKIM for alignment — which to rely on

DMARC passes if SPF aligns or DKIM aligns, so you only need one of them aligned, but they align differently and one is more dependable. SPF alignment depends on the envelope/return-path domain matching the From domain, which means controlling the bounce address your MTA uses — and SPF breaks the moment a message is forwarded, because the forwarding server becomes the new envelope sender. DKIM alignment depends on the d= domain matching the From domain, and a DKIM signature travels with the message, surviving most forwarding intact. For a self-hosted sender the practical advice is to make DKIM the alignment you rely on: sign with d= set to your From domain, publish the key, and you have aligned authentication that holds up even when mail is forwarded. Treat aligned SPF as the useful second mechanism rather than the primary one. Configuring both is best; depending on SPF alone for alignment is fragile. A useful habit is to confirm, every time you stand up a new From domain or sending subdomain, that its DKIM key is published and signing with a matching d= before any real mail goes out — that single check prevents the alignment variant of 5.7.26 entirely.

Common self-hosted causes

• SPF lists the wrong IP. The record names an old host or the panel server, not the MTA's actual egress IP, so SPF fails. A PermError from too many lookups counts as a failure too.
• DKIM public key never published. The MTA signs, but the selector's TXT record is missing or wrong, so DKIM cannot verify.
• DKIM d= does not match From. The signature passes on a different domain, so DMARC alignment fails — the classic "I have DKIM but still get 5.7.26."
• Subdomain inherits p=reject. Mail from a subdomain with no aligned authentication is rejected under the parent domain's reject policy.
• A new sending IP not in SPF. Adding an IP to a pool without updating SPF makes mail from that IP fail SPF immediately.
• Return-path domain differs from From. SPF passes on the bounce domain but does not align, so it does not satisfy DMARC.

Verify the fix before resending

Because 5.7.26 is a permanent 5xx, the wrong move is to keep resending the same message and hope — each attempt is rejected identically and adds another negative mark. Instead, after correcting the records, send a single seed to an inbox you can inspect and read its Authentication-Results header, confirming spf, dkim and dmarc all pass and align. External tooling such as a DKIM checker verifies the published key independently, and the SMTP code lookup confirms you are reading the bounce correctly. Allow the DNS changes to propagate within their TTL before the seed, then resume volume gradually once a real message passes.

The durable way to stay clear of 5.7.26 is to make aligned authentication part of the build rather than a reaction to a bounce. A sending setup where DKIM signs with the From domain, SPF lists exactly the IPs in use, and DMARC is published and aligned simply does not produce this error — and when you add a new sending IP or a new From domain later, updating SPF and confirming the DKIM domain at that moment prevents the rejection from ever appearing. The error is common precisely because these records drift: an IP changes, a subdomain gets added, a signing domain is left at a default. Re-checking alignment whenever the sending setup changes is what keeps it from recurring.

The same rejection at Yahoo and Microsoft

If Gmail is rejecting your mail for authentication, the other large providers will too — they adopted the same requirements, and they each have their own code for it. Yahoo returns 550 5.7.9 and Microsoft returns 550 5.7.515 for the equivalent failure: mail that is unauthenticated or fails the domain's policy. The underlying fix is identical, because it is the same SPF, DKIM and aligned DMARC that all three check. Fix the authentication and alignment once and you clear the rejection across Gmail, Yahoo and Outlook together.

Two per-provider nuances are worth knowing as you verify. Yahoo measures spam complaints against inbox-delivered mail only, so its tolerance is effectively tighter than Gmail's even when the headline rules match — a sender that just barely passes at Gmail can still be penalised at Yahoo. Microsoft, which began enforcing in May 2025, skipped the gradual deferral phase and bounces non-compliant bulk mail outright with 5.7.515. None of this changes the authentication fix; it just means you should seed-test all three providers after correcting your records rather than assuming a clean Gmail result covers everyone. The full cross-provider picture, including the complaint-rate thresholds and one-click unsubscribe, is laid out in the bulk sender requirements guide.

Related Gmail rejections

The same family of enhanced status codes names other specific failures, which is why reading the exact code matters. If your bounce is actually 5.7.25, the problem is reverse DNS — the sending IP lacks a matching PTR — and the fix lives in the reverse DNS guide, not here. A generic 5.7.1 is a broader policy or reputation block rather than a clean authentication failure. The advantage of 5.7.26 specifically is its precision: it tells you the problem is authentication or alignment, so there is no guesswork about reputation — repair the named protocol and the rejection clears.

The bottom line

Gmail's 550 5.7.26 is an authentication rejection with two wordings. "Requires SPF or DKIM" means you authenticated nothing — publish SPF for your sending IPs and sign with DKIM. "Due to domain's DMARC policy" means you authenticated the wrong domain — align the SPF or DKIM domain with your visible From under your reject policy. On a self-hosted PowerMTA or KumoMTA every one of these records and signatures is yours to set, which is why the error appears during setup and disappears for good once alignment is right. Read your exact wording, apply the matching fix, verify with the Authentication-Results header, and only then resume sending. If you are setting up a sending domain from scratch, get DKIM signing on your From domain and SPF listing your real sending IPs in place before the first campaign goes out, and 5.7.26 never appears in the first place.