If your emails are landing in spam, getting rejected, or showing "unverified sender" warnings, the first thing you should check is your email authentication setup.
That means verifying these three critical records:
- SPF (Sender Policy Framework)
- DKIM (DomainKeys Identified Mail)
- DMARC (Domain-based Message Authentication, Reporting, and Conformance)
These DNS records tell mailbox providers like Gmail, Outlook, and Yahoo whether your domain is actually authorized to send email. If one of them is missing, broken, or too weak, your messages can lose trust fast.
In this free 2026 guide, you'll learn:
- how to check an SPF record
- how to check a DKIM record
- how to check a DMARC record
- why emails still go to spam even when records exist
- the most common email authentication mistakes
- the fastest way to test any domain for deliverability issues
If you manage a business domain, newsletter, support inbox, outreach campaign, SaaS product, or cold email setup, this is one of the most important technical checks you can do.
Quick Answer: How Do You Check SPF, DKIM, and DMARC for a Domain?
To check SPF, DKIM, and DMARC for any domain:
- Look up the domain's DNS TXT records
- Verify that an SPF record exists and is valid
- Verify that a DKIM selector resolves to a valid public key
- Check for a DMARC policy at
_dmarc.yourdomain.com - Confirm the records are not just present, but also properly configured
- If emails still go to spam, analyze a real email header to see what actually passed or failed
The fastest beginner-friendly way is to start with a full domain scan using the Email Health Checker, then drill deeper into specific authentication records if something looks off.
Why SPF, DKIM, and DMARC Matter in 2026
Email providers are stricter than ever.
Modern inbox providers don't just look at your message content — they look at whether your domain has a trustworthy sending setup.
A strong SPF, DKIM, and DMARC configuration helps you:
- Improve inbox placement
- Reduce the risk of email spoofing
- Prevent phishing abuse on your domain
- Lower the chance of landing in spam
- Increase trust with Gmail, Outlook, Yahoo, and business mail gateways
- Build a healthier sender reputation over time
If you send:
- transactional emails
- verification codes
- newsletters
- cold outreach
- support replies
- password reset emails
- SaaS notifications
…then email authentication is not optional anymore.
What Is SPF, DKIM, and DMARC? (Simple Explanation)
Before checking records, it helps to understand what each one actually does.
SPF: Who Is Allowed to Send Email for Your Domain
SPF is a DNS TXT record that lists which mail servers or email services are allowed to send email on behalf of your domain.
For example, if you use:
- Google Workspace
- Microsoft 365
- Mailgun
- SendGrid
- Amazon SES
- Brevo
- Zoho Mail
…those services usually need to be included in your SPF record.
What SPF protects against:
Unauthorized senders pretending to send mail from your domain.
What SPF does not guarantee:
That the visible "From" address fully aligns in a way DMARC accepts.
DKIM: Proves the Email Was Signed
DKIM adds a cryptographic signature to your outgoing email.
When a recipient server gets the message, it checks a public key stored in DNS to confirm:
- the email was signed by an authorized sender
- the message wasn't altered in transit
What DKIM protects against:
Tampering and forged mail that lacks a valid signature.
Important: A DKIM record existing in DNS does not automatically mean DKIM is working correctly in real sends.
DMARC: Tells Mail Providers What to Do If SPF or DKIM Fails
DMARC builds on SPF and DKIM.
It tells receiving servers:
- whether failed mail should be monitored, quarantined, or rejected
- where to send aggregate reports
- whether the authenticated domain aligns with the visible "From" domain
DMARC policy values:
p=none→ monitor onlyp=quarantine→ suspicious mail may go to spamp=reject→ failing mail should be rejected
What DMARC protects against:
Domain spoofing, impersonation, and poor enforcement of authentication.
How to Check SPF, DKIM, and DMARC for Any Domain
Here's the easiest and most practical workflow.
Step 1: Run a Full Email Authentication Check First
Instead of checking records one by one manually, start with a broad domain-level scan.
Use the Email Health Checker to get a fast overview of:
- SPF status
- DKIM presence
- DMARC presence
- MX setup
- basic authentication health
- common risk signals
This is the best first step because it instantly tells you whether the domain is missing obvious pieces before you go deeper.
Why this matters:
A lot of domains fail because of simple issues like no DMARC record, no DKIM, missing MX, or a broken SPF structure.
Step 2: How to Check an SPF Record
If you want to know how to check SPF record settings correctly, don't just ask "does it exist?" — ask whether it is valid, clean, and within limits.
What a valid SPF record looks like
An SPF record usually starts like this:
v=spf1 include:_spf.google.com ~all
What to look for in an SPF record
- It starts with
v=spf1 - There is only one SPF TXT record for the domain
- It includes your current sending providers
- It ends with a sensible policy like:
~all(soft fail)-all(hard fail)
- It does not exceed the 10 DNS lookup limit
Common SPF mistakes
- Publishing multiple SPF records
- Leaving old
include:entries from previous email providers - Using an overly permissive rule like
+all - Exceeding the SPF 10-lookup limit
- Forgetting to update SPF after switching ESPs
Big 2026 SPF problem: the 10-lookup limit
This is one of the most common hidden deliverability killers.
If your SPF record includes too many nested providers, forwarding services, or SaaS tools, it can exceed the allowed DNS lookups and silently fail.
If your SPF is complex, the SPF Flattening Tool can help simplify include chains into explicit IPs so the record stays within limits.
Step 3: How to Check a DKIM Record
If you're searching how to check DKIM record, the main thing to know is:
DKIM is selector-based.
That means you usually need:
- the domain
- the selector used by the sending platform
A DKIM record often lives at something like:
selector1._domainkey.example.com
What to look for in a DKIM record
- The selector resolves successfully
- A TXT record exists
- The public key (
p=) is present - The record is properly formatted
- The key is strong enough
- The platform is actually signing real outgoing mail
Common DKIM mistakes
- Using the wrong selector
- Publishing the record but never enabling DKIM in the mail provider
- Broken TXT formatting in DNS
- Weak or outdated key sizes
- Rotating keys incorrectly
- Assuming "record exists" means "DKIM passes"
If you want a deeper technical inspection of the record itself, use the DKIM Analyzer to inspect key strength, record structure, and possible DKIM configuration issues.
Step 4: How to Check a DMARC Record
If you want to know how to check DMARC record status properly, look for a TXT record at:
_dmarc.example.com
A basic DMARC record looks like:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
What to look for in a DMARC record
- It starts with
v=DMARC1 - It has a policy:
p=nonep=quarantinep=reject
- It ideally includes a reporting address:
rua=mailto:...
- Optional forensic reporting:
ruf=mailto:...
- Alignment settings may be present:
adkim=aspf=
- Optional gradual rollout:
pct=
Common DMARC mistakes
- No DMARC record at all
- Staying at
p=noneforever - No reporting mailbox configured
- Broken record syntax
- Ignoring alignment failures
- Copy-pasting a generic record without understanding it
To validate the record quickly and see whether it is monitoring or actually enforcing, use the DMARC Checker.
Why Emails Still Go to Spam Even If SPF, DKIM, and DMARC Exist
This is one of the most misunderstood parts of email deliverability.
A domain can have SPF, DKIM, and DMARC records present, but emails can still land in spam.
Why?
Because presence is not the same as correct configuration.
Here are common reasons:
- SPF exists, but it exceeds the 10-lookup limit
- SPF passes, but alignment fails
- DKIM record exists, but the actual signature fails
- DKIM breaks after forwarding or rewriting
- DMARC exists, but it stays at
p=none - The domain has a poor reputation
- The sending IP has a poor reputation
- Content triggers spam filters
- Links look suspicious
- Bounce rate is high
- Complaint rate is high
- Reverse DNS is missing or weak
- Sending volume patterns changed suddenly
Important truth:
SPF + DKIM + DMARC are the foundation, not the full deliverability system.
They help mailbox providers trust you, but they don't override bad sender reputation or spammy behavior.
How to Check Why an Email Went to Spam
If your DNS records look fine but a real email still lands in spam, stop looking only at DNS.
You need to inspect the raw email headers.
That's where you'll see what the receiving server actually observed.
Use the Email Header Analyser to inspect:
- SPF pass/fail
- DKIM pass/fail
- DMARC pass/fail
- Authentication-Results
- mail hops / relay path
- alignment clues
- spam-routing hints
This is critical because many people only check DNS records and never test the real delivered message, which is where hidden issues show up.
Best Workflow for Checking Email Authentication (Fastest Method)
If you want the simplest practical workflow in 2026, do it in this order:
- Run a broad scan with Email Health Checker
- Check DMARC policy and enforcement level with DMARC Checker
- Inspect DKIM quality and selector validity with DKIM Analyzer
- Review SPF structure and lookup count with SPF Flattening Tool
- Analyze real email headers with Email Header Analyser if inbox placement still fails
This gives you:
- a DNS-level view
- a policy-level view
- a real-message view
That combination is much more useful than doing only a basic TXT lookup.
Common SPF, DKIM, and DMARC Mistakes to Avoid
These mistakes show up again and again on business domains, SaaS apps, and cold email setups.
SPF mistakes
- Multiple SPF TXT records
- Too many
include:lookups - Old providers still listed
+allor overly loose policy- Not updating SPF after provider changes
DKIM mistakes
- Wrong selector
- Record published but signing disabled
- Broken TXT formatting
- Weak keys
- Not testing with real sent mail
DMARC mistakes
- No DMARC record
p=noneforever- No
rua=reporting address - Ignoring alignment
- Broken syntax
- No move toward enforcement
SPF, DKIM, and DMARC Best Practices for 2026
If you want stronger inbox placement this year, aim for this baseline:
- Publish one clean SPF record only
- Keep SPF under the 10-lookup limit
- Remove old or unused providers from SPF
- Use strong DKIM keys
- Confirm DKIM signs real outgoing mail
- Publish DMARC on every active sending domain
- Start with monitoring, then move toward enforcement
- Collect DMARC reports
- Check alignment, not just pass/fail
- Re-test after DNS or ESP changes
- Review headers when something feels wrong
- Monitor reputation and bounce trends
Who Should Use This Checklist?
This guide is useful if you run:
- a business website
- a SaaS product
- a support mailbox
- a newsletter system
- transactional email
- cold outreach campaigns
- agency-managed client domains
- custom domain email forwarding
- ecommerce notifications
- password reset / verification systems
If email matters to your business, authentication matters too.
Final Thoughts
If you send email from your domain, learning how to check SPF, DKIM, and DMARC is one of the highest-ROI technical skills you can pick up.
It helps you:
- improve inbox placement
- reduce spoofing risk
- diagnose why emails go to spam
- catch hidden DNS mistakes
- build trust with mailbox providers
And the most important takeaway is this:
Having SPF, DKIM, and DMARC records is not enough — they need to be valid, aligned, and tested against real email behavior.
A domain can look "configured" at first glance and still fail in production.
That's why the smartest approach is:
- check the domain
- inspect the records
- validate the policy
- test the actual message
Do that consistently, and you'll catch most email authentication issues before they hurt deliverability.
Frequently Asked Questions (FAQ)
How do I check SPF for a domain?
To check SPF for a domain, look for a DNS TXT record that starts with v=spf1. Make sure there is only one SPF record, it includes your active sending providers, and it does not exceed the 10 DNS lookup limit.
How do I check DKIM for a domain?
To check DKIM, you need the domain and usually the selector used by the sending platform. The DKIM TXT record should contain a valid public key and proper formatting, but you should also confirm that real outgoing emails are actually being signed.
How do I check DMARC for a domain?
To check DMARC, look for a TXT record at _dmarc.yourdomain.com. It should begin with v=DMARC1 and include a policy such as p=none, p=quarantine, or p=reject. A reporting address (rua=) is also strongly recommended.
What is the best SPF DKIM DMARC checker?
The best workflow is not just one single check — it's a combination of:
- domain-level email authentication scanning
- direct DMARC validation
- DKIM record inspection
- SPF structure review
- real email header analysis
That gives you both the DNS view and the real-message view.
Why do emails go to spam even when SPF, DKIM, and DMARC exist?
Because authentication records being present does not guarantee inbox placement. Emails can still go to spam due to:
- alignment failures
- broken DKIM signatures
- weak SPF structure
- poor domain or IP reputation
- spam-triggering content
- high complaint or bounce rates
- non-enforcing DMARC policies
Does DMARC require SPF and DKIM?
DMARC works best when both SPF and DKIM are correctly configured. Technically, DMARC can pass if either SPF or DKIM passes with proper alignment, but relying on both is much stronger and recommended.
What is the SPF 10 lookup limit?
SPF evaluation can only perform up to 10 DNS lookups. If your SPF record exceeds that limit because of too many include: mechanisms, it can fail, which can hurt deliverability.
Should I use p=none or p=reject in DMARC?
If you're just starting, p=none is useful for monitoring. But long-term, staying at p=none forever weakens protection. Once your authentication is stable, most domains should work toward p=quarantine or p=reject.
Is having SPF, DKIM, and DMARC enough for deliverability?
No. These records are essential, but deliverability also depends on:
- domain reputation
- IP reputation
- content quality
- complaint rates
- bounce rates
- sending behavior
- list hygiene
- infrastructure quality
Authentication is the foundation, not the full system.
Your temp mail is ready right now
No signup, no password. A disposable inbox waiting the moment you open the page.
Get My Free Temp Mail →