Read Gmail Authentication Results for SPF, DKIM, DMARC
Drowning in unreadable DMARC report XML? Paste one into our free reader for a plain-English read. Read your report.
Gmail shows the verdict in Show original
A single fail in Gmail's Authentication-Results header can explain one common reason a normal sales reply went to spam. The header shows the SPF, DKIM, and DMARC result before the inbox view hides the detail.
Open the message in Gmail. Click the three dots, then Show original. Gmail shows a short authentication summary at the top. Below it, the raw source includes one or more Authentication-Results lines. Read the line added by Google, then look for spf=, dkim=, and dmarc=.
A clean result might say spf=pass, dkim=pass, and dmarc=pass. The useful parts sit next to those words: smtp.mailfrom for SPF, header.d and header.s for DKIM, and header.from for DMARC. Those domains tell you whether the passing result belongs to your visible From domain or to a sender you hired.
- Use the topmost Authentication-Results line added by Gmail or Google.
- Check SPF, DKIM, and DMARC before older relay headers.
- Keep the full header when asking a provider for help. Screenshots often miss the domain detail.
Map SPF to your domain score
SPF tells Gmail which mail servers may send for the envelope sender domain. In the header, Gmail may report pass, fail, softfail, neutral, none, temperror, or permerror.
spf=pass helps your score when the sending IP is allowed by the domain in smtp.mailfrom. For DMARC, that domain must also align with the visible From domain, usually by sharing the same organizational domain. A pass for a random vendor domain can still leave your own domain weak.
spf=fail means the IP was not allowed. spf=softfail often appears when the record ends in ~all. That says the sender is probably not allowed. -all is stricter and says mail from other servers should fail. Use -all only after every real sender is listed. A record ending in +all is a serious problem because it allows anyone.
SPF also has a hard DNS limit: receivers stop after 10 DNS lookups caused by mechanisms such as include, a, mx, ptr, exists, and redirect. Too many vendors can push a valid-looking record into permerror. Keep one SPF TXT record at the sending domain, remove dead includes, and avoid flattening unless you have a process to keep IPs current.
Map DKIM and DMARC to the real fix
DKIM and DMARC explain more than SPF alone. They tell you whether the message was signed and whether Gmail can connect trust to the visible From domain.
dkim=pass means the message had a valid cryptographic signature. Check header.d for the signing domain and header.s for the selector. The selector points to a DNS record such as selector._domainkey.example.com. If DKIM fails, the key may be missing, the selector may be wrong, the provider may not be signing, or the message may have changed after signing.
dmarc=pass means either SPF or DKIM passed and aligned with the visible From domain. Gmail and Outlook use that result when they judge domain trust, especially under sender rules for higher-volume mail. If DMARC fails while DKIM passes, the DKIM d= domain probably does not align. If SPF passes but DMARC fails, the envelope sender may belong to a different domain.
Your DMARC record lives at _dmarc.example.com. Start with p=none to watch real traffic, then move to p=quarantine or p=reject when SPF and DKIM are passing for every sender. Add rua=mailto:... so receivers can send aggregate reports. If you need to read those XML reports more easily, use the free DMARC report reader.
- Pass DKIM with a selector controlled by your mail provider.
- Align DKIM or SPF with the visible From domain.
- Use DMARC
p=nonefor learning, then enforce withquarantineorreject. - Watch RUA reports before you tighten policy.
Why pass can still land in spam
Authentication is the first gate. Gmail and Outlook still weigh reputation, complaints, volume, blocklists, and whether your domain looks stable.
MX records do not prove outbound mail, but broken or missing MX can hurt replies and make a domain look poorly run. Listings on public blocklists can hurt when an IP or domain has sent unwanted mail, been compromised, or inherited a bad sender history. Content, links, sudden volume spikes, and low engagement can also drag a message into spam even when SPF, DKIM, and DMARC pass.
Use the header to find the exact authentication failure, then check the domain itself. InboxRadar's free domain scorecard reads SPF, DKIM, DMARC, MX, and blocklist signals, grades the domain, and watches for drift after you fix it.
For reference, SPF is defined by RFC 7208, DKIM by RFC 6376, and DMARC by RFC 7489. Google and Microsoft sender guidelines explain how those records affect mail sent to Gmail, Google Workspace, Outlook.com, and Microsoft 365.
Do not confuse email headers with AI crawl access
Email authentication tells mailbox providers whether to trust your mail. AI search visibility depends on whether answer engines can reach and read your site.
The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews, and Applebot for Apple Intelligence. Google AI Overviews use the normal Search index, and there is no separate opt-out crawler. Disallowing these crawlers in robots.txt removes you from that engine.
By contrast, GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.
robots.txt is a site's stated policy, not proof of behavior. Perplexity-User and Bytespider are reported to ignore it, so do not assert what a bot did from robots.txt alone. Only Googlebot documents JavaScript rendering. Client-side-only content may be invisible to other AI crawlers, but that is an undocumented risk, not a proven rule for every bot. For AI crawler rules, check the vendor docs from OpenAI, Anthropic, Perplexity, Google, Apple, and Common Crawl. Check your pages with the free AI visibility checker, and use the guide library at InboxRadar guides when you need the source rules.
Common questions
Where is Authentication-Results in Gmail?
Open the message, click the three dots, choose Show original, then read the raw source. The Gmail summary is useful, but the full Authentication-Results line shows the domains behind SPF, DKIM, and DMARC.
Does SPF pass mean DMARC passes?
No. SPF must pass and align with the visible From domain. DMARC can also pass through aligned DKIM, so a message may fail SPF and still pass DMARC if DKIM is valid and aligned.
What should I fix first when Gmail shows fail?
Fix DMARC alignment first, because it depends on SPF or DKIM passing for your From domain. In practice, that usually means turning on DKIM for each sender, then cleaning SPF so Gmail no longer sees fail, softfail, or permerror.
Should my DMARC policy be reject?
Use p=reject only when you know every real sender is authenticated and aligned. Start with p=none, read RUA reports, fix missing sources, move to quarantine, then reject when the reports are clean.