PacketNebula

SPF / DKIM / DMARC Checker

Audit all three email auth records, count SPF lookups, find DKIM selectors.

This SPF, DKIM and DMARC checker audits all three email authentication records for a domain in one pass. It walks your SPF record recursively and counts the DNS lookups against the limit of ten that quietly breaks deliverability, scans the common DKIM selectors for a live key, and reads your DMARC policy the way Gmail does. Every finding comes with the fix. Run it on your own domain, or on one you're about to trust mail from.

Queries run through the PacketNebula lookup service. We log nothing.

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 is the part Gmail and Yahoo check before accepting bulk mail, and the part attackers probe before spoofing a domain. What it cannot prove from outside is that every message you send is actually 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 SPF lookup counter, explained

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 mode nobody sees coming: each SaaS tool you onboard says "just add include:spf.vendor.com", each include hides two or three more inside, and one day mail starts soft-failing with permerror while every individual record looks fine. The counter shows the whole tree, so the conversation about which vendor to flatten or drop starts from data.

How the DKIM scan works

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 are due 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 are 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.

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 is 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 do not own?

Yes, the records are public DNS by design; that is how every receiving mail server in the world evaluates them. Checking a partner or a phishing-target domain before trusting mail from it is a legitimate and common use.