Blog · Dmarc
How to Check SPF, DKIM, and DMARC for Any Domain (Step-by-Step)
When you manage email for clients, the question is not whether SPF, DKIM, and DMARC exist. The question is whether they are actually working, and what to do when they are not.
This guide covers how to check all three protocols for any domain using command-line tools and web-based options, plus what the results actually mean.
What Each Protocol Checks
SPF (Sender Policy Framework) verifies which mail servers are authorized to send email for your domain. It works by looking up a TXT DNS record you publish.
DKIM (DomainKeys Identified Mail) verifies a cryptographic signature,证明 the email was not altered in transit. The public key used to verify the signature lives in your DNS.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM by enforcing alignment. It tells receivers what to do when authentication fails.
All three use DNS, so you can check them without sending a single test email.
How to Check SPF
Terminal command:
dig TXT yourdomain.com
On macOS:
nslookup -type=TXT yourdomain.com
A valid SPF record looks like this:
v=spf1 include:_spf.google.com ~all
Breaking it down:
- v=spf1 means this is an SPF record (version 1)
- include:_spf.google.com authorizes Google's servers to send for this domain
- ~all means emails from unauthorized servers should be treated as suspicious
The common mistakes: multiple SPF records for the same domain (breaks everything), too many DNS lookups in the record (the 10-lookup limit), and using ~all when you could be using -all (hard fail, which is what you want once you have confirmed all your sending sources are covered).
How to Check DKIM
DKIM requires finding the selector first. Look at an email header from the sender and locate the dkim-signature field:
dkim-signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
The s=selector1 part tells you which selector to look up. Then query:
dig TXT selector1._domainkey.yourdomain.com
If the record exists and the key parses, DKIM is configured. NXDOMAIN means no DKIM record for that selector.
If you do not see DKIM on every email from a sender, they might be using a different selector for different sending systems. Some domains run multiple DKIM keys.
How to Check DMARC
DMARC records live at _dmarc.yourdomain.com:
dig TXT _dmarc.yourdomain.com
A typical record:
v=DMARC1; p=quarantine; rua=mailto:reports@example.com; ruf=mailto:forensics@example.com; pct=100
What each part does:
- p=quarantine tells receivers to mark failing emails as suspicious instead of accepting them outright
- rua is where aggregate reports go (daily summary of pass/fail counts by receiver)
- ruf is where forensic reports go (detailed info on specific failures)
- pct=100 means the policy applies to every email
The three policy levels:
- none: watch only, take no action
- quarantine: treat suspicious emails as spam
- reject: refuse the email
Most domains start at none, then move to quarantine, then reject once they have confirmed all legitimate sending sources are covered.
Tools That Check All Three at Once
Running three separate dig commands works fine for one domain. For ongoing monitoring across multiple domains and receivers, dedicated tools save time.
MXToolbox offers a free lookup that shows all three records. It is useful for quick one-off checks.
DMARC Analyzer and dmarcian offer lookup tools plus reporting services. Both are US-based.
DMARCFlow monitors SPF, DKIM, and DMARC across multiple domains and receivers on an ongoing basis, tracking changes to records and shifts in authentication results. For practitioners who manage several domains, this matters more than a one-time lookup, since email authentication is not a set-and-forget configuration.
Why Your Results Might Differ Between Receivers
This is the part that trips up most practitioners: SPF and DKIM both pass, but one receiver accepts the email and another marks it as spam.
The most common causes:
DMARC alignment. SPF and DKIM must both pass AND align with the From domain. If you send from a subdomain like mail.example.com but the From address shows example.com, DMARC alignment fails even though SPF and DKIM technically pass. This is the most frequent cause of apparent inconsistencies.
DNS propagation. Changes to DNS records can take up to 48 hours to reach all receivers globally. One receiver might have the updated record; another might still be using a cached version.
Forwarding. Forwarded emails break the authentication chain. The forwarder sends from their own server, which fails SPF for the original sender's domain.
Receiver-specific rules. Some receivers apply their own filtering on top of authentication results. Authentication passing does not guarantee inbox placement.
When one receiver behaves differently, your DMARC aggregate reports show exactly what each receiver sees. Without those reports, you are guessing.
When to Run a Full Authentication Check
Run a full check when:
- Onboarding a new client domain
- After changing mail providers or adding a new sending platform
- When emails start landing in spam without a clear reason
- Before moving to a stricter DMARC policy
- Quarterly for domains you manage long-term
Frequently Asked Questions
Why does SPF pass but the email still fails?
SPF passing means the sending server is authorized. The failure is likely DMARC alignment (the From domain does not match the SPF domain), DKIM issues, or receiver-side filtering unrelated to authentication. Check your DMARC reports.
What if DKIM is missing from email headers?
Either the sender is not using DKIM, or you are looking at a forwarded email where the signature was stripped. Ask the sender if they have DKIM configured and which selector they use.
How often should I check these records?
After any DNS change affecting mail. For ongoing monitoring, set up automated alerts for record changes and subscribe to DMARC aggregate reports.
Can I check SPF/DKIM/DMARC for a domain I do not own?
Yes. All three records are publicly visible in DNS. You do not need ownership to look them up.
---
Verifying SPF, DKIM, and DMARC does not require special access. The DNS records are public. What matters is knowing what to look for, what the results mean, and what to do when they diverge from expectations.
For one-off audits, command-line tools are sufficient. For ongoing monitoring across a domain portfolio, automated tracking of record changes and receiver-level results catches problems before they become deliverability issues.