Why are my authenticated emails to Gmail soft bouncing with a DKIM and SPF fail error?
Matthew Whittaker
Co-founder & CTO, Suped
Published 6 May 2025
Updated 4 Jun 2026
8 min read
Summarize with
If Gmail soft bounces a message with 550-5.7.26 and says DKIM checks did not pass and SPF did not pass, the direct answer is this: the specific message Gmail received did not authenticate. Your domain can have valid SPF and DKIM records and the message can still fail if that sending IP is not authorized, the envelope sender is different, the DKIM selector is missing, the DKIM signature breaks in transit, or Gmail cannot read the DNS answer reliably.
I do not treat this as a generic deliverability problem first. I treat it as a message-level authentication problem. The fastest path is to send the same kind of message to Suped's email tester, inspect the headers, compare the Gmail bounce IP with the authorized SPF senders, and verify the DKIM selector that appears in the failing message.
Direct answer
A Gmail DKIM and SPF fail bounce means Gmail found no passing authentication path for that message. At least one of SPF or DKIM needs to pass, and for DMARC alignment the passing identity must match the visible From domain or an allowed organizational domain.
- Message-specific: A valid domain record does not prove every sender, route, or template is using it correctly.
- Header-specific: SPF checks the envelope sender domain, not always the visible From address.
- DNS-specific: Missing, moved, slow, or malformed DNS records can make authentication fail at Gmail.
What Gmail is actually testing
Gmail is not asking whether your domain has any SPF or DKIM record in DNS. It is asking whether the message it received passed SPF or DKIM during that SMTP transaction. SPF checks whether the connecting IP is authorized by the envelope sender domain, often shown as Return-Path or 5321.From. DKIM checks whether a cryptographic signature in the message validates against a public key published at the selector and d= domain in the DKIM-Signature header.
An infographic showing the five message details Gmail checks for email authentication.
That distinction explains most confusing cases. A sender says, "SPF and DKIM are set up," but Gmail says both failed. Both statements can be true if the published records are correct for one mail stream and the failing message came through another route. Header review matters because the Authentication-Results line tells you what Gmail evaluated, not what the sender thought was configured.
Typical Gmail authentication bounce
550-5.7.26 This mail is unauthenticated, which poses a security risk 550-5.7.26 to the sender and Gmail users, and has been blocked. 550-5.7.26 The sender must authenticate with at least one of SPF or DKIM. 550-5.7.26 For this message, DKIM checks did not pass and SPF check 550-5.7.26 for example.com did not pass with ip: 203.0.113.10.
The bounce text usually includes the IP Gmail checked. That IP is one of the most useful clues. If it is not an expected outbound mail server, the issue is routing. If it is expected but missing from SPF, the issue is DNS authorization. If SPF is expected to fail because the envelope sender uses a third-party domain, DKIM must carry the authentication instead.
The causes I check first
I start with the causes that explain both SPF and DKIM failing at the same time. When both fail, the message usually did not contain a usable DKIM signature and did not come through an SPF-authorized IP for the envelope sender. That points to the sending path, DNS publication, or a recent migration.
- Wrong route: The message left through a server that is not included in the envelope sender domain's SPF record.
- Wrong domain: The visible From domain is authenticated, but the envelope sender domain is different and lacks SPF authorization.
- Missing selector: The message is signed, but the DKIM selector in the header has no matching public key in DNS.
- Broken signature: A footer, relay, scanner, or encoding change altered signed headers or body content after DKIM signing.
- DNS migration: SPF, DKIM, or DMARC TXT records were not copied to a new DNS host or were copied with syntax errors.
- Unstable DNS: Gmail cannot reliably retrieve the SPF or DKIM record because the DNS host times out or returns inconsistent answers.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A broad domain health check is useful when the bounce started after a DNS change, email platform change, or migration. It lets you check SPF, DKIM, and DMARC together before you spend time chasing content, engagement, or blocklist (blacklist) theories.
Do not stop at the DNS record
The DNS record can look correct and the live message can still fail. Always compare the failing message headers with the DNS records. DKIM is especially easy to misread because one selector can work while another selector is missing.
How to prove the failure in headers
The proof sits in the received message headers. If you only have the bounce, ask for a full copy of a similar sent message that reached any mailbox, then send a fresh test to Gmail or to a tester mailbox. You need the sending IP, the envelope sender, the DKIM selector, the DKIM d= domain, and the final Authentication-Results verdict.
Header clues to collect
Authentication-Results: mx.google.com; spf=fail smtp.mailfrom=bounces.example.com; dkim=fail header.d=example.com header.s=s1; dmarc=fail header.from=example.com Return-Path: <bounce-123@bounces.example.com> DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1;
What SPF needs
- Envelope domain: Use the Return-Path or SMTP mail-from domain, not the visible From address.
- Sending IP: Match the IP in the bounce to the SPF mechanism or included sender.
- Lookup count: Keep SPF within the DNS lookup limit so receivers can complete evaluation.
What DKIM needs
- Signature header: The message needs a DKIM-Signature header added before final delivery.
- Public key: The selector and domain must resolve to the exact DKIM public key.
- Unchanged body: Content covered by the signature must not change after signing.
When the header shows SPF fail, validate the exact domain with the SPF checker. When the header shows DKIM fail or DKIM none, validate the selector with the DKIM checker. Do not check a selector you expected to use. Check the selector that appears in the live message.
Example DNS records to comparedns
bounces.example.com. TXT "v=spf1 include:send.example.net -all" s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjAN..." _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Fix path for Gmail 550 5.7.26
The fix is usually simple once the failing identity is known. Do not change every SPF and DKIM record at once. Change the record tied to the failing path, retest, and keep the evidence. That reduces the chance of fixing one stream and breaking another.
A flowchart showing how to diagnose and fix Gmail 550 5.7.26 authentication bounces.
- Capture evidence: Save the Gmail bounce, the IP in the bounce, and a full header sample from the same sending system.
- Confirm SPF: Check the envelope sender domain and authorize the real outbound IP or included sender.
- Confirm DKIM: Find the DKIM selector in the message and publish or correct the matching public key.
- Check modification: Remove footer injection, relay rewriting, or gateway changes that happen after signing.
- Retest Gmail: Send a new message, then confirm at least one of SPF or DKIM passes in Gmail headers.
- Track bounces: If delivery still fails after authentication passes, move to reputation and policy checks.
If the bounce is part of a wider pattern, compare it against a broader soft bounce guide. Gmail authentication bounces are specific, but they can appear beside temporary DNS failures, connection timeouts, rate limits, or sender reputation problems.
Escalate only after testing
If Gmail says neither SPF nor DKIM passed, fix your evidence first. Escalation only makes sense after you can show fresh samples where SPF or DKIM passes and Gmail still blocks the message for authentication.
When the sender really is authenticated
Sometimes the sender's control panel says authentication is complete, but the actual Gmail-bound message still fails. That usually means the control panel verified one domain, one selector, or one mail stream. Gmail evaluates the message in front of it. Those are different checks.
|
|
|
|---|---|---|
SPF fail | IP not authorized | Update SPF |
DKIM none | No signature | Enable signing |
DKIM fail | Bad key or change | Check selector |
DMARC fail | No alignment | Fix domains |
DNS temp | Lookup issue | Check host |
How to read common authentication signals
The most common mismatch is SPF passing in a vendor's setup screen but failing at Gmail because the visible From domain and the envelope sender are not the same domain. That is not always wrong. It does mean DKIM becomes the cleaner path for DMARC alignment because the DKIM d= domain can match the visible From domain even when Return-Path uses a bounce subdomain.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
This is where Suped is the practical DMARC platform choice for most teams. Suped connects DMARC reports, SPF, DKIM, sender sources, issue detection, and fix steps in one place. Instead of looking at one DNS record at a time, you can see which source failed, what identity it used, and what needs to change.
How Suped helps this workflow
- Issue detection: Suped highlights failed sources and gives concrete steps to fix them.
- Real-time alerts: Teams can react when authentication failures spike instead of waiting for users to report bounces.
- Hosted SPF: Sender changes can be managed without repeated DNS edits, and SPF flattening helps stay under lookup limits.
- Unified view: DMARC monitoring, SPF, DKIM, blocklist monitoring, and deliverability checks live together.
What to check before changing DNS
Before editing DNS, verify the sending system. I have seen teams publish the right records and still fail because an application used a backup SMTP relay, an old integration, or a shared server that was never authorized. DNS changes only help when they match the path Gmail actually sees.
Before DNS edits
- Find source: Confirm which app, server, or vendor sent the bounced message.
- Read IP: Use the IP in the bounce instead of a guessed sender range.
- Check selector: Use the selector in the live message, not a default selector name.
After DNS edits
- Wait TTL: Let DNS propagation complete before judging a new result.
- Retest path: Send through the same application and route that produced the bounce.
- Watch reports: Confirm DMARC aggregate data shows the failing source recovering.
If SPF is failing because of a forwarding path, adding the forwarder's IP to your SPF record is usually the wrong fix. SPF is tied to the envelope sender. For forwarded mail, DKIM should survive forwarding unless something modifies signed content. If it does not survive, fix the forwarding or signing behavior rather than adding random relay IPs to SPF.
Views from the trenches
Best practices
Keep one fresh header sample for each mail stream before changing DNS or sender settings.
Compare Gmail's bounce IP with the exact envelope sender domain before editing SPF.
Use DMARC reports to confirm the same source recovers after SPF or DKIM changes.
Common pitfalls
Assuming a setup screen proves the live Gmail-bound message used the same auth path.
Checking a default DKIM selector instead of the selector shown in the failed message.
Copying DNS during a migration and leaving TXT records missing, malformed, or stale.
Expert tips
Treat DKIM pass as the cleaner fix when SPF uses third-party bounce domains often.
If both SPF and DKIM fail, inspect routing before blaming Gmail or reputation first.
Do not escalate to Gmail until fresh samples show authentication passes correctly.
Marketer from Email Geeks says the bounce should be trusted as a sign that Gmail did not see a passing SPF or DKIM result for that message.
2023-05-17 - Email Geeks
Marketer from Email Geeks says the From domain is the first detail to confirm because the error points to an unauthenticated sending identity.
2023-05-17 - Email Geeks
The practical answer
Your authenticated emails are soft bouncing at Gmail because the specific message Gmail received is not authenticated. The usual reason is not that Gmail ignored a good setup. The usual reason is that SPF or DKIM is correct somewhere, but not on the exact sender, envelope domain, selector, route, or DNS host that handled the bounced message.
Start with the bounce IP, the Return-Path domain, the DKIM selector, and the Authentication-Results header. Fix the failing path only, then send a fresh Gmail test. If you manage several senders or clients, Suped gives you the more reliable operating model: monitor every source, detect authentication breaks quickly, and turn DMARC data into specific SPF and DKIM fixes.
