What could cause Gmail SPF/DKIM issues and how to check authentication results in email headers?
Updated on 25 Oct 2026: We added Google Workspace DKIM setup steps and clarified Gmail header results, SPF forwarding failures, and DMARC domain matching.
Gmail SPF and DKIM issues usually come from sender setup errors, DNS lookup failures, missing DKIM selectors, SPF lookup limits, DMARC domain mismatches, or forwarding changes. Apparent failures in reports can also come from reporting scope. If the raw Gmail header for an affected message shows SPF, DKIM, and DMARC as pass, Gmail authenticated that message. A conflicting aggregate result points to another mail stream, a different reporting view, reporting lag, or sparse data before it points to a DNS change.
Start with one real message that reached a personal Gmail inbox, especially when work mail has internal allowlists. Gmail writes the result into the message headers. The block to find starts with Authentication-Results: mx.google.com. That block records Gmail's SPF and DKIM results. Use Gmail's receiving-server result, not an upstream Authentication-Results entry or ARC-Authentication-Results, which records an earlier hop.
Trust the Gmail header for the individual message, then compare it with aggregate reports. A header pass means that message authenticated. A conflicting dashboard result calls for checks of the selected domain, reporting view, traffic volume, reporting lag, and other senders or subdomains.
For mail sent to personal Gmail accounts, all senders need SPF or DKIM. Bulk senders need SPF, DKIM, and DMARC, with p=none sufficient for the minimum DMARC policy requirement. Direct mail must pass DMARC through a matching SPF or DKIM domain. See Google's sender guidelines. Bulk status applies at roughly 5,000 messages in 24 hours across the same primary domain and its subdomains, and remains once reached, as explained in Google's bulk sender FAQ. Gmail defers messages with 4.7.27 (SPF) or 4.7.30 (DKIM), and rejects them with 5.7.27 or 5.7.30. These are delivery responses, not SPF or DKIM result values; see Google's SMTP error reference.
What causes Gmail SPF and DKIM issues
Gmail evaluates the connecting IP, the envelope sender, each DKIM signature it processes, the public DNS records, and the visible From domain. Sort a sudden drop by the part of that authentication chain that can break.
- DNS lookup failure: A DNS timeout or SERVFAIL can produce temperror. An absent SPF record or DKIM key has a different result, so read the method and error reason.
- SPF lookup limit: An SPF evaluation that exceeds 10 DNS-querying terms, including nested include and redirect evaluations, returns permerror. Publish only one v=spf1 TXT record per domain name; multiple SPF records also cause permerror.
- Missing selector: DKIM fails when the selector in the signature has no matching public key in DNS, or the key is truncated.
- Changed sender: A new mail stream or subdomain can send without the SPF authorization or DKIM signing profile used by established traffic. Check the actual outbound SMTP server and authorize all legitimate IPv4 and IPv6 senders for the envelope sender domain.
- Changed message: Forwarding often breaks SPF because Gmail sees the forwarder's IP instead of the original sender's. DKIM can fail when a forwarder or outbound gateway adds a footer, rewrites content, or otherwise changes signed data.
- Domain mismatch: SPF or DKIM can pass while DMARC fails when the authenticated domain does not match the visible From domain under DMARC rules.
- Report mismatch: An aggregate view can cover another source, a different domain view, or a later window. Low-volume days can also have sparse or omitted data.
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 reputation or content enters the diagnosis.
Gmail email authentication flow: SPF, DKIM, From-domain matching, and header results.
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 change filtering. Use the raw header from the same kind of inbox subscribers use. If Gmail rejects the message before delivery, save the full bounce or SMTP rejection instead. A 550 5.7.26 response can indicate that neither SPF nor DKIM passed, an SPF hard-fail policy rejection, or a DMARC policy rejection; read the complete response.
Gmail More menu with Show original for checking SPF and DKIM email headers.
- Open message: Open the exact Gmail message you want to inspect, not a similar campaign or a forwarded copy.
- On a computer, use the message's three-dot More menu next to Reply and select Show original. Review the SPF, DKIM, and DMARC summary at the top, then inspect the raw headers below it.
- Search the raw source for Authentication-Results: mx.google.com and use Gmail's own receiving-server result.
- Read SPF: Check spf=, the connecting IP, and the envelope sender after smtp.mailfrom. This is the MAIL FROM identity, usually reflected in Return-Path, rather than the visible From address.
- Read DKIM: Check every reported DKIM result and reason, then read d= (signing domain) and s= (selector) in DKIM-Signature. A header.i value is the signing identity; use d= for DMARC domain matching.
- Read DMARC: Confirm whether Gmail found a passing SPF or DKIM domain that matches the visible From domain.
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
This header says Gmail verified the DKIM signature, authorized the SPF sending IP for the envelope sender, and found the domain match DMARC needs. If an aggregate view disagrees for the same message family, check its scope before changing DNS.
How to finish Google Workspace DKIM setup
If Google Workspace sends the affected mail, publishing a DKIM record is only part of setup. Signing must also be enabled for the selected domain.
- In the Google Admin console, open Apps > Google Workspace > Gmail > Authenticate email and select the affected domain. This requires the Gmail Settings administrator privilege.
- If the DNS hostname and TXT value are blank, generate a DKIM record. Publish the exact hostname and complete public key at your DNS provider, avoiding a duplicated domain suffix in the hostname.
- After the record is publicly resolvable, return to Authenticate email and click Start authentication. The expected status is "Authenticating email with DKIM."
- Send a new message to a separate personal Gmail account. Open Show original and verify dkim=pass for your domain; a DNS record alone does not confirm that outgoing mail is signed.
Google documents these checks in Troubleshoot DKIM issues. New Google Workspace setups can require 24-72 hours after Gmail is enabled before a DKIM key can be generated. After publishing DNS changes, allow for caching and up to 48 hours for authentication to start working, then verify a fresh message.
Advanced Gmail DKIM checks
A published selector does not prove that Gmail can validate the signature. Use the raw message and the live DNS response to check these less obvious failure modes.
- Signature order: Gmail checks only the first five DKIM signatures listed in Authentication-Results. A valid signature outside that set can leave DKIM and DMARC failing.
- Body hash: The result 'body hash did not verify' means the received body does not match the signed body hash. Inspect forwarders, outbound gateways, added footers, and encoding changes; also check the sender's signing process.
- Public key length: Gmail requires RSA DKIM keys of at least 1024 bits and recommends 2048 bits. A long key can use adjacent quoted strings of up to 255 octets each within one TXT record. Keep every character in order; do not publish the fragments as separate TXT records.
- Selector match: Read the d= signing domain and s= selector in DKIM-Signature, then query <selector>._domainkey.<signing-domain>. Confirm that the returned key matches the active private key on the sender. For example, d=example.com and s=s1 require the key at s1._domainkey.example.com.
Do not treat a successful DNS lookup as a DKIM pass. Gmail still has to find the signature, retrieve the right key, and verify the signed headers and body. Avoid the DKIM l= body-length tag, which can leave appended content outside the signature.
How to interpret the results
SPF and DKIM are separate checks. SPF validates the connecting IP against the envelope sender domain. DKIM validates a signature for its d= signing domain. DMARC passes when at least one of those checks passes and its domain matches the visible From domain under the published DMARC settings. Under the DMARC specification, relaxed matching, the default, requires the same organizational domain. Strict aspf=s or adkim=s requires an exact domain match for that method, so a subdomain can pass relaxed matching and fail strict matching.
|
|
|
|---|---|---|
spf=pass | The IP is authorized for smtp.mailfrom. | Compare its domain with From. |
dkim=pass | The signature verified for its signing domain. | Compare d= with From. |
dmarc=pass | A passing method matched the visible From domain. | Review non-authentication filtering. |
spf=fail / dkim=fail | SPF: the IP is not authorized. DKIM: the signature did not verify. | For SPF, check the sending IP and forwarding path. For DKIM, check the key and signed data. |
spf=softfail / spf=neutral | Softfail: the SPF policy weakly disallows the sender, commonly through ~all. Neutral: the policy makes no authorization assertion. | Neither result is an SPF pass for DMARC. Confirm authorization for legitimate senders. |
spf=none / dkim=none | SPF: no SPF record was found or no domain could be evaluated. DKIM: no signature was present. | Check the envelope sender domain's SPF record or enable DKIM signing on the sending stream. |
temperror | A temporary lookup or processing error occurred. | Retest and inspect DNS availability. |
permerror | A permanent evaluation error occurred, such as invalid SPF syntax, multiple SPF records, an exceeded lookup limit, or malformed DKIM data. | Read the method-specific reason before changing records or signing configuration. |
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. Configure the envelope sender or DKIM signing domain so its domain matches the From domain under the configured relaxed or strict rule.
Header says pass
If SPF, DKIM, and DMARC all pass in Gmail, the inspected message authenticated. Spam placement then points toward reputation, engagement, content, volume shifts, or blocklist (blacklist) signals.
Header reports a problem
If Gmail shows fail, none, temperror, or permerror, investigate the reported method. A forwarded message can fail SPF while a valid DKIM signature with a matching domain still passes DMARC. Use the reported domain and error reason to decide what needs fixing.
For forwarded mail, Sender Rewriting Scheme (SRS) can restore SPF for the forwarder's domain without creating the domain match needed for the original From address. Authenticated Received Chain (ARC) can preserve earlier authentication results for Gmail to assess, but ARC does not itself turn an SPF, DKIM, or DMARC failure into a pass. A surviving DKIM signature with a matching domain remains important.
How to investigate a sudden drop
When a weekend report shows 0% SPF or DKIM, do not treat it as a Gmail-wide fault until affected headers support that conclusion. A missing or sparse view on a low-volume day is different from a literal 0% pass rate, and either can cover only one selected domain or sender.
Compare an affected Gmail header with the live DNS records first. Next, compare the result with aggregate reports by source IP, subdomain, and sender. Compare raw SPF/DKIM authentication results with the report's DMARC policy evaluation: a method can authenticate successfully but fail the From-domain match. Then send a fresh test through the same sending stream to Gmail to measure the current path.
For an additional test, Suped's email tester checks a new message delivered to its test address. Retest the affected sending stream in Gmail as well, because a result at another receiver does not establish Gmail's result.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Do not rewrite SPF or rotate DKIM keys because one report looks wrong. Save the raw header, sending IP, From domain, selector, report view, and time window first. That evidence identifies whether DNS, signing, routing, or reporting caused the issue.
Where Suped fits
Manual header checks answer what happened to one message. Suped is our DMARC reporting and email authentication platform. It groups authentication results by source and domain so a failed mail stream can be separated from healthy traffic.
Use the sending IP and From domain in the Gmail header to find the matching source in Suped, then compare its reporting window and SPF/DKIM results. Aggregate reports arrive after the reporting window; they are not a live view of an individual Gmail delivery.
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 subdomain, or the whole domain.
- Use alerts: Review authentication changes as new DNS or report data becomes available.
- Use hosted SPF: Manage authorized sender includes and lookup limits through a controlled workflow.
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.
Assuming a work inbox predicts personal Gmail filtering overlooks routing and allowlists.
Changing DNS repeatedly during an incident creates new cache and propagation questions.
Expert tips
Save Gmail's Authentication-Results block and the sending IP for each failed campaign.
Compare the dashboard scope and time window with Gmail headers before changing DNS records.
Check whether the same campaign passed at other receivers before changing shared DNS records.
When Gmail headers pass but mail reaches spam, check reputation and recipient feedback.
Marketer view
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 view
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
