SPF, DKIM & DMARC Checker
Check a domain's email authentication — SPF lookup count, DMARC policy and DKIM keys — and generate correct records
DNS records are public. Lookups go from your browser to Cloudflare's 1.1.1.1 DNS-over-HTTPS service (Google's as a fallback) — only the domain names are sent, nothing passes through ToolNinja.
Was the SPF, DKIM & DMARC Checker helpful?
About this tool
The SPF, DKIM & DMARC Checker looks up a domain's email authentication records and explains what receivers will do with them. Since November 2025 Gmail rejects non-compliant bulk mail outright, and Yahoo and Outlook have similar rules: SPF and DKIM must pass, and a DMARC record (p=none is enough to start) must be published. The SPF check walks every include:, a, mx, exists and redirect the way receivers do and counts the DNS lookups against RFC 7208's limit of 10 — the most common hidden failure, which shows up as a PermError (550 5.7.24 at Microsoft 365) and fails SPF for all your mail. It also flags +all, ?all, deprecated ptr, multiple SPF records, includes that point nowhere and too many void lookups. The DMARC check reads the policy, reporting addresses and alignment, including records inherited from the organisational domain. The DKIM check tries the common selectors (Google, Microsoft 365, Mailchimp, SendGrid and others, plus any you enter) and reports the RSA key size. The generators build an SPF record from the services you send with and a DMARC record with the policy you choose. Lookups go from your browser to Cloudflare's public DNS-over-HTTPS resolver (Google's as a fallback); only domain names are sent.
When to use it
- →Finding out why mail lands in spam or bounces with 550 5.7.26, 5.7.24 or "SPF permerror"
- →Meeting Gmail, Yahoo and Outlook bulk-sender requirements
- →Adding a new sending service (a CRM, newsletter or helpdesk) without breaking the 10-lookup limit
- →Moving DMARC from p=none to quarantine or reject with confidence
- →Checking a client's or new employer's domain setup in a minute
Tips
- ◆Each include: costs one lookup plus every lookup inside it — a single vendor include can use three or four. The include tree shows the real cost.
- ◆ip4: and ip6: cost no lookups, but replacing a vendor's include with its current IPs breaks silently when the vendor changes them.
- ◆Publish exactly one SPF record per domain. Two v=spf1 records are a PermError even if both are valid.
- ◆DKIM selectors can't be listed from DNS. Find yours in the s= tag of the DKIM-Signature header of an email you sent.
Frequently asked questions
What does "SPF PermError: too many DNS lookups" mean?
SPF evaluation may trigger at most 10 DNS lookups (include, a, mx, ptr, exists and redirect each count, recursively). Beyond that the receiver stops and returns PermError, which DMARC treats as a failure for every message. Remove includes for services you no longer use, or move rarely changing senders to ip4:/ip6: ranges.
Is p=none good enough?
It satisfies the bulk-sender requirement to publish DMARC, and it's the right start because nothing is blocked while you read the reports (rua=). But it doesn't stop spoofing. Once the reports show your legitimate mail passing, move to p=quarantine and then p=reject.
Why does my DKIM key show as 1024 bits?
Many older setups used 1024-bit RSA keys. They still verify, but 2048-bit is the current recommendation. Most providers let you rotate to a 2048-bit key by publishing a new selector and switching signing over.
Is my domain sent to ToolNinja?
No. The DNS queries go straight from your browser to Cloudflare's 1.1.1.1 (or Google's 8.8.8.8 as a fallback) over HTTPS, and they only contain the record names being looked up — information that is public anyway.
ToolNinja