SPF, DKIM & DMARC Checker
Look up a domain’s DNS records: SPF, DMARC, DKIM, MX, CAA and DNSSEC.
This tool queries public DNS via Cloudflare (1.1.1.1) — it only sends the domain name. No file or content of yours ever leaves your browser.
How do I check if a domain has SPF, DKIM and DMARC set up correctly?
Enter a domain and Docuboxer looks up its MX, SPF, DMARC, DKIM, CAA records and DNSSEC signal in seconds, with a plain-English verdict (ok, warning or problem) for each one. It's free, no signup, no query limits. Unlike every other Docuboxer tool, this one does make a network call: DNS records don't live in your browser, so checking them means asking a public DNS resolver (Cloudflare, over DNS-over-HTTPS). The only thing that leaves your machine is the domain name you type — no file, email or content of yours is ever uploaded anywhere. Use it right after setting up company email to confirm it's wired correctly, while auditing a third-party domain's mail security, or while troubleshooting why messages keep landing in spam.
How to use SPF, DKIM & DMARC Checker
- Type the domain you want to check (e.g. company.com). If you paste a full URL instead, the tool automatically strips it down to just the domain.
- If you're chasing a specific DKIM issue, enter the selector in the optional field — it appears in the DKIM-Signature header of a real email from that domain — or try one of the common presets (default, google, k1, s1, selector1, selector2).
- Click "Check domain" to run the DNS lookups. Within a few seconds you'll see a verdict for each area: MX, SPF, DMARC, DKIM, CAA and DNSSEC.
- Read the raw record and the explanation under each section. Every warning or problem spells out why it matters and, where relevant, what it means in practice — mail landing in spam, or a domain that's spoofable.
- Copy the summary or download the .txt report to attach to a support ticket, hand to your email provider, or keep as audit evidence.
Common use cases
Confirm transactional email won't land in spam
After wiring up SendGrid, Mailgun or Amazon SES to send invoices or notifications, verify the SPF record includes the provider and that DMARC isn't silently undermining those sends.
Audit anti-spoofing posture before a pentest or compliance check
See at a glance whether a domain has DMARC at p=reject, SPF ending in a strict qualifier, and active DKIM — three controls that show up on most email-security checklists and compliance frameworks.
Debug why an email landed in spam
Look up the sending domain to see if SPF is missing, if DMARC is stuck in monitor-only mode (p=none), or if the DKIM selector the provider actually used doesn't match what's published in DNS.
Verify an email provider migration
When moving from Google Workspace to Microsoft 365 (or the other way around), confirm MX records point to the right provider and that SPF wasn't left with stale includes from the old one, which quietly breaks deliverability.
Check who can issue SSL certificates for your domain
Review CAA records to see whether any certificate authority can still issue a certificate in your domain's name, or whether you've already restricted that to one issuer like Let's Encrypt or DigiCert.
Frequently asked questions
Why does this tool call the network when every other Docuboxer tool is fully local?
Because a domain's DNS records don't exist in your browser — they live on public DNS servers. Reading them means asking a resolver, in this case Cloudflare over DNS-over-HTTPS. It's one of the very few Docuboxer tools that make a network request (the Open Graph checker's URL mode is the other), and it only ever sends the domain name — never a file, an email, or any content of yours.
What's the difference between SPF ending in ~all and -all?
~all (softfail) tells receiving servers to flag mail from unauthorized sources as suspicious but usually still deliver it. -all (hardfail) asks them to reject it outright. ~all is a common, reasonable default; -all is stricter but requires a complete, well-maintained SPF record so you don't accidentally block legitimate mail.
Why can't it find my DKIM record when I know it exists?
DKIM is published under a name that includes a "selector" your mail provider chooses (like selector1._domainkey.yourdomain.com), and that selector isn't guessable from outside. If you don't enter it, the tool tries common presets, but if your provider uses something else it will find nothing — that doesn't mean your domain lacks DKIM, only that the wrong selector was queried. Check the DKIM-Signature header of a real email to get the right one.
Do I need DMARC if I already have SPF and DKIM?
It's not required, but without DMARC, SPF and DKIM alone aren't enough: nothing tells receiving servers what to do when a message fails those checks, so spoofing of your domain is still possible. DMARC is the piece that closes the loop, and it also gives you reports (rua) showing who's sending mail as your domain.
What happens if my SPF record goes over the 10 DNS lookup limit?
The SPF standard caps mechanisms that trigger an extra DNS lookup (include, a, mx, ptr, exists, redirect) at 10. Going over that limit means many mail servers can no longer evaluate the record at all (a PermError), and in practice treat the domain as if it had no SPF. It's a common, silent failure that creeps in as third-party integrations pile up over time.
Why does the DNSSEC result say "warning" instead of confirming I don't have it?
The AD flag on a DNS response indicates whether the resolver cryptographically validated that specific query, not whether it walked the domain's entire chain of trust. It's a useful but partial signal, so AD=0 is shown as an inconclusive warning rather than a confirmed failure — DNSSEC is still optional and far from universal, even on well-run domains.