Why are my authenticated emails to Gmail soft bouncing with a DKIM and SPF fail error?
Published 6 May 2025
Updated 20 Oct 2026
15 min read
Summarize with
Updated on 25 Oct 2026: We clarified Gmail's authentication errors, corrected the SPF and DMARC checks, and added practical steps for verifying rejected messages.
If Gmail rejects a message with 550-5.7.26 and says DKIM checks did not pass and SPF did not pass, the specific message Gmail received did not authenticate. A 550 response is a permanent rejection, even if your sending platform labels it a soft bounce. Your domain can have valid SPF and DKIM records and the message can still fail if the actual envelope domain's SPF record does not authorize the sending IP, the DKIM selector is missing, the signature breaks in transit, or Gmail cannot retrieve the DNS records.
Treat this as a message-level authentication problem before investigating general deliverability. Send the same message type through the same route 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 rejection explicitly reporting both DKIM and SPF as not passing means neither check authenticated that message. Google's sender guidelines require SPF or DKIM for mail to personal Gmail accounts. Bulk senders need both, plus DMARC with at least p=none and a passing SPF or DKIM domain that meets DMARC alignment with the visible From 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.
Google's bulk sender definition covers senders reaching close to 5,000 messages or more in 24 hours to personal Gmail accounts, counted across the same primary domain and its subdomains. Bulk sender status is permanent once assigned.
Why 550 5.7.26 is not a soft bounce
The first digit controls how the sender should handle the response. Gmail's 550 5.7.26 response is a permanent failure for that delivery attempt. A mail platform might group it under soft bounces for its own suppression logic, but blindly retrying the same unauthenticated message will not fix it.
SPF softfail is an authentication result, usually produced by ~all. It does not mean a soft bounce: the SMTP response determines whether delivery is deferred or rejected. Changing -all to ~all does not produce SPF pass. These SPF results are defined in RFC 7208.
|
|
|
|---|---|---|
550 5.7.26 | Permanent authentication rejection | Read the full error, fix authentication or DMARC alignment, then send a new message |
421 4.7.26 | Temporary rate limit for unauthenticated mail | Fix authentication and follow the retry schedule |
451 4.7.26 | DMARC-related deferral because DNS failures prevent authentication | Check DNS health and retry later |
How Gmail authentication status classes affect retries
Do not retry unchanged mail
For a 550 5.7.26 response, correct the sending route, SPF authorization, or DKIM signing first. Then create a fresh delivery attempt. Repeated delivery of the unchanged message can increase bounce volume without producing new evidence.
Read the full Gmail 5.7.26 error
The enhanced status code alone does not identify the failed check. Google's SMTP error reference lists several 550 5.7.26 responses. Use the accompanying text to choose the fix.
|
|
|
|---|---|---|
DKIM and SPF did not pass | Neither check authenticated the received message | Check the actual sending IP, envelope SPF record, and DKIM signature |
SPF hard fail policy (-all) | The envelope domain explicitly excludes the connecting IP | Correct the authorized sending route or SPF record, even if a separate DKIM test passes |
Domain's DMARC policy | No passing authentication result meets DMARC alignment | Check From against the passing SPF or DKIM domain and the DMARC comparison mode |
Different Gmail 550 5.7.26 messages require different fixes
Publishing p=none does not make SPF or DKIM pass, and it does not override Gmail's authentication requirements. Fix the failing identity rather than weakening policy to hide the symptom.
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 RFC5321.MailFrom. 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.
Gmail authentication checks using the visible From, envelope sender, sending IP, DKIM selector, and DNS records.
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 rejection
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 rejection 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. A third-party envelope sender domain can pass SPF. If that domain does not meet DMARC alignment with the visible From domain, a passing custom DKIM signature can provide the required DMARC result.
The causes to check first
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.
- Invalid SPF: The envelope domain publishes multiple SPF records, has malformed syntax, or exceeds the limit of 10 DNS-querying SPF terms evaluated across the record and nested includes.
- Missing selector: The message is signed, but the DKIM selector in the header has no matching public key in DNS.
- Broken signature: A footer or relay changed signed content after signing. MIME re-encoding can also break the signature.
- 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 authoritative nameservers time out or return conflicting zone data.
?
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 rejection 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
Use the rejection and outbound SMTP logs for a message Gmail refused. It will not have a delivered Gmail copy containing Gmail-added headers. Collect the connecting IP and SMTP MAIL FROM domain, plus the DKIM d= domain and s= selector from the outbound message. A delivered test through the same route provides comparison evidence, but another receiver's pass does not prove Gmail saw the same result.
For a test that reaches Gmail, open the message in a browser and choose More next to Reply, then Show original. Read Gmail's own Authentication-Results entry, normally identified by mx.google.com, rather than an earlier result added by another system.
Illustrative authentication results and DKIM header excerpt
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 rejection to the SPF mechanism or included sender.
- One record: Publish one v=spf1 TXT record at the exact envelope domain. An SPF record at the root domain is not inherited by its subdomains.
- Lookup count: Keep evaluated DNS-querying SPF terms within 10, including nested includes. ip4 and ip6 mechanisms do not consume this limit.
What DKIM needs
- Signature header: Enable signing in the sending system; publishing a public key alone does not add a DKIM-Signature header.
- Public key: Look up s._domainkey.d using the signature's s= and d= values, following any CNAME. The public key must match the private signing key. Gmail requires RSA keys of at least 1024 bits and recommends 2048 bits when supported.
- Unchanged body: Content covered by the signature must not change after signing.
When the header shows SPF none, fail, softfail, neutral, temperror, or permerror, validate the exact envelope domain with the SPF checker. For DKIM fail, temperror, or permerror, validate the signature's selector with the DKIM checker. If DKIM is none, first confirm that signing is enabled; there is no selector to test when the signature is absent.
Illustrative DNS records, with a truncated DKIM keydns
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"
These records are examples, not values to publish. Use the sending system's actual include domain and complete public key. RFC 7208 defines the SPF lookup limit and permits multiple quoted strings within one TXT record; separate v=spf1 records at the same name are invalid.
How to fix 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 rejection, the IP in the response, and a full header sample from the same sending system.
- Confirm SPF: Check the envelope sender domain, keep one valid SPF record, and authorize the actual outbound IP or documented include. Check IPv6 as well as IPv4 when both are used.
- Confirm DKIM: Find the DKIM selector in the message, publish the matching public key, and enable signing. During key rotation, retain the old selector until messages using it have left the queues.
- Check modification: Prevent changes to signed content after signing, or move DKIM signing after the final content change.
- Retest Gmail: After cached DNS answers expire, send a new message through the same route and inspect Gmail's result.
- Track rejections: If delivery still fails, read the new error and verify DMARC alignment and bulk sender requirements before investigating reputation.
If the rejection is part of a wider pattern, compare it against a broader soft bounce guide. A 550 5.7.26 response is permanent. A 421 or 451 4.7.26 response is a temporary deferral; keep queued mail on the normal retry schedule while correcting the cause.
Escalate with the delivery evidence
If you cannot change a managed relay or DNS zone, contact the responsible provider with the full rejection and outbound logs. Include the timestamp with timezone, sending IP, envelope domain, and DKIM selector. For an unexplained Gmail rejection after corrections, include a fresh test through the same route.
Why SPF or DKIM pass can still fail DMARC
A sender's control panel can confirm that DNS records exist without proving a live message passes. A message can also pass SPF or DKIM for a domain unrelated to the visible From address and still fail DMARC. Check the actual identities in the message, not only the setup screen.
|
|
|
|---|---|---|
SPF fail, softfail, or neutral | No SPF pass for the connecting IP and envelope identity | Check the envelope domain and sending IP |
SPF none | No applicable SPF record or usable identity | Check the exact envelope domain and its TXT record |
SPF permerror | Invalid SPF record or lookup limit exceeded | Fix syntax, duplicate records, or lookup count |
SPF temperror | Temporary DNS lookup problem | Check DNS reliability and retry later |
DKIM none | No DKIM signature found | Enable signing |
DKIM fail | Bad key or message change | Check the selector and signed content |
DMARC fail | No passing SPF or DKIM identity meets DMARC alignment | Check the visible From domain and the aspf/adkim modes |
How to read common authentication signals
A different envelope sender domain does not itself cause SPF to fail. With relaxed DMARC alignment, bounces.example.com and example.com share an organizational domain, so a passing SPF result can satisfy DMARC. With aspf=s, the domains must match exactly. The corresponding adkim setting controls DKIM alignment. A passing DKIM d= domain that meets the required comparison can satisfy DMARC even when the envelope domain does not. See RFC 9989.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped is our DMARC reporting and email authentication platform. Use its aggregate reports to identify failing sending sources and inspect their SPF and DKIM results, then follow the relevant fix steps. Aggregate reports are delayed summaries, not individual SMTP bounce logs; use the rejection and outbound logs to diagnose the specific message.
How Suped helps this workflow
- Source review: Compare reported source IPs and authentication results with the route in the Gmail rejection.
- Recovery checks: After new reports arrive, check whether the same source and identities show passing results. A passing DMARC result alone does not prove inbox placement.
What to check before changing DNS
Before editing DNS, verify the sending system. Teams can 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 rejected message.
- Read IP: Use the IP in the rejection instead of a guessed sender range.
- Check selector: Use the selector in the live message, not a default selector name.
After DNS edits
- Wait for TTL: Verify the authoritative answer, then allow prior TTLs and negative caches to expire. Some DNS changes take up to 48 hours; do not wait out conflicting authoritative answers.
- Retest path: Send through the same application and route that produced the rejection.
- Watch reports: Confirm DMARC aggregate data shows the failing source recovering.
After a DNS migration, confirm the delegated authoritative nameservers and query each for the envelope domain's SPF TXT record and the actual DKIM selector. Fix missing records or conflicting zone answers with the DNS host. A correct record in an inactive DNS zone does not help Gmail. Google's SPF troubleshooting guidance also recommends checking DNS hosting and allowing caches to expire.
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. A forwarder using Sender Rewriting Scheme (SRS) rewrites the envelope sender so SPF can pass for its own domain; that does not by itself satisfy DMARC for the original From domain.
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 later 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
Use a passing custom DKIM signature for DMARC when the envelope domain is unrelated to From.
If both SPF and DKIM fail, inspect routing before blaming Gmail or reputation first.
Escalate relay or DNS faults with the full Gmail rejection and logs to the responsible provider.
Marketer view
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 view
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
How to confirm the fix
Send a fresh message through the same application and outbound route after the DNS or signing change. For a sender outside the bulk category, confirm SPF or DKIM pass and any applicable DMARC requirement. For a bulk sender, confirm that SPF and DKIM pass, DMARC passes, and at least one passing domain has DMARC alignment with the visible From domain.
Keep the failed response and before-and-after header samples with the DNS change record. In Suped, compare the source's next DMARC aggregate results with its earlier failures. Recovery means the same source and identity now authenticate, not merely that a different mail stream passes. Receiver reports usually cover a reporting period, commonly a day, and arrive afterward; a missing report is not proof of successful delivery. The reporting format is defined in RFC 9990.
