What could cause Gmail SPF/DKIM issues and how to check authentication results in email headers?
Michael Ko
Co-founder & CEO, Suped
Published 27 Apr 2025
Updated 4 Jun 2026
6 min read
Summarize with
Gmail SPF and DKIM issues are usually caused by sender-side setup problems, DNS lookup failures, broken DKIM selectors, SPF lookup limits, domain match failures for DMARC, forwarding changes, or a reporting mismatch. If the raw Gmail header for an affected message shows SPF, DKIM, and DMARC as pass, Gmail authenticated that message. A 0% report in a dashboard then points to another mail stream, delayed reporting, a test-path difference, or a non-authentication deliverability problem.
I start with one real message that reached a personal Gmail inbox, especially if work mail has internal allowlists. Gmail writes the answer into the message headers. The block to find starts with Authentication-Results. That line tells you whether Gmail passed, failed, or was unable to evaluate SPF and DKIM.
The fastest answer is this: trust the Gmail header for the individual message, then compare it with your aggregate reports. A header pass means that message authenticated. A dashboard showing 0% at the same time means you need to check message scope, sampling, reporting delay, and whether another sender or subdomain had the failure.
What causes Gmail SPF and DKIM issues
Gmail does not invent SPF or DKIM results. It evaluates the connecting IP, the envelope sender, the DKIM signatures, the public DNS records, and the visible From domain. When a weekend drop appears, I sort causes by the part of the authentication chain that can break.
- DNS outage: If Gmail cannot resolve SPF or DKIM records at delivery time, it records a temporary error or no usable result.
- SPF lookup limit: SPF stops after too many DNS lookups, so a record that looks valid can fail under Gmail evaluation.
- Missing selector: DKIM fails when the selector in the signature has no matching public key in DNS.
- Changed sender: A new mail stream or subdomain can send without the same SPF include or DKIM signing profile.
- Broken signature: DKIM fails when headers or body content are changed after signing.
- Domain mismatch: SPF or DKIM can pass but still fail DMARC when the passing domain does not match the visible From domain.
- Report mismatch: A dashboard can show a bad rate for a different source, later reporting window, or smaller sample than the message you inspected.
For a broad DNS and authentication check, run the domain through Suped's domain health checker. If the problem narrows to one mechanism, validate the published record with the SPF checker or the DKIM checker. That confirms whether DNS has the data Gmail needs before you diagnose reputation or content.
Flowchart showing how Gmail checks SPF, DKIM, From domain match, and headers.
How to inspect Gmail headers
The most useful test is a message that went to spam in a normal Gmail mailbox. A work mailbox can hide the real result because routing rules and allowlists can bypass parts of filtering. I want the raw header from the same kind of inbox subscribers use.
Gmail message menu with Show original selected for header inspection.
- Open message: Open the exact Gmail message you want to inspect, not a similar campaign or a forwarded copy.
- Show original: Use the three-dot menu and select Show original.
- Find results: Search the raw source for Authentication-Results.
- Read SPF: Check the result, connecting IP, and envelope sender shown after smtp.mailfrom.
- Read DKIM: Check each signature result, selector, and signing identity.
- Read DMARC: Confirm whether Gmail says the message met the visible From domain requirement.
Gmail Authentication-Results example
Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=s1 header.b=abc123; spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com; dmarc=pass (p=quarantine sp=none dis=none) header.from=example.com
That header says Gmail accepted the DKIM signature, accepted the SPF sending IP for the envelope sender, and found enough domain match for DMARC. If a report says 0% for the same message family, the next step is scope checking, not changing DNS immediately.
How to interpret the results
SPF and DKIM are separate checks. DMARC looks at whether at least one of those passing checks belongs to the visible From domain. That difference explains many confusing Gmail headers.
|
|
|
|---|---|---|
spf=pass | The sending IP is authorized. | Check From match. |
dkim=pass | The signature verified. | Check signer domain. |
dmarc=pass | A pass matched From. | Review filtering. |
none | No usable result. | Check DNS and signing. |
temperror | Temporary lookup issue. | Retry and inspect DNS. |
permerror | Record has a hard error. | Fix the record. |
Common Gmail header results and what they mean.
Passes SPF but fails DMARC
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounces.sender.example; dkim=none; dmarc=fail header.from=example.com
In that example, SPF passed for the bounce domain, but Gmail did not get a passing result tied to the visible From domain. The fix is to make the sending domain setup match the way the message is branded.
Header says pass
If SPF, DKIM, and DMARC all pass in Gmail, the inspected message authenticated. Poor opens or spam placement then point toward reputation, engagement, content, volume shifts, or blocklist (blacklist) signals.
Header says fail
If Gmail shows fail, none, temperror, or permerror, fix the authentication path first. A deliverability investigation has weak footing until Gmail can authenticate the mail.
How to investigate a sudden drop
When a weekend report shows 0% SPF or DKIM, I avoid treating it as a Gmail-wide fault until the headers support that. A broad receiver issue would usually affect many senders at the same time. A domain-specific issue is more common.
SPF and DKIM triage thresholds
Use these bands to decide whether to fix records, monitor reports, or inspect other deliverability signals.
Healthy
95-100%
Headers pass for affected samples and reports agree.
Watch
80-94%
Some failures appear on one stream or one sender.
Fix now
0-79%
Failures are visible in Gmail headers.
The investigation order matters. First, compare an affected Gmail header with your DNS records. Second, compare that result with aggregate reports by source IP, subdomain, and sender. Third, send a fresh seed test so the current path is measured cleanly.
For the fresh seed test, Suped's email tester is useful because it gives you a current message-level result, not only an aggregate report that arrives later.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Do not rewrite SPF or rotate DKIM keys just because one report looks wrong. Save the raw header, the sending IP, the From domain, and the selector first. That evidence tells you whether DNS, signing, or reporting caused the issue.
Where Suped fits
Manual header checks are excellent for one message. They are not enough for ongoing monitoring across multiple senders, subdomains, and DNS changes. Suped's product connects DMARC, SPF, DKIM, hosted SPF, hosted DMARC, blocklist (blacklist) monitoring, and real-time alerts in one workflow.
Suped is the best overall DMARC platform for most teams that need continuous visibility instead of one-off checks. The practical value is issue detection with steps to fix, source-level reporting, hosted SPF for managing senders without repeated DNS edits, and alerts when authentication rates change.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
- Use headers: Confirm what Gmail did for one exact message.
- Use reports: Find whether the issue affected one source, one campaign, or the whole domain.
- Use alerts: Catch authentication changes before they turn into a sender-wide deliverability incident.
- Use hosted SPF: Control sender includes and lookup limits without asking for DNS changes every time.
Views from the trenches
Best practices
Capture the raw Gmail header before changing DNS so later checks compare facts, not memory.
Test with a personal Gmail inbox because internal allowlists can hide real spam placement.
Track each sending stream separately so one broken selector does not look domain-wide.
Keep SPF includes current and remove unused senders before the lookup limit is hit.
Common pitfalls
Assuming a Gmail-wide fault before checking one affected message's headers wastes time.
Reading only DKIM pass and ignoring the From-domain match leaves DMARC failures unclear.
Using a work inbox for tests gives cleaner results than subscribers receive in Gmail.
Changing DNS repeatedly during an incident creates new cache and propagation questions.
Expert tips
Save the Authentication-Results block and the sending IP for each failed campaign.
Compare provider dashboard signals with Gmail headers before blaming DNS providers.
Check whether the same campaign passed for non-Gmail mailboxes before broad fixes.
When headers pass but mail lands in spam, shift investigation to reputation signals.
Marketer from Email Geeks says Gmail headers are the fastest way to separate a real SPF or DKIM failure from reporting noise.
2020-07-27 - Email Geeks
Marketer from Email Geeks says a personal Gmail seed is useful because work mail can have allowlists that hide mailbox filtering.
2020-07-27 - Email Geeks
The practical answer
Gmail SPF and DKIM issues can come from DNS, sender setup, DKIM signing, SPF limits, From-domain mismatch, or reporting scope. The way to prove the cause is to inspect the Gmail Authentication-Results header for an affected message and compare it with your aggregate authentication data.
If the Gmail header passes, keep the DNS record stable and investigate sender scope, reporting delay, reputation, content, and blocklist (blacklist) signals. If the header fails, fix the specific SPF, DKIM, or DMARC problem shown there before changing anything else.
