How to Check SPF, DKIM, and DMARC for Any Domain — Stop Emails From Hitting Spam
How to Check SPF, DKIM, and DMARC for Any Domain — Stop Emails From Hitting SpamYour DNS looks perfect. Your emails still land in spam. Here’s the part nobody explains.
SPF record? Published. DKIM key? In DNS. DMARC? Set to reject.
And your emails still go to spam. The reason most guides skip: those three records can all exist and still fail — because email authentication isn’t about whether records exist. It’s about whether real messages actually pass and align with your visible From address. That one word — alignment — is what breaks 90% of “everything looks fine” setups.
🔍 Quick-Start — Check Everything in 5 Minutes
Think of email authentication like a building’s security system. SPF is the guest list (who’s allowed in). DKIM is the ID badge (proof you are who you say). DMARC is the security guard (checks if the guest list OR the badge match the name on the door).
Here’s the fastest way to check all three — no command line, no DNS digging:
Step 1 → Run a full scan first to see the big picture.
Email Health Checker — shows whether SPF, DKIM, and DMARC exist and flags obvious problems.
Step 2 → Check your SPF record — look for a TXT record on your root domain starting with v=spf1.
Step 3 → Check your DMARC record — look for a TXT record at _dmarc.yourdomain.com starting with v=DMARC1.
Step 4 → Check your DKIM record — you need the selector first, then check selector._domainkey.yourdomain.com.
Step 5 → Confirm alignment — at least SPF or DKIM must pass and match your visible From domain.
Step 6 → If everything looks right but emails still go to spam, check a real email header:
Email Header Analyser — shows what the receiving server actually saw.
Trick: Don’t just check whether records exist. Send yourself a test email, then look at the raw header — that’s where the truth is. DNS can look perfect while live messages silently fail.
📬 What SPF, DKIM, and DMARC Actually Do — Plain English
SPF — The Guest List
Think of SPF like a door policy at a club. Your domain publishes a list of IPs and services allowed to send email on your behalf. If Google Workspace, SendGrid, or Amazon SES sends your mail, they need to be on that list.
SPF lives as a TXT record on your root domain. It looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
If a service sends email for you but isn’t in this record, SPF fails for those messages.
DKIM — The ID Badge
DKIM adds an invisible digital signature to every email you send. When the receiving server gets your message, it checks a public key stored in your DNS to confirm two things: the message was signed by someone you authorized, and nobody changed it in transit.
The tricky part: DKIM doesn’t live at your root domain. It lives at a specific address like:
google._domainkey.yourdomain.com
That first part (google) is the selector — and if you check the wrong selector, the whole lookup fails even when DKIM is perfectly configured.
DMARC — The Security Guard
DMARC sits on top of SPF and DKIM. It tells receiving servers what to do when authentication fails — ignore it (p=none), put it in spam (p=quarantine), or reject it entirely (p=reject).
But here’s the critical part most guides skip:
DMARC doesn’t just care whether SPF or DKIM passed. It cares whether they passed AND matched your visible From address.
That matching is called alignment — and it’s the #1 reason people get stuck.
| Protocol | What It Checks | Where to Look | Most Common Mistake |
|---|---|---|---|
| SPF | Who can send mail for your domain | Root domain TXT record | Multiple SPF records or too many DNS lookups |
| DKIM | Whether the email was digitally signed | selector._domainkey.domain.com |
Wrong selector, or record exists but provider isn’t signing |
| DMARC | Whether SPF or DKIM passes and aligns | _dmarc.domain.com |
Thinking “record exists” = “DMARC works” |
⚠️ Step Zero — Make Sure You're Checking the Right Domain
A surprising number of checks fail because someone tested the wrong domain.
Root domain vs subdomain matters. These are all different:
example.commail.example.comupdates.example.com
If your emails go out from a subdomain, that changes which SPF record applies, which DKIM selector is used, and which DMARC policy kicks in.
For DMARC, the visible From address is everything. Three domains often get confused:
| Domain | What It Is | Why It Matters |
|---|---|---|
| From: | What the recipient sees | DMARC checks alignment against THIS |
| Return-Path: | Where bounces go (what SPF checks) | Can be different from the From domain |
| DKIM d= | The domain in the DKIM signature | Must align with From for DMARC via DKIM |
🛠️ Step-by-Step — Check SPF
Where SPF lives: TXT record on your root domain, starting with v=spf1.
What to look for:
A healthy SPF record includes every service that sends email for you. It starts with v=spf1, lists your services with include:, and ends with ~all (softfail) or -all (hardfail).
The 5 most common SPF problems:
| Problem | What Happens | Fix |
|---|---|---|
| No SPF record at all | No authentication — anyone can pretend to be you | Add a TXT record starting with v=spf1 |
| Multiple SPF records | Both break — receivers see a PermError | Combine into ONE record with all includes |
| Missing a sending service | That service’s emails fail SPF | Add its include: to your record |
| Old/dead includes | Bloats the record, wastes DNS lookups | Remove services you don’t use anymore |
| Too many DNS lookups | SPF silently fails — even if syntax is correct | Flatten or consolidate (see below) |
The hidden killer: the 10 DNS lookup limit
This is the #1 SPF problem nobody warns you about. Every include:, a, mx, and exists in your SPF triggers a DNS lookup. If the total chain (including nested includes inside other SPF records) exceeds 10 lookups, SPF returns a permanent error — your email fails authentication and you never get a warning.
Real-world example: Google Workspace alone eats 3-5 lookups. Add Microsoft 365 (3-5 more), SendGrid (1-3), and a CRM (1-2) — you’re already past the limit.
This limit is defined in RFC 7208. It’s not optional. And ip4: / ip6: mechanisms don’t count against it — only mechanisms that need DNS resolution.
If your SPF record is bloated, use this:
SPF Flattening Tool — replaces include: mechanisms with direct IP addresses, cutting your lookup count.
🔐 Step-by-Step — Check DKIM
DKIM is where most “simple” guides become useless — because they skip the hardest part: you need the selector.
Where DKIM lives: selector._domainkey.yourdomain.com — NOT at the root domain.
How to find the selector:
- Check your email provider’s DNS setup instructions (Google uses
google, many services usedefaultork1) - Look in a real email header — find the
DKIM-Signaturesection, then look fors=(selector) andd=(signing domain) - Check your ESP or mailbox settings
Best tool for DKIM: DKIM Analyzer — validates the selector, checks the public key, and confirms whether the signing domain aligns with your From domain.
The 3 most common DKIM problems:
| Problem | What Happens | Fix |
|---|---|---|
| Wrong selector | Lookup returns nothing — even if DKIM is configured correctly | Find the real selector from email headers |
| DNS formatting errors | Key is truncated, split wrong, or pasted with errors | Re-paste the full key as a single TXT record |
| Record exists but provider isn’t signing | DNS looks fine, but no signature on actual emails | Enable DKIM signing in your email provider’s settings |
Why DKIM can pass but DMARC still fails:
This is the single most important concept in this entire guide.
DKIM “pass” alone is not enough. For DMARC to pass via DKIM, the signing domain (d= in the DKIM header) must match your visible From domain.
| Scenario | DKIM Result | DMARC Result |
|---|---|---|
From: [email protected] / DKIM d=example.com |
 Pass + aligned |
