Processed on our server. Your input is sent to our server to produce the result. Uploaded files are not kept, and nothing is sold or shared; our privacy policy lists what is logged.
Check SPF, DKIM and DMARC Records for Any Domain
The Tools Kit’s free DMARC / SPF Checker looks up the three DNS records that decide whether email from a domain is trusted: the SPF record at the domain itself, the DMARC record at _dmarc. plus the domain, and the DKIM key for the selector you enter. All three lookups run at once, and the full text of every record found is shown so you can read exactly what the domain publishes.
Each result is one of three states: record found, no record found, or lookup did not complete. That last state matters. A query that fails is never reported as a missing record, because believing you have no SPF record when you do can lead you to publish a second one, which breaks SPF entirely. If you want to see every TXT, MX or other record on the domain rather than just these three, use the DNS lookup tool.
How to Use the DMARC / SPF Checker
- 1
Enter the domain
Type the domain you send email from, such as example.com, in the Domain box. A pasted URL is fine: the http:// or https:// prefix and any path after the domain are removed for you.
- 2
Set the DKIM selector
The DKIM Selector box starts as "default". Replace it with the selector your email provider uses, such as google or selector1, or clear it to skip the DKIM lookup (the DKIM row then simply shows no record found).
- 3
Check the records
Click Check Records or press Enter. The SPF, DMARC and DKIM lookups run at the same time and usually return in a second or two.
- 4
Read each result
Each record type shows found, not found, or lookup did not complete, with the full text of any matching record underneath so you can review its contents.
The lookups are made from our server through Google Public DNS (8.8.8.8), so the results reflect what the public internet sees rather than your local network or your computer’s DNS cache. Answers may be cached on our side for a short time, so a just-published record can take a few minutes to show up.
How SPF, DKIM and DMARC Work Together
SPF (RFC 7208) is a TXT record at the domain, such as v=spf1 include:_spf.google.com ~all, listing the servers allowed to send for it. A receiving server compares the connecting IP address with that list. You can check which address and network a server belongs to with the IP address checker, and confirm its hostname with a reverse DNS lookup, which many mail receivers also run.
DKIM (RFC 6376) signs each outgoing message with a private key. The matching public key lives in DNS at selector._domainkey.example.com, typically as v=DKIM1; k=rsa; p= followed by the key. Because the selector is part of the name, you must know it before you can look the key up, which is why this checker asks for one.
DMARC (RFC 7489) sits on top of both. It passes a message only when SPF or DKIM passes and the domain it checked matches the domain in the visible From address, a rule called alignment. The record then tells receivers what to do with mail that fails and where to send reports. Since 2024, Gmail and Yahoo require bulk senders to have SPF, DKIM and a DMARC record in place, so all three now affect deliverability directly.
Reading an SPF Record
The checker shows the raw SPF record but does not parse or score it, so it helps to know what each part does. Mechanisms are checked left to right, and the first match decides the result.
| Part | What it does |
|---|---|
v=spf1 | Marks the TXT record as SPF; it must come first |
ip4: / ip6: | Authorizes a specific address or range |
include: | Pulls in another domain’s SPF record, such as your email provider’s |
a / mx | Authorizes the addresses of the domain’s A or MX records |
-all | Hard fail: anything not listed is not authorized |
~all | Soft fail: anything not listed is suspicious but not rejected outright |
?all / +all | Neutral, or allow everyone; +all defeats the purpose of SPF |
Two rules cause most SPF failures. A domain may publish only one SPF record, and evaluating it may trigger no more than 10 DNS lookups in total, counting every include, a, mx, exists and redirect, including those nested inside included records. Break either rule and receivers return a permanent error. If the checker lists two SPF records, merge them into one.
Reading a DMARC Record and Choosing a Policy
A typical DMARC record looks like v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r. The p tag is the policy: none only monitors, quarantine asks receivers to send failing mail to spam, and reject asks them to refuse it. The sp tag sets a separate policy for subdomains, pct applies the policy to a percentage of failing mail, and adkim and aspf choose relaxed (r) or strict (s) alignment.
The safe rollout is to publish p=none with a rua address, read the aggregate reports for a few weeks, fix any legitimate senders that fail, then tighten to quarantine and finally reject. Note that the checker queries _dmarc on exactly the name you type; a subdomain without its own record inherits the parent domain’s policy, so check the parent too.
Authentication is one half of email hygiene; a valid recipient list is the other. Before a campaign, the email validator checks address format and whether the recipient domain has MX records.
Common uses
- Confirming SPF, DKIM and DMARC after setting up Google Workspace, Microsoft 365 or a new email service
- Finding out why messages from your domain are landing in spam
- Checking that a new DKIM selector is live after a key rotation
- Reviewing a client’s or vendor’s domain before a mail migration
- Spotting a duplicate SPF record or a DMARC policy still stuck at p=none
A full domain health check often covers more than email. Look up registration and expiry details with the WHOIS lookup, confirm the HTTPS certificate with the SSL certificate checker, and review the website’s protections with the security headers checker. You will find these and more in the security tools collection.
Email authentication terms explained
| Term | What it means |
|---|---|
| SPF | Sender Policy Framework: a TXT record at the domain that lists the servers allowed to send mail for it |
| DKIM | DomainKeys Identified Mail: a public key in DNS that receivers use to verify a cryptographic signature on each message |
| DMARC | A policy at _dmarc.<domain> telling receivers what to do when SPF and DKIM fail to align with the From domain, and where to send reports |
| Selector | The label before ._domainkey in a DKIM record name; it lets one domain publish several DKIM keys |
| Alignment | DMARC’s requirement that the domain checked by SPF or DKIM matches the domain in the visible From address |
| permerror | A permanent SPF error, caused for example by two SPF records or more than 10 DNS-querying mechanisms |
| rua / ruf | DMARC tags giving the addresses that receive aggregate (rua) and failure (ruf) reports |
Frequently Asked Questions
Enter your domain and click Check Records. The tool looks up the TXT record at _dmarc.yourdomain and shows any record that starts with v=DMARC1. If nothing is published there, it reports that no DMARC record was found.
This checker confirms whether a TXT record starting with v=spf1 is published at the domain and shows its full text. It does not validate the syntax or count DNS lookups, so read the record yourself: there should be exactly one, it should end in an all mechanism such as ~all or -all, and it should stay within the 10-lookup limit.
The selector depends on your email provider. Google Workspace typically uses google, Microsoft 365 uses selector1 and selector2, and many hosts use default or k1. You can also open a message you sent, view its headers, and find the s= value in the DKIM-Signature header.
DKIM keys are published under a selector, so the lookup only finds a key if you enter the exact selector your provider signs with. A not found result for the default selector usually means your provider uses a different one, not that DKIM is missing.
SPF lists the servers allowed to send mail for a domain. DKIM adds a cryptographic signature that receivers verify with a public key published in DNS. DMARC ties the two to the visible From address and tells receivers whether to accept, quarantine or reject mail that fails.
The DNS query itself failed or was refused, so the tool cannot tell whether a record exists. It is reported separately from a missing record on purpose, so you do not publish a duplicate SPF record by mistake. Wait a moment and check again.
No. A domain must publish exactly one SPF record. Two or more records starting with v=spf1 cause a permanent error at receiving servers. If the checker lists more than one SPF record, merge them into a single record.
It looks up _dmarc on exactly the name you enter. If you check a subdomain such as mail.example.com and it has no record of its own, receivers fall back to the policy at _dmarc.example.com, so check the parent domain as well.
The lookups run on The Tools Kit server through Google Public DNS at 8.8.8.8. Answers can be cached for a short time, so a record you just published may take a few minutes, or longer if the old record had a long TTL, before it appears.
The checker is free and needs no account, but DNS lookups share a per-minute rate limit to keep the service available. Each check uses up to three lookups, so if you run many checks in a row, some may show as not completed until the limit resets.
Start with p=none and a rua address so you receive aggregate reports without affecting delivery. Once the reports show that all of your legitimate mail passes SPF or DKIM with alignment, move to p=quarantine and then p=reject.
Reviewed by Raja Jahangir · Last reviewed: October 7, 2026
How do you check a domain's SPF, DKIM, and DMARC records?
To check email authentication, enter the domain and a DKIM selector (the default is "default"). Three TXT lookups run through Google's 8.8.8.8 resolver: the bare domain for a record starting v=spf1, _dmarc.domain for v=DMARC1, and selector._domainkey.domain for DKIM. Each record found is shown in full; missing ones are flagged.
What DKIM selector should you enter?
The DKIM selector is the label before ._domainkey in the DNS record name, and it depends on who sends the mail. Google Workspace typically uses "google", Microsoft 365 uses "selector1" and "selector2", and many providers use "default" or "k1". Find it in a received message's DKIM-Signature header after "s=".