Gmail blocks email for authentication when the message it receives does not pass SPF or DKIM at delivery time. A DNS record that looks correct later does not prove that Gmail resolved it, used the same domain you checked, or saw a message that was actually signed. The rejection is about the delivered message, the sending path, and live DNS resolution, rather than only the existence of TXT records.
The common 550-5.7.26 error means Gmail evaluated the message as unauthenticated. Google's sender requirements say all senders need SPF or DKIM, and senders above 5,000 messages per day to personal Gmail accounts need SPF, DKIM, and DMARC. Gmail also expects valid forward and reverse DNS, TLS, and low spam complaint rates.
I treat this as an evidence problem. Start with the full bounce, the exact sender domain, the envelope sender, the DKIM selector, and the sending IP. Suped's DMARC monitoring helps by collecting authentication results over time, separating verified senders from unverified ones, and pointing to the specific source that needs work.
The short answer
Correct SPF and DKIM DNS records are necessary, but they are not enough. Gmail must successfully retrieve the records and apply them to the exact message that arrived. If SPF and DKIM both fail, Gmail has no authenticated identity to trust, so it can reject the message before inbox placement decisions even matter.
- Wrong domain: SPF checks the return-path domain, which is not always the visible From domain.
- Wrong IP: The provider can send through an IP range that your SPF record does not include.
- Missing signature: The DKIM key exists in DNS, but the message was not signed with that selector.
- Broken signature: A gateway, footer, or tracking layer changed signed headers or body content after signing.
- DNS failure: Gmail could not resolve the TXT record during the SMTP transaction.
- SPF limit: Your SPF chain exceeds the 10 DNS lookup limit or returns a temporary DNS error.
Typical Gmail 5.7.26 rejectiontext
550-5.7.26 Your email has been blocked because the sender is 550-5.7.26 unauthenticated. Gmail requires all senders to 550-5.7.26 authenticate with either SPF or DKIM. 550-5.7.26 Authentication results: 550-5.7.26 DKIM = did not pass 550-5.7.26 SPF [example.com] with ip: [203.0.113.10] = did not pass
Do not debug from screenshots alone
A partial bounce usually hides the fields that matter. Keep the unedited SMTP response, the sending IP, the return-path domain, the DKIM selector, and the message headers from a fresh test. Without those fields, the investigation becomes guessing.
What Gmail checks
When a message reaches Gmail, Gmail does not ask whether your domain has any SPF or DKIM record somewhere in DNS. It asks narrower questions: which domain is in the SMTP envelope, which IP connected to Gmail, which DKIM selector signed the message, whether the public key can be fetched, and whether the resulting authentication domain matches the identity Gmail is evaluating.
|
|
|
|---|---|---|
SPF | Return path | The connecting IP is absent or DNS lookup fails. |
DKIM | Signature | The key is missing, wrong, or the signature changed. |
DMARC | From domain | Neither SPF nor DKIM passes with the From domain. |
PTR | Sending IP | Forward and reverse DNS do not match correctly. |
TLS | SMTP session | The sending server does not use a secure connection. |
Gmail checks the delivered message, not only the DNS record you inspected.
The Gmail authentication result in the header is the ground truth for a delivered test. For rejected mail, the bounce response is the next best source. If you need a header-level process, the Gmail SPF/DKIM guide gives a step-by-step way to read Authentication-Results.
Flowchart showing Gmail reading the SMTP envelope, SPF DNS, DKIM signature, and DKIM DNS before accepting or rejecting mail.
Why SPF can fail when DNS looks right
The biggest SPF misunderstanding is checking the visible From address instead of the envelope sender. SPF authenticates the domain used in the SMTP return path. Many sending platforms use a bounce domain that differs from the From domain, so a correct SPF record on the visible domain does not help if Gmail evaluates a different domain.
What admins often check
- Visible domain: They inspect the domain shown in the From header.
- Current DNS: They check the TXT record after the rejection happened.
- One IP: They confirm one documented IP is present.
What Gmail actually checks
- Return path: Gmail checks the SPF domain in the SMTP envelope.
- Live lookup: Gmail resolves DNS during the SMTP transaction.
- Exact IP: The connecting IP must be authorized by SPF.
SPF also fails when a record is syntactically valid but operationally broken. Multiple SPF records at the same hostname, too many DNS lookups, a missing include, or a temporary DNS timeout can all produce an SPF fail or temperror. A fast domain health check is useful before you change anything because it checks SPF, DKIM, and DMARC together.
SPF record with one provider includetext
example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.sender.example -all"
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The key is checking the same sending path that Gmail rejected. If a provider rotates mail through a different pool, the IP in the bounce can be the missing piece. If the provider changed an include target or had DNS trouble, your record can look correct while Gmail's live SPF check still fails.
Why DKIM can fail when the key exists
DKIM is not a DNS-only check. The message needs a DKIM-Signature header, the signature must name the expected domain and selector, Gmail must fetch the selector's public key, and the cryptographic hash must still match the message when Gmail receives it.
- No signing: The DNS key exists, but the sending stream is not configured to sign.
- Wrong selector: The message uses selector A while DNS only has selector B.
- Wrong domain: The signature uses a provider domain instead of the sender's domain.
- Modified message: A footer, link rewrite, security gateway, or MIME change breaks the signed content.
- Weak key: A short or malformed key can fail receiver policy even when the hostname exists.
DKIM header fields to inspecttext
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail1; h=from:to:subject:date:mime-version; bh=base64-body-hash; b=base64-signature;
Treat DKIM as message-specific
A passing DKIM test from one tool does not prove every stream is signed. Transactional, marketing, billing, and support mail often use separate systems. Each stream needs its own checked DKIM signature and selector.
After fixing either DKIM or SPF, validate the published DMARC record with a DMARC checker. DMARC is where the visible From domain is compared with the passing authentication method, so it catches cases where SPF passes for a bounce domain but not for the brand domain.
DNS timing and resolver failures
The most confusing case is a send that fails at 09:10 and passes at 09:25 with no DNS edit. That pattern usually points to DNS resolution, provider routing, or a temporary sending platform issue. Gmail's rejection was still real. The TXT record simply became reachable, the provider moved back to an expected IP range, or a resolver error cleared.
- Authoritative DNS: Nameservers can respond slowly, inconsistently, or with stale data.
- Recent change: A new SPF include or DKIM selector can take time to reach all resolvers.
- Provider routing: Mail can leave through a temporary IP range during maintenance or incidents.
- DNSSEC state: Broken DNSSEC creates hard failures, while no DNSSEC avoids that failure mode.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's product is useful here because it keeps the issue tied to the source that produced it. Instead of staring at a static DNS record, you can see which sender is failing, whether the problem repeats, and the fix steps needed for that sender.
A clean retest matters
Send a new message after the failure instead of reusing an old result. A fresh test gives you the current sending IP, current DKIM selector, and current DNS behavior. That is the fastest way to separate a fixed transient issue from a persistent configuration problem.
A practical troubleshooting order
I use this order because it keeps the investigation tied to evidence. It also prevents the worst failure mode: making several DNS changes after one bounce and losing the ability to tell which change mattered.
- Capture bounce: Save the full SMTP response, not a shortened screenshot.
- Send sample: Send one new message through the same platform and stream.
- Read headers: Inspect Authentication-Results if the message lands anywhere.
- Check envelope: Confirm the return-path domain that SPF used.
- Query DNS: Check SPF, DKIM, DMARC, and PTR records from outside your network.
- Ask provider: Confirm whether the sending IP range had an incident or routing change.
- Retest slowly: Send a small number of messages before resuming normal volume.
DNS queries to run during investigationbash
dig TXT example.com dig TXT mail1._domainkey.example.com dig TXT _dmarc.example.com dig -x 203.0.113.10
If the DNS answers differ by resolver, wait for TTL expiry and test again. If the sending IP is missing from SPF, update the provider include or authorized range. If DKIM is missing, enable signing for that stream, then confirm the selector in the message matches the selector in DNS.
Where DMARC fits
DMARC does not replace SPF or DKIM. It tells receivers how to evaluate the visible From domain when SPF or DKIM passes. That matters because many SPF passes are technically true but belong to a provider's bounce domain. Gmail's higher-volume requirements expect DMARC, and a DMARC report gives you a map of all the systems claiming to send as your domain.
This is where Suped's product is the strongest practical choice for most teams. It brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, MTA-STS, alerts, blocklist monitoring, and deliverability signals into one workflow. You still get the concrete sender-level evidence, but you do not have to stitch it together by hand across DNS, bounce logs, and aggregate XML.
Manual DNS management
- Slow changes: Every policy edit needs direct DNS access.
- Limited history: One test does not show repeated failures by source.
- Hidden risk: Old senders stay unnoticed until Gmail blocks them.
Suped workflow
- Source view: Verified and unverified senders are separated.
- Fix steps: Issues include tailored actions and verification.
- Policy staging: Hosted controls help move DMARC policy safely.
How urgently to act on Gmail authentication evidence
Use the bounce text and repeat rate to decide whether to change DNS now or monitor.
One old bounce
Monitor
Retest before changing records.
Repeat 5.7.26
Same day
Investigate SPF, DKIM, and DNS resolution for the exact source.
All Gmail mail blocked
Immediate
Pause the affected stream and fix the failing authentication path.
When DNS is correct and Gmail still blocks
If Gmail says DKIM did not pass and SPF did not pass, keep the focus on authentication first. Reputation, content, spam complaints, blocklist or blacklist status, and sending volume matter, but they usually produce different symptoms. A 5.7.26 rejection is Gmail telling you that it could not authenticate the sender with SPF or DKIM.
Once authentication is passing, Gmail can still route mail to spam because of reputation, complaints, list quality, message formatting, sudden volume, or confusing sender identity. That is a separate deliverability investigation. The Gmail spam placement guide covers that case in more detail.
Do not mix error classes
A hard 550-5.7.26 authentication block, a temporary rate limit, and spam-folder placement need different fixes. Solving the wrong class wastes time and can create new DNS errors.
Views from the trenches
Best practices
Keep the full bounce text, headers, sending IP, and From domain together for each case.
Retest through the same sending stream before changing SPF, DKIM, or DMARC records.
Record provider incidents beside authentication failures so short outages do not look permanent.
Common pitfalls
Checking the visible From domain only misses SPF failures on the actual return-path domain.
Redacting the domain, IP, or selector removes the details needed to explain the Gmail error.
Changing several DNS records after one bounce makes the real fix hard to identify later.
Expert tips
Repeat the same test after TTL expiry before changing several DNS records at once.
Ask the sending provider about recent IP range issues when failures start suddenly.
Compare a failed Gmail result with a fresh passing result to isolate the changed field.
Marketer from Email Geeks says a redacted bounce hides the domain, IP, and SPF domain, so diagnosis becomes guesswork.
2025-04-03 - Email Geeks
Expert from Email Geeks says correct-looking TXT records still fail when Gmail cannot resolve them during the SMTP check.
2025-04-03 - Email Geeks
The fix starts with the message Gmail saw
Gmail blocks these messages because SPF and DKIM failed for the actual delivery attempt. The DNS records can look correct later, but Gmail only sees what resolves during its check and what the message carries when it arrives. That is why the full bounce, sending IP, return path, DKIM selector, and fresh test matter more than a generic DNS screenshot.
The fastest fix is to identify the failing path, then change only that path: authorize the real sending IP, repair the SPF include, enable DKIM signing for the stream, publish the correct selector, or wait out a confirmed transient DNS failure. Suped's product helps teams do this continuously by turning DMARC reports, authentication failures, and sender inventory into source-level actions.
