Audit all three email auth records, count SPF lookups, find DKIM selectors.
Email gets spoofed and filtered for reasons that hide in three DNS records, and we audit all three in one pass. We walk your SPF record recursively and count the DNS lookups against the hard limit of ten that quietly breaks deliverability once you've onboarded a few SaaS senders. We scan the common DKIM selectors to find your live signing key and gauge its strength. And we read your DMARC policy the way Gmail and Yahoo do before they decide where your mail lands. Every finding comes with the one-line fix, not just a red cross. Run it on your own domain before a provider migration, or on one you're about to start trusting mail from.
Queries run through the PacketNebula lookup service. We log nothing.
The lookup service is not reachable.
In local preproduction, start it with npm run api then . The rest of the site works without it.
Self-test passed: SPF, DMARC and DKIM parsers verified against reference records on load.
What a green audit actually proves
Three passes here mean the DNS side of your email authentication is sound: a published SPF record within its lookup budget, at least one live DKIM key, and a DMARC policy that ties them to your visible From address. That’s the part Gmail and Yahoo check before accepting bulk mail, and the part attackers probe before spoofing a domain. What it can’t prove from out here is that every message you send is actually getting signed, so finish the job by mailing a Gmail address and reading "Show original": you want SPF, DKIM and DMARC all showing PASS on a real message. The background on how the three records cooperate is in our email authentication guide.
The two checks that actually fail: SPF lookups and DKIM selectors
The audit resolves your SPF record the way a receiver does, following every include and redirect recursively, and counts the DNS lookups against the hard limit of 10 from RFC 7208. This is the failure nobody sees coming. Every tool you onboard tells you to "just add include:spf.vendor.com", each include hides two or three more inside itself, and one morning mail starts failing with permerror while every individual record still looks perfectly fine. The counter shows you the whole tree, so you’re arguing about which vendor to drop from data rather than from memory.
DKIM has no index: keys sit at selector._domainkey.domain and nothing in DNS lists which selectors exist. The scan probes the names real providers use (google, selector1/selector2 for Microsoft 365, k1 for Mailchimp, s1/s2 for SendGrid, fm1-fm3 for Fastmail, and friends) plus anything you type in the custom field. For each hit it checks the key is actually present and estimates its strength: 1024-bit keys still verify, but they’re overdue for rotation, 2048-bit is the standard. An empty p= tag means a revoked key, which is worth knowing before you wonder why signatures fail.
Reading the DMARC verdict like a receiver
The policy tag is the headline: none observes, quarantine demotes, reject refuses. But the audit reads the rest the way Gmail does. No rua address means you’re flying blind with no aggregate reports. A pct below 100 means the policy only applies to a sample of failing mail, fine mid-rollout, odd as a permanent state. A missing subdomain policy (sp=) means subdomains inherit the main policy, which is usually what you want but surprises teams who thought newsletter.domain.com was exempt. Each finding comes with its one-line fix; the records themselves you can inspect raw with the DNS lookup tool.
The lookup limit is where most audits fail, so here’s the fix rather than just the diagnosis. Every include costs you at least one DNS lookup and often several, because the included record has includes of its own, and past ten the whole SPF record returns permerror. Receivers then treat SPF as broken rather than as a soft fail. Start by removing services you no longer send from, which is usually two or three of them. If you’re still over after that, flatten the worst offender into explicit ip4 ranges and set yourself a reminder to re-check it, because those ranges do change.
Frequently asked questions
Why does the tool say my SPF record uses too many DNS lookups?
RFC 7208 caps SPF evaluation at 10 DNS lookups, counting every include, a, mx, exists and redirect, recursively through nested includes. Past the limit, receivers return permerror and may treat your mail as unauthenticated. The fix is pruning dead includes, replacing includes with ip4/ip6 blocks where the provider publishes stable ranges, or flattening the record.
The DKIM scan found nothing. Does that mean DKIM is off?
Not necessarily. DKIM keys live at selector._domainkey.yourdomain, and the selector name is chosen by your mail provider; this tool probes a list of common ones plus whatever you type. If your provider uses a custom selector, check its admin console (or a received message's DKIM-Signature header, the s= tag names the selector) and test it in the custom field.
Is p=none a failure?
It’s a phase. p=none means receivers check alignment and send you reports but deliver mail normally, which is exactly right for the first weeks of a rollout. It becomes a finding when a domain stays there forever: you get the visibility but none of the protection, and Gmail/Yahoo bulk-sender rules only require none or better, so attackers exploit domains parked at none.
What does the alignment setting (aspf/adkim) change?
Whether a pass on a subdomain counts for the parent. Relaxed alignment (the default) lets mail.yourdomain.com satisfy DMARC for yourdomain.com; strict requires an exact match. Most organizations run relaxed; strict is for tightly controlled domains where any subdomain sending mail would itself be suspicious.
Can I run this check on a domain I don’t own?
Yes, the records are public DNS by design; that’s how every receiving mail server in the world evaluates them. Checking a partner or a phishing-target domain before trusting mail from it’s a legitimate and common use.