Why do emails get blocked by Gmail for authentication despite correct SPF and DKIM DNS records?
Published 25 May 2025
Updated 12 Oct 2026
15 min read
Summarize with
Updated on 12 Oct 2026: We clarified DMARC domain matching and corrected the SPF, DKIM, and DNS checks behind Gmail authentication rejections.
Gmail blocks email for authentication when the message it receives does not meet the authentication requirement named in the SMTP response. 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 concerns the message Gmail received, its sending path, and the DNS answers available during Gmail's check.
Google documents several 550-5.7.26 responses. The full text can report that SPF and DKIM did not pass, that an SPF record ending in -all rejected the connecting IP, or that unauthenticated mail was rejected under the sender domain's DMARC policy. Google's sender requirements say all senders to personal Gmail accounts need SPF or DKIM. Google treats senders reaching about 5,000 messages to personal Gmail accounts within 24 hours as bulk senders. They need SPF and DKIM plus DMARC, with domain alignment between the From domain and at least one passing authentication domain. Gmail also requires valid forward and reverse DNS, TLS, RFC 5322 formatting, and a spam rate below 0.3%.
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 product collects authentication results over time, separates verified senders from unverified ones, and points to the specific source that needs work.
Why correct DNS records do not prove authentication
Publishing SPF and DKIM DNS records does not prove that either method passes for a particular message. Gmail must successfully retrieve the records and apply them to the exact message that arrived. If the bounce specifically says SPF and DKIM both failed, Gmail found no passing authentication method for that delivery attempt, so it can reject the message before inbox placement decisions matter.
- Wrong domain: SPF checks the SMTP MAIL FROM domain, usually recorded in Return-Path after delivery, 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: The SPF evaluation exceeds its limit of 10 DNS-querying terms, including nested includes, and returns permerror.
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 a passing authentication domain has DMARC alignment with the visible From domain when required.
|
|
|
|---|---|---|
SPF | SMTP MAIL FROM domain, or HELO/EHLO for an empty reverse path | The connecting IP is unauthorized, or DNS resolution or SPF evaluation fails. |
DKIM | Signature | The key is missing, wrong, or the signed message changed. |
DMARC | From domain | Neither SPF nor DKIM passes with domain alignment to the visible From domain. |
PTR | Sending IP | The PTR record is missing, or its hostname's A/AAAA record does not resolve to the sending IP. |
TLS | SMTP session | The sending server does not use a secure connection. |
Gmail checks the delivered message, not only the DNS record you inspected.
For a delivered Gmail test, open the message's More menu and select "Show original". Read the Authentication-Results header added by mx.google.com, not a result inserted by an earlier sender or gateway. For rejected mail, use the full SMTP response and sending-server logs. 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. When the reverse path is empty, as with some bounce messages, SPF evaluates the HELO or EHLO identity instead.
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 and an evaluation that exceeds the limit of 10 DNS-querying terms produce permerror. The limit includes terms evaluated inside nested includes; ip4 and ip6 do not consume it. An unavailable DNS server can produce temperror. An evaluated include target with no SPF record produces permerror. An omitted provider include or incomplete IP range can produce fail when evaluation reaches -all. A 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"
?
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. Check IPv6 as well: an ip4 mechanism does not authorize an IPv6 connection. 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 signature and body hash must verify when Gmail receives it. Query s._domainkey.d using the actual s= selector and d= signing domain from that message. If the selector is a CNAME, check its target's TXT key as well.
- 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 key: The private key used to sign the message does not match the public key published at its selector. A provider-domain signature can pass DKIM while failing DMARC domain alignment.
- Modified message: A footer, link rewrite, security gateway, or MIME change breaks the signed content.
- Short key: Gmail requires at least 1024 bits and recommends 2048 bits when the DNS provider supports it.
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 stream does not prove every stream is signed. Transactional, marketing, billing, and support mail often use separate systems. Check the DKIM signature and selector on each stream. During key rotation, keep the previous selector available while legitimate messages signed with its key remain in transit.
After fixing either DKIM or SPF, validate the published DMARC record with a DMARC checker. DMARC compares the visible From domain with the domain used by a passing authentication method, so it catches cases where SPF passes for a provider bounce domain but uses a different organizational domain.
Why DMARC fails when SPF and DKIM pass
SPF and DKIM can both pass for a provider's domain while DMARC fails for your visible From domain. This is a domain alignment problem. Compare smtp.mailfrom, header.d, and header.from in Gmail's Authentication-Results.
Illustrative SPF and DKIM passes with DMARC failuretext
From: Billing <billing@example.com> Return-Path: <bounce@sender.example> Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=sender.example; dkim=pass header.d=sender.example header.s=mail1; dmarc=fail header.from=example.com
Configure custom DKIM signing with d=example.com or a custom return-path such as bounce.example.com that passes SPF. Relaxed alignment, the default, accepts the same organizational domain. Strict alignment, adkim=s for DKIM or aspf=s for SPF, requires an exact domain match. At least one passing method must satisfy its applicable mode; bulk senders must still configure both SPF and DKIM.
Google's sender requirements accept p=none for the bulk-sender DMARC record requirement. That policy does not make a failing message pass DMARC or waive authentication requirements.
Why forwarding breaks authentication
Forwarding changes the sending path even when the original sender's DNS is correct. Gmail sees the forwarding server's IP, which the original return-path domain usually does not authorize. SPF usually fails on that path; rewriting the envelope sender to a domain the forwarder controls lets it authenticate its own infrastructure. Gmail performs a new authentication check on the forwarded message rather than carrying over a pass from the first delivery.
- SPF after forwarding: The forwarding IP is usually absent from the original sender's SPF record.
- DKIM after forwarding: The signature can survive if the forwarder leaves signed headers and body content unchanged.
- Envelope rewriting: A forwarding operator can use Sender Rewriting Scheme (SRS) to rewrite MAIL FROM to its own domain. SPF can then pass for that domain, but that pass usually lacks DMARC alignment with the original From domain.
- Message modification: Subject tags, footer insertion, MIME changes, and re-encoding can invalidate DKIM.
Confirm whether the path is direct
Compare the Received headers and return path with the route you expected. If a mailing list, alias, gateway, or forwarding mailbox handled the message, troubleshoot that indirect path. Do not add the forwarder's IP to the original sender's SPF record unless the sender actually authorizes and controls that service.
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. Compare the failed and passing attempts to establish whether the DNS answer, connecting IP, or DKIM selector changed.
- Authoritative DNS: Nameservers can respond slowly, inconsistently, or with different zone data. Confirm the records were edited at the active authoritative nameservers, not in an unused DNS control panel.
- Recent change: Resolvers can retain the previous SPF or DKIM answer until its TTL expires.
- Provider routing: Mail can leave through a temporary IP range during maintenance or incidents.
- DNSSEC failure: A stale DS record or invalid signature can cause validating resolvers to return SERVFAIL.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's DMARC reporting product keeps recurring authentication issues tied to their sending sources. Compare failure patterns and suggested fix steps with the bounced message's IP and selector.
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. Use that comparison to distinguish a resolved transient issue from a persistent configuration problem.
How to troubleshoot Gmail authentication rejections
Use this order to keep the investigation tied to evidence. It also prevents several DNS changes after one bounce from obscuring 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: For a Gmail delivery, use "Show original" and read Gmail's Authentication-Results. A pass at another receiver does not prove Gmail saw the same result.
- Check envelope: Confirm the SMTP MAIL FROM domain SPF used, plus d= and s= in the DKIM signature.
- Query DNS: Check SPF, DKIM, DMARC, and PTR records from outside your network.
- Ask provider: Confirm the actual outbound SMTP service and whether its 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 bounce.example.com dig TXT mail1._domainkey.example.com dig TXT _dmarc.example.com dig -x 203.0.113.10 dig A mail.example.com dig AAAA mail.example.com
Replace bounce.example.com with the actual MAIL FROM domain, mail1 and example.com in the DKIM query with the message's s= and d= values, and the DMARC query with the visible From domain. Query the PTR hostname's A/AAAA records and confirm they resolve to the connecting IP. Compare authoritative DNS with public recursive answers. If an old answer is still cached, wait for its TTL to expire. Repair the authorized SPF range or enable DKIM signing for the affected stream, then send a fresh test. MX records control inbound delivery; changing them does not repair an outbound SPF or DKIM rejection.
Use DMARC reports to find failing senders
DMARC does not replace SPF or DKIM. It checks whether a domain used by passing SPF or DKIM has domain alignment with the visible From domain. The receiving server considers the published policy and its own rules when deciding how to handle a failure. That matters because many SPF passes belong to a provider's bounce domain. Gmail requires DMARC for bulk senders, and DMARC aggregate reports give you a map of the systems claiming to send as your domain.
Suped's product uses DMARC aggregate reports to identify authentication failures by sending source. Its hosted DMARC controls help teams stage policy changes after legitimate senders pass. Reports are delayed summaries from participating receivers; use the full SMTP response to investigate a specific Gmail rejection.
Manual DNS management
- Slow changes: Policy edits usually need DNS access or coordination with the DNS administrator.
- Limited history: One test does not show repeated failures by source.
- Hidden risk: An incomplete sender inventory can leave old sending systems untested.
Suped workflow
- Source view: Verified and unverified senders are separated.
- Fix steps: Issues include tailored actions and verification.
- Policy staging: Hosted DMARC controls let teams stage policy changes after reviewing legitimate senders.
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 authentication passes 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 (blacklist) status, and sending volume matter, but they usually produce different symptoms. A 5.7.26 response that names both failures means Gmail could not authenticate that delivery with SPF or DKIM.
Once authentication is passing, Gmail can still reject mail, rate-limit it, or route it 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
Read the exact enhanced status code and response text. Gmail uses 5.7.25 for invalid PTR configuration, 5.7.27 for a bulk-sender SPF failure, 5.7.29 for missing TLS, 5.7.30 for a bulk-sender DKIM failure, 5.7.32 for domain alignment, and 550 5.7.40 for a missing DMARC record or policy. A 4.x response is temporary, while a 5.x response is permanent for that attempt. Temporary 4.7.26 responses also cover unauthenticated mail or authentication prevented by DNS errors; read the full response before deciding how to retry. Each class needs a different fix.
Bulk-sender status also matters after volume drops. Gmail aggregates traffic under the same primary domain when counting the daily threshold, and a sender classified as bulk remains classified as bulk. Marketing and subscribed messages in that category need one-click unsubscribe plus a visible unsubscribe link. Honor unsubscribe requests within two days. Since November 2025, Gmail has increased enforcement against traffic that fails its sender requirements, including temporary and permanent rejections.
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
Retest the same sending stream 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 view
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 view
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
Frequently asked questions
Yes. Gmail rejects based on the message it receives and the DNS answers available during delivery. Published records do not prevent rejections if Gmail evaluates a different domain, the connecting IP is unauthorized, the message has no valid signature, or DNS resolution fails.
SPF checks the SMTP MAIL FROM domain, usually shown in Return-Path after delivery, rather than the visible From address. If the reverse path is empty, SPF uses the HELO or EHLO domain. Checking only the visible domain's SPF record misses failures on the actual envelope domain.
Forwarding changes the connecting IP, so the original sender's SPF result usually fails. DKIM can still pass if the forwarder does not alter signed headers or body content. Check the Received chain to confirm whether Gmail evaluated a direct or forwarded path.
A new delivery attempt can pass after cached DNS data expires, resolver recovery, provider routing changes, or a temporary sending platform incident. A 550 rejection is permanent for the original attempt; send a fresh test after diagnosing the cause. Compare the failed result with the new passing result.
No. DMARC requires SPF or DKIM to pass with domain alignment to the visible From domain. SPF and DKIM can both pass for provider domains while DMARC fails. Fix authentication or domain matching, then use DMARC reports to check legitimate sending sources.
Not immediately unless the missing record or wrong IP is clear. Capture the full evidence, run a fresh test, compare the exact sender path, then make the smallest DNS or provider change that addresses the failure.
