Gmail Says This Message Is Not Authenticated: Fixes

Why Gmail shows this warning

A small red question mark in Gmail can make a real brand look like a spoof.

When Gmail says a message is not authenticated, it could not confirm the sender with SPF or DKIM. The risky case for a brand is when those checks do not align with the domain in the visible From address. The usual cause is a missing or broken SPF record, missing DKIM signing, or a DMARC alignment failure. A newer domain, a shared sending platform, a changed DNS record, or a vendor sending from the wrong return-path can trigger it even when the message looks normal to you.

Do not guess from the inbox view alone. Open the message headers and look for Authentication-Results. You want spf=pass and dkim=pass where possible, and dmarc=pass for the visible From domain. Gmail and Outlook also weigh reputation, complaints, blocklists, links, malware, volume, and recipient behavior. Authentication is the first fix because it proves identity. Reputation decides whether trusted mail gets inboxed, spammed, or rejected.

A quick way to see the live DNS state is the free InboxRadar domain scorecard. It checks SPF, DKIM, DMARC, MX, and blocklist signals from outside your account, then shows which record is most likely causing the warning.

Fix SPF first

SPF tells receivers which servers may send mail for your domain.

SPF is a TXT record on the domain used in the envelope sender, usually shown as Return-Path or MAIL FROM. It starts with v=spf1. A simple Google Workspace example is v=spf1 include:_spf.google.com ~all. A simple Microsoft 365 example is v=spf1 include:spf.protection.outlook.com -all. Your real record must include every service that sends as your domain, such as your help desk, CRM, newsletter tool, billing system, website app, and mail host.

• Publish only one SPF record per domain or sending subdomain.
• Remove old vendors that no longer send for you.
• Use provider docs for each include: value. Do not copy a random record from another site.
• Keep SPF under the RFC 7208 limit of 10 DNS-querying lookups across include, a, mx, ptr, exists, and redirect.
• Use ~all while you are still finding senders. Move to -all when the sender list is complete and DKIM plus DMARC are working.
• Never use +all. It tells receivers that any server may send as your domain.

SPF checks the envelope sender, also called Return-Path or MAIL FROM. That may differ from the address people see in Gmail. A message can pass SPF for a vendor domain and still fail DMARC for your brand domain. That is why SPF alone does not always remove the Gmail warning.

Turn on DKIM signing

DKIM adds a cryptographic signature to the message, then publishes the matching public key in DNS.

Most providers give you one or more DKIM selector records. A selector is the name before ._domainkey, such as selector1._domainkey.example.com. Google, Microsoft, and email service providers generate the key or CNAME target for you. Publish the exact DNS record they give you, then enable signing in that provider.

After DNS updates, send a fresh test message to Gmail and check the headers. Look for dkim=pass. Also check the DKIM d= domain. For DMARC, that signing domain must align with the visible From domain. If your From address is you@example.com but the only passing DKIM signature is from vendor-mail.com, Gmail may still treat the message as unauthenticated for your domain.

• Enable DKIM for every service that sends mail using your domain.
• Use provider-generated selectors and keys. Do not invent them.
• Rotate keys through the provider's normal process when offered.
• Retest after changes, because old messages keep their old headers.
• Keep DKIM working even when SPF passes, since forwarding can break SPF.

Make DMARC pass

DMARC is the rule that ties SPF and DKIM to the From address people see.

Publish DMARC as a TXT record at _dmarc.yourdomain.com. A safe first record is v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none collects data without asking receivers to spam or reject failures. The rua address gets aggregate reports that show which IPs and services send as your domain, and whether SPF, DKIM, and DMARC passed.

DMARC passes when SPF passes and aligns, or DKIM passes and aligns. Alignment means the authenticated domain matches the visible From domain at the organizational domain level by default. If Gmail says your message is unauthenticated while SPF or DKIM shows pass, alignment is the next thing to check.

Move carefully from p=none to p=quarantine, then to p=reject. p=quarantine asks receivers to treat failing mail as suspicious, often by placing it in spam. p=reject asks receivers to reject failing mail. Receivers still apply their own policy. Do not enforce DMARC until every real sender has aligned SPF or aligned DKIM.

If the aggregate XML files are hard to read, use the free DMARC report reader to see which source is failing before you tighten policy.

Check MX, blocklists, and reputation

Authentication removes the identity problem. Spam filters still judge whether people want the mail.

MX records say where inbound mail for your domain should be delivered. Bad MX records do not normally cause a specific outbound SPF failure, but they can break replies, abuse contacts, verification loops, and checks that expect the domain to receive mail. Make sure the MX records match the provider that receives mail for you.

Then check blocklists and sender reputation. Gmail's sender rules require authentication, valid forward and reverse DNS for sending servers, low spam complaint rates, and honest sending practices. Bulk senders to personal Gmail accounts have stricter requirements, including SPF, DKIM, DMARC, alignment, and easy unsubscribe for marketing mail. Microsoft also uses SPF, DKIM, DMARC, and its own reputation and filtering signals for Outlook and Microsoft 365 recipients.

• Check Google Postmaster Tools if you send enough volume to see data.
• Look for sudden volume jumps, compromised mailboxes, and old lists.
• Make unsubscribe clear for marketing mail and stop mailing people who complain.
• Scan major blocklists when spam placement changes overnight.
• Fix the cause before requesting delisting, or the listing can come back.

Official references are worth using for the exact rules: RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for DMARC, Google sender guidelines, and Microsoft email authentication guidance.

Do the repair in this order

Fix the record that proves identity before chasing copy, links, or templates.

• Send a test message to Gmail and save the full headers.
• Confirm the visible From domain, Return-Path domain, and DKIM d= domain.
• Fix duplicate, missing, or over-large SPF records.
• Turn on DKIM signing for the same domain people see in the From address.
• Publish DMARC with p=none and a working rua address.
• Use DMARC reports to find every service sending as you.
• Move toward p=quarantine and p=reject after legitimate mail passes.
• Check MX, blocklists, complaint rate, and list quality if Gmail still routes mail to spam.

For deeper fixes after authentication passes, use the related guides at InboxRadar articles.

AI search visibility for this fix page

If customers search for your fix in AI answers, crawlers need to reach and read the page.

The crawlers that decide whether a page can appear in live AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews through the normal Google Search index, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes your site from that engine's live search visibility.

Training controls are different. GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not remove a page from live AI search visibility. Google-Extended and Applebot-Extended are robots-only control tokens, with no separate crawl user-agent.

A robots.txt file is a stated site policy, not proof of what a bot did. Logs show requests. Perplexity-User and Bytespider have been reported to ignore robots.txt, so treat those reports as claims about behavior, not a promise about every request. Also keep the main answer in server-rendered HTML when you can. Googlebot documents JavaScript rendering. For other AI search crawlers, client-side-only content is an undocumented risk, so do not rely on it for critical help content.

Use the free AI visibility checker when you need to see whether a page is open to the search crawlers. Vendor docs to confirm the crawler names are OpenAI crawlers, Anthropic crawler controls, Perplexity crawlers, Google crawlers, Applebot, and Common Crawl CCBot.