How is 550 5.7.26 different from 550 5.7.1?

They come from different rulebooks. 5.7.1 (RFC 3463) means 'delivery not authorized' — most often a single SPF hard-fail or a DMARC reject. 5.7.26 (RFC 7372) is literally 'Multiple authentication checks failed': the message produced no aligned pass from SPF *and* no aligned pass from DKIM. Gmail uses 5.7.26 for its bulk-sender rule that took effect in February 2024, where every sender must authenticate with at least one of the two. 5.7.1 says 'a policy refused you'; 5.7.26 says 'you authenticated with nothing we accept.'

SPF passes and DKIM signs my mail, so why is it still 'unauthenticated'?

Because passing isn't the same as aligning. Gmail counts an authentication result only if it aligns with the domain in your visible From header. A marketing platform often passes SPF on its own bounce domain and signs DKIM with its own signing domain — both pass, neither matches your From, so from Gmail's point of view your domain authenticated with nothing. Fix it by publishing a DKIM key the platform signs *as your domain* (a CNAME the vendor gives you), or by aligning the Return-Path. Alignment, not a green pass somewhere, is what clears 5.7.26.

I send low volume. Do the February 2024 rules apply to me?

Partly. Google's bulk threshold — SPF and DKIM and a DMARC record — targets senders pushing more than 5,000 messages a day to Gmail. But the baseline requirement, set up SPF or DKIM, applies to everyone; Google has been tightening enforcement on all senders since 2024, moving from temporary 421 deferrals to permanent 550 rejections. Low volume doesn't exempt you from having at least one aligned authentication method.

Views: 28

550 5.7.26: Fix Gmail's Unauthenticated Email Block

550 5.7.26 means Gmail blocked your mail as unauthenticated. Fix it in 4 checks: SPF, DKIM, DMARC, and From alignment. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Your mail to Gmail bounces with 550 5.7.26 and a line like “This mail has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.” Nothing reached the inbox. This isn’t a spam-score problem or a reputation dip — Gmail refused the message at the door because it couldn’t tie the mail to your domain through either authentication method it trusts.

Symptoms

Bounce reads 550-5.7.26 with text about the sender being “unauthenticated” or authentication being required.
It started, or got worse, sometime after February 2024 — Google’s sender rules rolled out and tightened through 2024–2025.
Mail from your main platform delivers, but mail from a new tool or script bounces.
DMARC reports show SPF and DKIM both fail (or both unaligned) for the rejected source.
The same mail is accepted by smaller providers but rejected only by Gmail (and often Yahoo).

What 550 5.7.26 Actually Means

Read the code as two independent facts. The 550 is the SMTP reply (RFC 5321): a permanent failure — retrying the identical message won’t help. The 5.7.26 is the enhanced status code, and it’s precise: RFC 7372 defines X.7.26 as “Multiple authentication checks failed.” The message failed more than one authentication check against the receiver’s policy.

For Gmail specifically, those two checks are SPF and DKIM, evaluated for alignment with your From domain. Gmail’s sender guidelines, enforced starting February 1, 2024, require every sender to authenticate with at least one of them, and bulk senders (over 5,000 messages a day to Gmail) to publish SPF, DKIM, and a DMARC record of at least p=none. When a message produces no aligned SPF pass and no aligned DKIM pass, it has failed both checks Gmail cares about — 5.7.26, by the book.

The word doing the quiet work is aligned. A message can pass SPF and carry a valid DKIM signature and still be “unauthenticated” in Gmail’s eyes, because neither result matches the domain a human sees in the From field. That gap between “passes somewhere” and “aligns with my domain” is where most 5.7.26 bounces actually live.

Top 3 Causes

No authentication set up for the sending source at all. A new domain, a transactional script, or a freshly added app sends “as you” but you never published SPF, never configured DKIM for it, or both. Neither check can pass because neither exists. The tell: it’s a new or one-off sender, and your DNS has no DKIM selector for it.
SPF and DKIM pass, but neither aligns with your From domain. You send through an ESP or SaaS tool. SPF passes on the vendor’s bounce domain; DKIM is signed with the vendor’s domain. Both are “green,” but your From is you@yourdomain.com, so from Gmail’s alignment view your domain authenticated with nothing. The tell: your headers show spf=pass and dkim=pass yet Gmail still says unauthenticated — because it checked the vendor’s domain, not yours.
Bulk sender with no DMARC record. You’re over the 5,000/day-to-Gmail threshold, SPF and DKIM may even be fine, but there’s no DMARC record on your domain — which Gmail now requires for bulk senders. The tell: high volume to Gmail, and a _dmarc.yourdomain.com TXT lookup returns nothing.

Diagnose with DechoNet

Email Check pulls your domain’s SPF, DKIM, and DMARC records in one pass — so you can confirm SPF exists and resolves under the 10-lookup limit, a DKIM selector is published, and a DMARC record is present (the exact three Gmail’s bulk rule demands) before you touch a single sender.
Email Header Analyzer reads the Authentication-Results of a bounced or received message and shows the SPF and DKIM results and the domain each was evaluated against — the fastest way to catch the alignment gap where both “pass” but neither matches your From.

Resolution Checklist

Confirm the code is 5.7.26, not 5.7.1 or 5.7.7 — 5.7.26 means both authentication checks failed, so the fix is “make one align,” not “adjust a single policy.”
Run Email Check on your From domain and verify all three exist: an SPF record, a DKIM selector, and a DMARC record (at least p=none).
For each active sending service, set up DKIM as your domain — publish the CNAME/TXT selector the vendor provides so the signature aligns with your From, not the vendor’s.
Add every legitimate sending source to your v=spf1 record via the vendor’s documented include:, and keep total DNS lookups under 10 (RFC 7208 §4.6.4).
Use Email Header Analyzer on a real message to confirm at least one of SPF or DKIM now shows pass aligned with your From domain.
If you send in bulk to Gmail, publish a DMARC record even at p=none — its absence alone triggers 5.7.26 for bulk senders regardless of SPF/DKIM.

When to Escalate

If a vendor can’t offer domain-aligned DKIM (only their own signing domain), that’s a limitation on their side — push them for a custom DKIM/return-path setup, because without alignment their mail will keep hitting 5.7.26.
If all three records are correct and aligned and Gmail still rejects with 5.7.26, capture the full bounce and the message’s Authentication-Results header and take it to Google’s sender support or Postmaster Tools — the failing check is now theirs to explain.