Gmail 550-5.7.26: what “unauthenticated email” means, and the records that fix it
Your message came back. Somewhere in the bounce is the code 550-5.7.26, and Gmail did not put it in the spam folder — it refused to accept the message at all. This page explains what Gmail checked, why it is almost always a DNS problem rather than a mail-server problem, and the exact records to publish. The whole fix is here, free.
Read your bounce carefully — the sentence after the number tells you which one you have, and they are fixed differently.
- “…is not accepted due to domain’s DMARC policy” — your domain publishes an enforcing DMARC policy, and this message satisfied neither SPF nor DKIM in a way that lines up with the From address. Your own policy is what refused it.
- “Gmail requires all senders to authenticate with either SPF or DKIM” — nothing authenticated the message at all. This is the rule Google applied to every sender from 2024 onward.
Free, no signup: what a stranger can already read about your domain
The bounce tells you Gmail refused the message. This tells you what Gmail READ: the SPF, DKIM and DMARC records your domain publishes right now, including an SPF record over the lookup limit and a DKIM key that is revoked or too short.
Type a domain and get four checks in about ten seconds: whether anyone can send email in your name (SPF, DKIM and DMARC), how long your HTTPS certificate has left, when your domain registration expires, and whether the site answers over HTTPS rather than plain http. No email address, no account, nothing installed. It runs the same code our paid monthly report runs.
Open the free check on its own page → · We measured 604 domains: 72-83% had at least one finding
What Gmail is actually checking
Three records, in this order, and the third one is where most people come unstuck.
- SPF — a TXT record on your domain listing the servers allowed to send for it. Gmail compares the sending server’s IP against that list.
- DKIM — a cryptographic signature added by the sending system,
verified against a public key you publish in DNS at
selector._domainkey.yourdomain.com. - Alignment — the part nobody is told about. It is not enough
for SPF or DKIM to pass. The domain they passed for must match the
domain in the
From:address your recipient sees. A message can pass SPF perfectly for your email provider’s own domain and still fail DMARC, because the passing domain was not yours.
That is why this error so often appears on the day nothing changed on your mail server. A newsletter tool, an invoicing system, a CRM or a booking form starts sending “from” you, and it authenticates as itself.
Fix 1 — authorise the system that is actually sending
Find the service that produced the bounce. Every one of them publishes a page telling
you two things: an SPF include, and one or more DKIM records to add. You need
both. Add the include to your single existing SPF record — never
publish a second one, which is an error in itself:
Type TXT
Name @
Value v=spf1 include:_spf.google.com include:sendgrid.net ~allThen publish the DKIM key exactly as the provider gives it, at the selector name they
specify. The selector is arbitrary and provider-chosen — google,
selector1, k1, default and s1 are all
common — so it must be copied, not guessed:
Type TXT
Name selector1._domainkey
Value v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…Fix 2 — if the bounce named your DMARC policy
Then the record refusing your mail is your own, and you have a choice: authorise the sender properly, or relax the policy until you have. Relaxing is the wrong instinct if the sender is legitimate, because it also re-opens your domain to forgery. Authorise it.
Prefer DKIM over SPF when you can only fix one. SPF alignment breaks the moment a message is forwarded, because the forwarding server is not on your list. A DKIM signature travels with the message and survives that, which is why a domain that signs with DKIM is far more robust under an enforcing DMARC policy than one leaning on SPF alone.
Fix 3 — the failure that leaves no trace in a DNS console
Two ways a record that looks right is not:
- SPF over the ten-lookup limit. An SPF record may cost a receiver at
most ten DNS lookups, counting everything inside every
include. Over that, the result ispermerrorand receivers may act as though you published nothing. The record still reads correctly on screen. - A revoked or undersized DKIM key. A key published with an empty
p=value is a revoked key: the record exists, and every signature made with it fails. An RSA key shorter than 1024 bits is below the floor RFC 8301 sets, and receivers are permitted to treat mail signed with it as unsigned.
Every DKIM key found for yourcompany.com is published with an empty p= value, which is how the standard says a key has been withdrawn. Mail signed with one of them fails its signature check, and if your DMARC policy is enforcing the message can be rejected outright rather than sent to spam.
The sentence above is the wording our own free checker returns for this finding, reproduced here from the running code rather than retyped.
What we measured
On 2026-09-02 we asked the same 83 independent small-business domains behind our published study what they publish for DKIM, using the 25 selector names a public prober can guess. 39 of them answered with a key. 44 did not answer at any name we tried. One published a live key of 768 bits — below the standard’s floor, so mail signed with it can be discarded as unsigned by a receiver that enforces the rule.
That second number is not what it looks like, and we will not let it be read as though it were. DKIM selectors are arbitrary. There is no DNS query that returns “this domain publishes no DKIM”, and no wildcard to ask. A prober can only ask about names it already guessed, so “44 did not answer” is a fact about our list of 25 names and not about their DNS. Any of them may be signing perfectly under a selector nobody outside their own provider would think to try.
Our own free check reports it the same way for the same reason: it will tell you a key exists, because that is something it can prove, and it will never tell you that you have no DKIM, because that is something no external tool can prove.
For context on the other two records, the same 83 domains produced 13 with no SPF record at all (15.7%), and 80.7% had no enforcing DMARC policy — which is why the second variant of this bounce, the one about authenticating with either SPF or DKIM, is the more common of the two among small businesses.
Check what you actually publish
Before changing anything, read the three records as a receiver sees them — the console you edit them in is not the same thing as what resolves publicly. Our free check reads all three for any domain and reports what it finds, including an SPF record over the lookup limit and a DKIM key that is revoked or too short. It takes a few seconds and asks for nothing.
What it cannot do, said plainly: it reads your published DNS. It never sees the message that bounced, so it cannot tell you which sending system failed alignment — only the bounce itself and your provider’s logs can. Use it to confirm the records are right, then re-send.
Fix it yourself. Then find out when it breaks again.
Everything on this page is the whole fix, free, with nothing held back. What a DNS change cannot do is tell you when somebody edits it back, when a certificate runs out, or when a registration lapses — all three carry dates and none of them announce themselves. A3E’s perimeter monitor re-runs all four checks every month and emails you only when something moves: CA$99/month per site, cancel any time. A single report with no monitoring is CA$29.
Check a domain free See the monitorQuestions
What does 550-5.7.26 mean?
Gmail refused to accept your message because nothing authenticated it as coming from the domain in the From address. Either your own DMARC policy asked for that refusal, or the message satisfied neither SPF nor DKIM and Gmail applied its own requirement that all senders authenticate.
Why did this start happening when nothing changed on my mail server?
Usually because a different system began sending as you: a newsletter tool, an invoicing system, a CRM or a booking form. It authenticates as itself, not as your domain, so the message arrives unauthenticated for the address your recipient sees.
Is SPF or DKIM more important for fixing this?
DKIM, if you can only do one. SPF alignment breaks whenever a message is forwarded, because the forwarding server is not on your list. A DKIM signature travels with the message and still verifies after a forward.
How do I find my DKIM selector?
You do not guess it, you copy it from whichever service sends your mail; the selector name is theirs to choose. There is no DNS query that lists the selectors a domain uses, which is also why no external checker can honestly tell you that you publish no DKIM at all.
Can I just remove my DMARC record to stop the rejections?
It would stop the first variant of this bounce and it is the wrong fix. It also removes the only instruction receivers have about forged mail in your name, and it will not help with the second variant, where Gmail is applying its own requirement rather than yours.
How long after fixing DNS can I retry?
As soon as the new record resolves publicly, which depends on the TTL of the record you replaced. Check what actually resolves rather than what your DNS console displays, then re-send; this bounce is not a block on your account and clears as soon as the message authenticates.
The other five in this set
No DMARC record found: what it means and the record to publish
DMARC record published but invalid: why receivers discard it
DMARC p=none: what it does, and how to move off it safely
No SPF record found: the record to publish, and why SPF alone is not enough
SPF permerror — too many DNS lookups, and how to get back under ten
The measurement behind every number on this page: 604 domains, method and limitations
Every figure on this page is generated from the stored raw measurement files behind our 604-domain study (522 agency-built sites measured 2026-08-20, 83 independent domains measured 2026-08-01), and the quoted finding wording is read out of the running checker at build time. An automated control re-asserts both against this live page on every operating cycle; if either changed and this page did not, it fails. Generated 2026-09-05T23:34:13Z.
← Back to all articles