DMARC passes |
From: [email protected] / DKIM d=sendgrid.net |
Pass but NOT aligned |
 DMARC fails via DKIM |
🛡️ Step-by-Step — Check DMARC
Where DMARC lives: TXT record at _dmarc.yourdomain.com — not the root domain.
What a valid DMARC record looks like:
At minimum: v=DMARC1; p=none
Common tags:
| Tag | What It Does | Example |
|---|---|---|
v=DMARC1 |
Version (required) | Always DMARC1 |
p= |
Policy — what to do when auth fails | none / quarantine / reject |
rua= |
Where to send aggregate reports | mailto:[email protected] |
ruf= |
Where to send forensic reports | Less common, optional |
adkim= |
DKIM alignment mode | r (relaxed) or s (strict) |
aspf= |
SPF alignment mode | r (relaxed) or s (strict) |
Best tool for DMARC: DMARC Checker — catches missing policies, duplicate records, and malformed tags.
What the three policies actually mean:
| Policy | What Happens | When to Use |
|---|---|---|
p=none |
Monitor only — nothing blocked | Starting out, collecting data |
p=quarantine |
Suspicious mail may go to spam | After confirming all legit senders |
p=reject |
Failing mail gets rejected outright | Full enforcement — strongest protection |
Recommended path: Start with p=none → collect reports → verify every legitimate sender → move to quarantine → later consider reject.
Common DMARC mistakes:
- Multiple DMARC records (only one is allowed)
- Missing the
p=tag entirely (invalid record) - Publishing the record on the root domain instead of
_dmarc. - Setting strict alignment before all senders are properly configured
- Assuming “record exists” means “DMARC is working”
💡 The Part Most Beginners Miss — Alignment Explained
If you only remember one thing from this guide:
DMARC requires alignment, not just pass.
DMARC doesn’t simply ask “did SPF pass?” or “did DKIM pass?” It asks: did SPF or DKIM pass in a way that matches the visible From domain?
SPF alignment example:
- From:
[email protected] - Return-Path:
mailer.sendplatform.com - SPF passes for
mailer.sendplatform.com
SPF passed — but the Return-Path domain doesn’t match example.com, so DMARC doesn’t pass via SPF.
DKIM alignment example:
- From:
[email protected] - DKIM signature validates
- DKIM
d=vendor-mail.com
DKIM passed — but vendor-mail.com doesn’t match example.com, so DMARC doesn’t pass via DKIM.
This is exactly why “everything looks fine but emails go to spam” happens. You see SPF = pass, DKIM = pass, and assume you’re done. But if neither one aligns with your From domain, DMARC fails — and inbox providers treat the message as suspicious.
Authentication-Results. That single line tells you exactly what passed, what failed, and what aligned — all in one place.
🔬 When DNS Looks Perfect But Emails Still Go to Spam — Check the Header
DNS records tell you what should happen. The email header tells you what actually happened.
A domain can look perfect in DNS and still fail because:
- The wrong provider sent the email
- The message used a different Return-Path than expected
- DKIM signing wasn’t enabled on that specific sending stream
- Email forwarding changed the authentication path
- A third-party tool bypassed your intended sending route
What to look for in the raw header:
| Header Field | What It Tells You |
|---|---|
Authentication-Results |
The final verdict — pass/fail for SPF, DKIM, DMARC |
spf=pass or spf=fail |
Whether the sending IP was in your SPF record |
dkim=pass or dkim=fail |
Whether the DKIM signature validated |
dmarc=pass or dmarc=fail |
Whether alignment succeeded |
header.from= |
Your visible From address |
return-path |
Where bounces go (SPF checks this) |
d= in DKIM-Signature |
The domain that signed the message |
Best tool: Email Header Analyser — paste your raw header, get a breakdown of exactly what passed and what failed.
Authentication-Resultsright at the top. Outlook: open the message → File → Properties → Internet Headers.
🧰 Free Workflow — Check Everything Without the Command Line
Here’s the complete order, using free tools:
| Step | Tool | When to Use |
|---|---|---|
| 1. Big picture scan | Email Health Checker | First — when you don’t know what’s broken |
| 2. DMARC check | DMARC Checker | Policy missing, malformed, or suspicious |
| 3. DKIM check | DKIM Analyzer | Selector unclear, signing domain doesn’t align |
| 4. SPF check | SPF Flattening Tool | Too many includes, near the 10-lookup limit |
| 5. Real-world test | Email Header Analyser | DNS looks fine but emails still go to spam |
🚨 Emails Still Going to Spam? 5 Reasons Beyond Authentication
Authentication is just one piece. Even with perfect SPF, DKIM, and DMARC, emails can still miss the inbox:
| Reason | What’s Happening | Fix |
|---|---|---|
| Weak domain/IP reputation | New domain, cold IP, or bad history | Warm up slowly, send to engaged contacts first |
| Forgotten sender path | One tool (CRM, forms, helpdesk) isn’t configured | Audit every service that sends email for you |
| Bad list quality | Sending to invalid, old, or scraped addresses | Clean your list — remove bounces and unengaged |
| Spammy content | Too many links, aggressive language, URL shorteners | Test with mail-tester.com before big sends |
| Promotions ≠ spam | Landing in Promotions tab, not the spam folder | This is classification, not a trust failure — your auth may be fine |
What NOT to do: Don’t set DMARC to p=reject before you’ve confirmed every legitimate sender. Don’t use multiple SPF records. Don’t ignore the 10-lookup limit. Don’t check DNS once and assume it stays correct forever. Don’t skip the email header when troubleshooting.
🔧 Fix Checklist — What to Do When You Find a Problem
| Problem Found | Fix It In This Order |
|---|---|
| SPF missing or failing | Add correct sending services → merge duplicates into one record → remove old includes → watch the 10-lookup limit → flatten if needed |
| DKIM exists but mail isn’t signed | Enable DKIM signing in your provider → confirm the selector → verify the sending stream → send a test and check the header |
| DMARC missing | Start with v=DMARC1; p=none; rua=mailto:[email protected] → monitor → confirm senders → move to quarantine → later reject |
| SPF/DKIM pass but DMARC fails | Check alignment first — From domain vs Return-Path vs DKIM d=. This is almost always the real issue |
| Everything passes but inbox is poor | You’re dealing with reputation, list quality, content, or sending behavior — authentication is necessary but not the whole story |
Quick Hits
| Want This | Do This |
|---|---|
 Fast first check |
→ Email Health Checker |
 Validate DMARC policy |
→ DMARC Checker |
 Verify DKIM selector |
→ DKIM Analyzer |
 Fix SPF lookup limit |
→ SPF Flattening Tool |
 See what actually failed |
→ Email Header Analyser |
 One rule to remember |
→ Don’t check if records exist — check if real messages pass and align |
Records exist. Messages align. Inbox earned — not assumed.
!