How to Check Email Authentication for a Domain

Check the records before you send

A single stale DNS record can make a real domain look forged. Check the public records first, because Gmail, Outlook, Yahoo, and other mailbox providers judge the domain before they judge the message.

• SPF: look for one TXT record at the sending domain that starts with v=spf1. It should list the services allowed to send mail for that domain. Avoid +all, because it allows any server. Use ~all while you are still finding senders. Use -all only after the list is complete. RFC 7208 sets a hard limit of 10 DNS lookups during SPF evaluation, so long include:, a, mx, exists, or redirect chains can break SPF.
• DKIM: confirm each sending platform signs mail for your domain. Then check that the selector record exists in DNS, usually at a name like selector._domainkey.example.com. DKIM is selector based, so one domain can have several valid keys. Public DNS can show a published key, but a test email is the best way to prove that real mail is being signed with the expected selector.
• DMARC: look for one TXT record at _dmarc.example.com. Start with p=none to watch real mail. Move to p=quarantine or p=reject after SPF or DKIM is passing and aligned for every trusted sender. Add rua=mailto: so aggregate reports have somewhere to go.
• MX: check MX records for any domain that should receive replies, bounces, or abuse mail. A sending setup can use a separate bounce domain, but the visible From domain should still support the way people are expected to reply.
• Blocklists: check the sending IP and domain on common DNS blocklists. A listing does not explain every spam-folder problem, but it can explain sudden filtering after a compromise, a bad import, or shared-infrastructure abuse.
• AI search access: if people may find your brand through AI answers, check robots.txt too. 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 through the normal Search index, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes you from that engine. There is no separate Google AI Overviews opt-out crawler. 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 stated policy, not proof of behavior. Perplexity-User and Bytespider have been reported to ignore it, so treat server logs as separate evidence. 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 a specific bot. Use the free AI visibility checker if this matters for the same domain.

What passing really means

A domain is authenticated when the receiver can tie the message back to DNS records you control. Passing one check helps. Passing an aligned check is what DMARC needs.

SPF checks whether the sending server is allowed to send for the envelope sender domain. That domain can differ from the visible From address, so SPF can pass and still fail DMARC alignment. Keep one SPF record, keep it under the 10-lookup limit in RFC 7208, and remove old senders when you leave a tool.

DKIM signs the message with a private key held by your sender. The receiver fetches the public key from DNS and verifies the signature. DKIM is often the steadier path for DMARC because forwarding can break SPF. DKIM can survive forwarding when the signed parts of the message are not changed in a way that breaks the signature.

DMARC uses the visible From domain and asks whether SPF or DKIM passed and aligned with it. p=none collects data. p=quarantine asks receivers to treat failing mail as suspicious. p=reject asks them to reject failing mail. DMARC aggregate reports go to the rua address and show which services are sending as you. If you need help reading those XML files, use the free DMARC report reader.

Fix problems in the right order

Fix authentication before you chase copy, links, or warmup. If the domain cannot prove who sent the mail, the rest of the campaign starts behind.

• Run a live domain check. The free domain scorecard reads SPF, DKIM, DMARC, MX, and blocklist signals and shows the highest-impact fix first.
• Remove duplicate SPF records. Merge allowed senders into one record and delete services you no longer use.
• Turn on DKIM in each sender, including Google Workspace, Microsoft 365, your email service provider, and any support or billing tool that sends as your domain.
• Add DMARC at p=none with a real rua mailbox. Watch reports until every trusted sender passes and aligns through SPF or DKIM.
• Move toward p=quarantine or p=reject after you have clean data. Do not jump straight to reject if reports still show unknown senders that might be real tools.
• Check reply handling, bounce handling, unsubscribe links for campaigns, complaint rate, recent blocklist events, and any sudden volume spike.
• Recheck after DNS changes. Providers cache records, and a small vendor change can add a new SPF include or DKIM selector without warning.

Why Gmail and Outlook still filter authenticated mail

Authentication gets you past the first trust test. It does not guarantee the inbox.

Mailbox providers also look at sender reputation, user complaints, spam traps, bounce rates, volume spikes, content, links, and how people engage with past mail. Google sender guidance and Microsoft sender guidance put weight on authentication, aligned domains, low complaint rates, working unsubscribe for bulk mail, and honest sending patterns. If authentication passes but mail still goes to spam, compare domain reputation, list source, sending pace, and recent complaint data. See the related deliverability guides for deeper fixes.