How to Check Your Email Authentication Setup
Updated February 6, 2026
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 — this completely defeats SPF. The ?all qualifier is neutral and provides no protection. Use ~all (soft fail) during testing and -all (hard fail) for production.
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 (512 or 1024 bits): Keys shorter than 2048 bits are considered weak. Generate a new 2048-bit key pair and rotate your DKIM configuration. See our DKIM guide for key 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 is appropriate for monitoring but provides no enforcement. If you've been on p=none for more than a month and your reports show clean authentication, progress to p=quarantine.
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 | Every 6-12 months | Keys should be rotated periodically |
| 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.