550 5.7.26: why Gmail rejected your email

The Email Digit teamUpdated 6 Oct 2026

550 5.7.26 means Gmail refused your message because it could not authenticate it: SPF and DKIM both failed, or your domain's DMARC policy told Gmail to reject mail that fails. The fix is to make sure the service sending your mail is in your SPF record, signs with DKIM on your own domain, and that you publish a DMARC record those checks align with.

The exact bounce messages

Gmail uses the 5.7.26 code for several related failures. The text after the code tells you which one you hit. These are the variants in Google's current error reference:

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: [192.0.2.10] = did not pass.

Neither SPF nor DKIM passed. This is the most common one.

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.

Your DMARC record is set to p=reject and this message did not pass DMARC. SPF or DKIM may have passed, but not for a domain aligned with your From: address.

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: [192.0.2.10].

The sending IP is not listed in your SPF record, and the record ends in -all, which tells receivers to fail anything not listed.

You may also see 421 4.7.26, a temporary version where Gmail rate limits unauthenticated mail instead of refusing it, and 451 4.7.26, where a DNS error stopped Gmail from checking your DMARC policy. Treat both as early warnings of the same problem.

What Gmail checks

Since February 2024, Google's sender guidelines have set two levels of requirements. Bulk senders are those that send close to 5,000 or more messages a day to personal Gmail accounts, counted across your domain and its subdomains. Once you reach that, Google treats you as a bulk sender permanently.

Requirement	All senders	Over 5,000 a day
SPF or DKIM	Yes, at least one	Both
DMARC record	No	Yes, `p=none` is enough
From: domain aligned with SPF or DKIM domain	No	Yes
Valid forward and reverse DNS for sending IPs	Yes	Yes
TLS for sending	Yes	Yes
One-click unsubscribe on marketing mail	No	Yes

Yahoo enforces the same shape of rules, also from February 2024. Outlook began refusing non-compliant mail from senders of more than 5,000 messages a day to Outlook.com, Hotmail.com and Live.com addresses on 5 May 2025, with its own code, 550 5.7.515. Fixing authentication once fixes all three.

How to fix it, step by step

Find out what sent the message. Note the IP in the bounce and which service it belongs to: your email platform, your CRM, your help desk, your own server.
Check SPF includes that service. Look up your record and confirm the service's include is there, and that there is only one SPF record on the domain.
```
$ dig TXT example.com +short
"v=spf1 include:_spf.example.net -all"
```
Turn on DKIM signing with your own domain. In the sending service's settings, set up DKIM for example.com and publish the record it gives you. Check the key is live:
```
$ dig TXT s1._domainkey.example.com +short
"v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
```
Publish DMARC. If you have none, start with p=none and a reporting address, so you see results without blocking anything:
```
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
```
Check alignment. Send a test to a Gmail address, open it, choose Show original, and find the Authentication-Results header. You want dmarc=pass alongside spf=pass or dkim=pass. If SPF and DKIM pass but DMARC does not, read SPF and DKIM pass but DMARC fails.
Resend. Once a test passes, resend the bounced messages. DNS changes can take a while to reach every resolver, so if the first retry bounces, wait and try again.

Common causes

A new sending service nobody added. Someone connected a new tool that sends as your domain, and its servers are not in your SPF record and it signs with no DKIM, or with its own.
DKIM signed with the provider's domain. The message passes DKIM for d=example.net, which does not match a From: of example.com, so it does not count toward DMARC.
Forwarding. A message forwarded to Gmail arrives from the forwarder's IP, so SPF fails. If the message was not changed, a DKIM signature on your domain still passes. Without one, a forwarded message can fail everything.
Two SPF records. A domain may have only one. With two, SPF returns an error instead of a pass for every message.
Too many includes. SPF allows ten DNS lookups. A record with many includes can go past that limit, and then SPF returns an error instead of a pass.

To see which of these applies to you, run your domain through the free domain checker. It checks SPF, DKIM, DMARC and MX plus five blocklists, with no signup, and for a missing or broken SPF or DMARC record it shows the record to publish. If you send through Email Digit, we manage authentication for you: four DNS records published once, then you rotate keys in one click and step up DMARC when your reports say it is safe, without editing DNS again. That gets your authentication right. It does not guarantee the inbox, which also depends on what you send and who wants it.