SPF/DKIM/DMARC Record Checker
Look up SPF, DMARC, and DKIM records for any domain in real time and diagnose your anti-spoofing email authentication setup.
Diagnosing the DNS records that guard against spoofing
Enter a domain and this tool queries its SPF, DKIM and DMARC records on the spot, reporting how far its defences against spoofed mail have been set up. It lets you establish whether your domain can be impersonated by a third party, and whether the mail you send will be trusted by those who receive it.
**The three have distinct roles, and no one of them suffices alone.** SPF declares which servers may send on the domain's behalf, and DKIM guarantees by signature that the message has not been altered. **DMARC then instructs the receiving side what to do with mail that fails those checks.** This is the crux: **with SPF and DKIM in place but no DMARC, what becomes of a spoofed message that fails the checks is left entirely to the recipient's discretion.** Many domains leave DMARC at `p=none`, which means "send me the reports but reject nothing" — a stage on the way rather than a defence in place.
How to use it
- Enter the domain to examine Give the domain alone, in the form `example.com`.
- Review what SPF contains **Look at the list of permitted senders and at the final qualifier, whether `~all` or `-all`.**
- Read the DMARC policy **At `p=none`, nothing is being rejected yet.**
- Add whatever records are missing The diagnosis gives you what you need to decide what to add to your DNS.
Tips for getting more out of it
- The standard order is SPF, then DKIM, then DMARC. Set up SPF and DKIM first, and use DMARC last to clarify instructions for receiving servers.
- Start DMARC with p=none rather than p=reject immediately. Collect reports first to identify every legitimate sending source before tightening the policy step by step.
- Domains with many SPF includes can hit the "10 DNS lookup / 255 character" limit and cause lookup failures, so periodically clean up unnecessary includes.
- This tool only tries common DKIM selectors, so a "not found" result may simply mean a different selector is actually in use.
- Major receivers like Gmail and Outlook have required SPF, DKIM, and DMARC for bulk senders since 2024, so domains sending newsletters should check this setup first.
Where it comes in useful
Checking your own domain's defences
**Spoofing falls hardest on the domains that have taken no measures.**
Investigating why your mail is treated as spam
A fault in SPF or DKIM is the first thing to suspect when messages fail to arrive.
Confirming after adding a sending service
**Once you start using a new delivery service, check that you have not forgotten to add it to SPF.**
Examining a correspondent's domain
It gives you material for judging whether a message you received is genuine.
Terms in email authentication
- SPF
- The DNS record **listing the servers permitted to send in the domain's name.** A trailing `-all` means anything unlisted is to be refused.
- DKIM
- A digital signature added on sending. **It lets the recipient confirm with a public key that neither body nor headers were rewritten in transit.**
- DMARC
- The record **instructing the receiving side what to do with mail that fails the SPF and DKIM checks.**
- P=none
- A DMARC policy meaning **reports are wanted but nothing is rejected or quarantined.** It is the setting for the early stage of adoption.
- P=quarantine and p=reject
- These instruct the recipient to set the message aside as spam, or to refuse it outright. **Reaching one of these is the goal of the exercise.**
- Selector
- The name stating where in DNS the DKIM public key was placed. It is referenced in the form `selector._domainkey.example.com`.
Frequently Asked Questions
Side Note — How the three pillars of anti-spoofing email defense came to be
SPF, DKIM, and DMARC each emerged at different times for different reasons. SPF, which appeared first around 2003, declares which IP addresses are allowed to send mail using a given domain name, and it spread as a countermeasure against spammers forging sender addresses. However, SPF is weak against forwarding: when mail is forwarded, the sending IP changes and authentication breaks.
DKIM (standardized around 2007) addressed that weakness. Rather than judging by IP address like SPF, it attaches a digital signature to part of the message body and headers, which the receiver verifies against a public key published in DNS — so authentication still passes after forwarding as long as the signature itself remains intact.
Still, SPF and DKIM could only detect that authentication had failed; what to do about it — deliver, mark as spam, or reject — was left entirely to the receiving server. DMARC, standardized in 2012, unified these receiver-side instructions. It also added a reporting mechanism (rua=) that sends authentication results back to the sending domain's administrators, enabling continuous monitoring for abuse of one's own domain.
When Google and Yahoo effectively required SPF, DKIM, and DMARC for bulk senders (5,000+ messages per day) in 2024, these three pillars became essential knowledge not just for large enterprises but for any organization sending newsletters or system notification emails.