How to Check Your Email Authentication Setup
Updated September 20, 2026
Technical review by Muhannad Binmiskeen, DNS Kit developer and operator. Review policy
Misconfigured email authentication is one of the most common DNS issues — and one of the most damaging. A broken SPF record silently fails, a missing DKIM key causes signatures to fail, and a weak DMARC policy leaves your domain open to spoofing. This guide walks you through checking each component step by step.
Quick Check: Use DNS Kit's Email Health Tool
The fastest way to verify your entire email authentication setup is to use an automated tool that checks everything at once.
Scan your domain's email authentication in seconds.
Free, instant, no login required.
DNS Kit's Email Health Checker scans your domain and validates:
- SPF record presence, syntax, and lookup count
- DKIM record presence and key validity
- DMARC record presence, policy strength, and reporting configuration
- MX record configuration
It provides a health score and specific fix recommendations for any issues found.
If you want to understand what the tool is checking — or prefer to verify manually — follow the step-by-step process below.
Step 1: Check Your SPF Record
What to Look For
Your domain should have exactly one TXT record starting with v=spf1.
How to Check
dig TXT example.com +short
Look for a line that starts with v=spf1. For example:
"v=spf1 include:_spf.google.com include:sendgrid.net -all"
Common SPF Issues
No SPF record found: Your domain has no SPF record at all. Any server can claim to send email as your domain. Add a TXT record listing your authorized senders.
Multiple SPF records:
You have two or more TXT records starting with v=spf1. This causes a PermError — both records are invalid. Merge them into a single record.
# WRONG: Two SPF records
"v=spf1 include:_spf.google.com -all"
"v=spf1 include:sendgrid.net -all"
# CORRECT: One merged record
"v=spf1 include:_spf.google.com include:sendgrid.net -all"
Too many DNS lookups (over 10):
Each include, a, mx, and redirect mechanism counts as a DNS lookup. Exceeding 10 causes a PermError. Count your lookups:
# Each of these counts as 1 lookup:
include:_spf.google.com # 1 (plus nested lookups inside Google's record)
include:sendgrid.net # 1
include:mailchimp.com # 1
mx # 1
a # 1
The 10-lookup limit includes nested lookups. If include:_spf.google.com itself contains 3 more include mechanisms, that's 4 lookups total for that one entry. Use DNS Kit to count the actual total.
Using +all or ?all:
The +all qualifier authorizes every server and defeats SPF's authorization purpose. The ?all qualifier returns Neutral. Choose ~all or -all only after inventorying legitimate senders; these produce SPF results, while receivers decide delivery under local policy.
For a complete SPF reference, see our SPF records guide.
Step 2: Check Your DKIM Record
What to Look For
A DKIM public key should be published as a TXT record at selector._domainkey.yourdomain.com.
Finding Your Selector
The selector depends on your email provider:
| Provider | Common Selector(s) | DNS Record Location |
|---|---|---|
| Google Workspace | google | google._domainkey.example.com |
| Microsoft 365 | selector1, selector2 | selector1._domainkey.example.com |
| Mailchimp | k1 | k1._domainkey.example.com |
| SendGrid | s1, s2 | s1._domainkey.example.com |
| Amazon SES | Custom (varies) | Check your SES dashboard |
How to Check
# Google Workspace
dig TXT google._domainkey.example.com +short
# Microsoft 365
dig TXT selector1._domainkey.example.com +short
# Should return something like:
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."
Common DKIM Issues
No DKIM record found: Either the selector is wrong or the record hasn't been published. Verify the selector with your email provider and check that the DNS record exists at the correct location.
Empty p= value:
A record with p= (empty) means the key has been revoked. This selector is no longer valid. Check with your email provider for the current selector.
Key too short: RFC 8301 requires DKIM signers using RSA to use keys of at least 1024 bits and recommends 2048 bits or more. A 512-bit key is invalid under that guidance; a 1024-bit key is permitted but should be upgraded where DNS and provider constraints allow. See our DKIM guide for staged rotation steps.
Record truncated: Long DKIM keys (2048-bit) may be split across multiple DNS TXT record strings. Verify the full record is being served:
dig TXT google._domainkey.example.com
Check that the p= value is complete and ends properly. Truncated keys cause signature verification to fail.
Step 3: Check Your DMARC Record
What to Look For
A DMARC record should be published as a TXT record at _dmarc.yourdomain.com, starting with v=DMARC1.
How to Check
dig TXT _dmarc.example.com +short
Should return something like:
"v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"
Common DMARC Issues
No DMARC record found:
Without DMARC, receivers make their own decisions about unauthenticated email. Add a DMARC record starting with p=none to begin monitoring.
v=DMARC1; p=none; rua=mailto:[email protected]
Policy too weak (p=none):
p=none requests no special handling and is useful for monitoring. Move to an enforcement policy only after reports identify every legitimate sender and aligned authentication is stable; there is no standards-mandated one-month deadline.
No rua tag (no reporting):
Without rua, you receive no aggregate reports. You won't know if legitimate email is failing or if attackers are spoofing your domain. Always include an rua address.
Syntax errors: Common mistakes include missing semicolons, incorrect tag names, or spaces in the wrong places:
# WRONG: missing semicolons
v=DMARC1 p=reject rua=mailto:[email protected]
# WRONG: incorrect tag
v=DMARC1; policy=reject;
# CORRECT
v=DMARC1; p=reject; rua=mailto:[email protected]
When you're ready to strengthen your DMARC policy, use the pct tag to roll out gradually. Start with pct=10 to apply the policy to 10% of failing messages, then increase to 25%, 50%, and finally 100% as you confirm everything works.
For a complete DMARC deployment guide, see our DMARC setup guide.
Step 4: Check MX Records
While not strictly an authentication protocol, your MX records are essential for email delivery. Verify they point to the correct mail servers:
dig MX example.com +short
Should return your email provider's servers with proper priority values:
1 ASPMX.L.GOOGLE.COM.
5 ALT1.ASPMX.L.GOOGLE.COM.
5 ALT2.ASPMX.L.GOOGLE.COM.
Step 5: Send a Test Email
After verifying DNS records, send a test email and inspect the headers on the receiving side. Look for the Authentication-Results header:
Authentication-Results: mx.google.com;
dkim=pass header.d=example.com header.s=google;
spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender);
dmarc=pass (p=REJECT) header.from=example.com
All three should show pass. If any shows fail or temperror, review the corresponding DNS record.
Ongoing Monitoring Checklist
Email authentication isn't a set-and-forget configuration. Review these regularly:
| Check | Frequency | Why |
|---|---|---|
| SPF record and lookup count | After adding any new email service | New include mechanisms can push you over the 10-lookup limit |
| DKIM key validity | Per provider security policy and after suspected compromise | A new selector supports staged key rotation |
| DMARC reports | Weekly during rollout, monthly after | Catch unauthorized senders and misconfigurations |
| DMARC policy level | Quarterly | Progress from none to quarantine to reject |
| MX record accuracy | After email provider changes | Incorrect MX records break incoming email |
Run a full email authentication audit on your domain now.
Free, instant, no login required.
For background on how these protocols work together, read our email authentication overview. For deep dives into individual protocols, see our guides on SPF, DKIM, and DMARC.
Primary sources
This guide was checked against the following standards. Receiver and provider behavior can still vary by implementation and local policy.