If Gmail bounced your message with 550-5.7.26, it rejected the email because it could not confirm you are authorized to send from your domain. The full text reads "This message does not have authentication information or fails to pass authentication checks." In plain terms, the message failed both SPF and DKIM in a way that aligns with your From address, so Gmail treated it as an unauthenticated sender and blocked it before delivery.
This is a hard rejection, not a spam-folder placement. The message never reaches the recipient, and the sender gets the bounce. The good news is that 5.7.26 almost always traces to one of three fixable causes, and you can identify which one in a couple of minutes.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
What 550-5.7.26 actually means
Gmail returns 5.7.26 when a message arrives with no passing, aligned authentication. Since February 2024, Gmail enforces sender requirements that were previously guidance. Every sender needs SPF or DKIM to pass, and bulk senders (roughly 5,000 or more messages per day to Gmail) need both SPF and DKIM plus a valid DMARC record.
The word that matters is "aligned." Gmail does not just want SPF or DKIM to pass on any domain. It wants at least one of them to pass on a domain that matches the visible From address. A message can show spf=pass in the headers and still get a 5.7.26 rejection if that pass belongs to your email provider's bounce domain instead of your own From domain. This is the single most common reason people are confused by the bounce: their provider "passes SPF," yet Gmail still refuses the mail.
Here is the logic Gmail applies:
- Does SPF pass AND does the SPF domain align with the From domain? If yes, authenticated.
- Does DKIM pass AND does the
d=domain align with the From domain? If yes, authenticated. - If neither aligned check passes, return
550-5.7.26.
Root cause 1: neither SPF nor DKIM passes
The first thing to rule out is a plain authentication failure. If SPF is broken and DKIM is not signing, there is nothing for Gmail to accept.
SPF breaks most often because the sending IP is not listed in your record, or because the record has too many DNS lookups and returns a PermError. A correct SPF record for a domain sending through Google Workspace looks like this:
v=spf1 include:_spf.google.com ~all
If you send through multiple services, each one needs its include, and the whole record must resolve within the ten-lookup limit. When you exceed that, SPF returns PermError and Gmail treats it as a fail. See fix SPF too many DNS lookups if your record has grown past the limit.
DKIM fails when the selector is not published, the key was rotated without updating DNS, or the signature never gets added because DKIM was never switched on in the sending platform. A DKIM record is a TXT (or CNAME) record at a selector host such as google._domainkey.yourdomain.com. If your provider says DKIM is enabled but Gmail shows dkim=none, the signature is not being applied to outbound mail.
Confirm both by reading the message headers. Open the bounced or a test message, view the original, and look at the Authentication-Results line. Our guide on how to read the Authentication-Results header walks through exactly what spf=, dkim= and dmarc= mean in that block.
Root cause 2: authentication passes but does not align
This is the case that trips up senders who "already have SPF." Alignment means the domain that authenticated must match the domain in your From address.
SPF authenticates the Return-Path (the envelope sender), which for many providers is a bounce subdomain the provider owns, like bounces.provider.net. If your From address is you@yourdomain.com but SPF passed for provider.net, SPF is not aligned. DMARC and Gmail's requirement both need alignment, so an unaligned SPF pass counts as a fail for the purpose of 5.7.26.
DKIM alignment works the same way. The signing domain in the DKIM header (d=) must match your From domain. If your platform signs with d=provider.net instead of d=yourdomain.com, DKIM passes but does not align.
The fix is to authenticate on your own domain. For SPF, use a custom Return-Path or bounce domain on your own domain where the provider supports it. For DKIM, publish the provider's signing key at a selector under your domain and enable domain-level signing, so the d= value is your domain. Most platforms call this "domain authentication" or "verified sending domain." Our walkthrough on how to fix DKIM alignment covers the exact records, and relaxed vs strict alignment explains why a subdomain can still align under the default relaxed mode.
Root cause 3: no DMARC record
If you send in volume to Gmail, a missing DMARC record on its own can trigger the rejection, even when SPF and DKIM look fine. Gmail's bulk sender rules require a DMARC record to exist, at minimum a policy of none.
The starting record is simple and safe:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Publish it as a TXT record at _dmarc.yourdomain.com. A policy of none satisfies the requirement to have DMARC without changing how any mail is handled, so it is the correct first step. You can tighten to quarantine and then reject later once your reports confirm all legitimate mail is aligned. If you have no record at all, follow fix no DMARC record to add one correctly.
Do not confuse 5.7.26 with 550-5.7.1. The 5.7.1 code means your message was rejected because it failed your own published DMARC policy of quarantine or reject. If you are seeing that instead, read 550-5.7.1 email rejected per DMARC policy.
Copy-paste diagnostic checklist
Run these checks in order. The first "no" is your root cause.
- Does an SPF record exist at your root domain and include every service that sends for you?
- Does SPF resolve within ten DNS lookups (no PermError)?
- Is DKIM enabled in your sending platform, with a selector published in DNS?
- In a test message to a Gmail account, does the Authentication-Results header show
spf=passORdkim=pass? - Does the passing mechanism align with your From domain? SPF Return-Path domain or DKIM
d=must matchyourdomain.com. - Does a DMARC record exist at
_dmarc.yourdomain.com?
If you would rather not read raw headers, run your domain through the free checker above. It shows SPF, DKIM, DMARC and alignment side by side, so you can see at a glance which of the three causes is failing. For the full list of what Gmail and Yahoo now demand, see Google and Yahoo sender requirements.
Frequently asked questions
Does 5.7.26 mean my domain is blacklisted?
No. 5.7.26 is an authentication failure, not a reputation block. Gmail could not confirm you are authorized to send from your From domain. Fix SPF, DKIM and alignment and the rejection stops, regardless of blocklist status.
Why do I get 5.7.26 when my provider says SPF passes?
Because SPF is passing for your provider's bounce domain, not your From domain. That is an alignment failure. Set up a custom Return-Path on your own domain, or rely on DKIM signed with d=yourdomain.com, so the passing check aligns with the address recipients see.
How long after fixing DNS will the bounces stop?
New records take effect once DNS caches expire, usually within the TTL you set, often 1 to 24 hours. Send a fresh test message to a Gmail account after the records propagate and confirm the Authentication-Results header shows an aligned pass before resuming your campaign.
Do I need DMARC if SPF and DKIM already pass?
For low-volume senders, an aligned SPF or DKIM pass is often enough to clear 5.7.26. If you send 5,000 or more messages a day to Gmail, a DMARC record is mandatory. Publishing p=none meets the requirement without changing mail handling, so add it either way.