550 5.7.26: Unauthenticated Email Is Not Accepted (Gmail)

A 550 5.7.26 bounce from Gmail means the message failed authentication badly enough that Gmail refused it outright. Either it passed neither SPF nor DKIM, your SPF record ends in -all and the sending IP isn't in it, or your domain publishes a DMARC policy of p=reject and the message failed DMARC. The fix is almost always in DNS or in the sending service's settings, not in the content.

It's a permanent rejection, so the message wasn't retried. Resend once authentication passes.

What the bounce says

Gmail documents three versions of 5.7.26. Which one you got tells you where to look.

No passing SPF or DKIM at all:

550 5.7.26 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 [example.com] with
ip: [203.0.113.7] = did not pass. For instructions on setting up
authentication, go to https://support.google.com/mail/answer/81126#authentication

SPF hard fail:

550 5.7.26 The (E)MAIL FROM domain [example.com] has an SPF record with a
hard fail policy (-all) but it fails to pass SPF checks with the ip:
[203.0.113.7]. To best protect our users from spam and phishing, the message
has been blocked.

DMARC policy:

550 5.7.26 Unauthenticated email from example.com is not accepted due to
domain's DMARC policy. Contact the administrator of example.com domain if
this was legitimate email.

In real bounce logs the code is usually written 550-5.7.26 on every line but the last. Older bounces may also use different wording ("This mail is unauthenticated, which poses a security risk..."). Same code, same meaning.

What it means

Gmail's sender guidelines require every sender, at any volume, to authenticate with SPF or DKIM. Bulk senders (more than 5,000 messages a day to personal Gmail accounts) need SPF, DKIM and DMARC, with the From domain aligned to SPF or DKIM. Google's FAQ says unauthenticated messages may be rejected with 5.7.26, and Google ramped up enforcement with temporary and permanent rejections starting in November 2025.

The DMARC version is a little different. That one isn't Gmail's own rule. Your domain published p=reject, which is an instruction to every receiver: if a message claiming to be from us fails DMARC, refuse it. Gmail is doing what you asked. This version can hit mail to Google Workspace recipients too, not just @gmail.com addresses.

Common causes, most likely first

1. A sending service that was never set up. Your main ESP is signed and in SPF, but the CRM, helpdesk, invoicing tool or website contact form sending as your domain isn't. Those messages fail, and if your DMARC policy is p=reject, they bounce.
2. SPF broken by the 10-lookup limit. Once an SPF record needs more than 10 DNS lookups, it returns a permanent error (permerror), and SPF no longer passes for anything. Every service you added over the years counts. See the SPF lookup limit guide.
3. DKIM pending or broken. The DKIM record was never published, the selector in the signature doesn't match the DNS record, a key was rotated without updating DNS, or the record was pasted with a line break in the middle.
4. Alignment failure under DMARC. SPF and DKIM both pass, but for the ESP's domain instead of yours. DMARC needs at least one of them to match the domain in the visible From address.
5. Forwarding. A mailbox forwards your message to Gmail. The forwarding server's IP isn't in your SPF record, so SPF fails. If the forwarder also changes the subject or footer, DKIM breaks too. Google's forwarding guidance notes that forwarded messages often fail SPF.

How to fix it

1. Pull the full bounce and identify the version. "Unauthenticated" with DKIM and SPF results means nothing passed. "Hard fail policy" points at SPF. "DMARC policy" means alignment or authentication failed under p=reject.
2. Find the sending source. Look at the IP in the bounce and the service that generated the message. If you have the original message, run its headers through the header analyzer to see the SPF, DKIM and DMARC results and which domains they evaluated.
3. Check your records. Run your domain through the email checker to see what SPF, DKIM and DMARC currently say, and the SPF analyzer to count lookups.
4. Fix SPF. Add the missing service's include or IP. If you're over 10 lookups, remove services you no longer use before you consider flattening.
5. Turn on DKIM with your own domain. In each sending service, set up custom DKIM so the signature uses d=example.com (or a subdomain), not the provider's default domain. DKIM is what survives forwarding, so this is the fix that matters most.
6. Fix alignment. If the service supports a custom return-path (bounce) domain, set it to a subdomain of yours so SPF aligns as well. One aligned pass is enough for DMARC, but two is sturdier.
7. Don't panic-edit DMARC. Dropping from p=reject to p=none will stop the DMARC version of this bounce, but it also reopens your domain to spoofing. Fix the failing source first. If you need breathing room for a legitimate stream while you fix it, move to p=quarantine briefly and set a date to move back. The DMARC fail guide covers the trade-offs.

How to confirm it's fixed

Send a test from the affected service to a personal Gmail address. Open it, choose "Show original," and check that SPF and DKIM both say PASS and that DMARC says PASS. Then check that the DKIM d= domain or the SPF domain matches your From domain.

Then watch your bounce logs and DMARC aggregate reports for a few days. The source should show as aligned and passing. The DMARC overview explains how to read them.

How to keep it from coming back

• Keep an inventory of every service that sends as your domain, and make "set up DKIM and SPF" part of onboarding any new one.
• Read your DMARC aggregate reports, or have something read them for you. A new failing source shows up there before it shows up as a pile of bounces.
• Re-count SPF lookups whenever someone adds an include.

When to get help

If you've fixed the obvious records and 5.7.26 keeps showing up, or you can't tell which of a dozen services is sending the failing mail, it's worth having someone read your DMARC reports and headers with you. Get in touch.

FAQ

Does 5.7.26 mean I'm on a blocklist?

No. It's an authentication failure, not a reputation block. No blocklist is involved and there's nothing to request removal from. Fix SPF, DKIM or DMARC and the bounces stop. If you're seeing a reputation-based Gmail block, that's 550 5.7.1 or 421 4.7.28.

I only send a few emails a day. Does this still apply?

Yes. The SPF-or-DKIM requirement applies to every sender to personal Gmail accounts, at any volume. The 5,000-a-day threshold only adds DMARC, alignment and one-click unsubscribe on top.

Why does SPF pass in my checker but Gmail says it failed?

Checkers usually test your From domain, but SPF is evaluated against the envelope sender (the return-path) and the actual sending IP. If your ESP uses its own return-path domain, or the mail went through a forwarder, Gmail checked a different domain or IP than you did. The headers of a real bounced or delivered message will show what Gmail actually evaluated.