SPF, DKIM and DMARC
SPF, DKIM and DMARC answer three different questions about an email, and none of them alone proves the message is legitimate: SPF asks whether the sending server is allowed to speak for the domain, DKIM asks whether the content was signed with a key only the domain owner holds, and DMARC ties both answers to a policy that tells the recipient what to do when they fail.
Each include counts as a separate lookup within RFC 7208's limit of 10; this record is far from the cap, but it ends in ~all, so unauthorized mail still gets through, just flagged.
A real 2048-bit RSA key, base64-encoded inside the record, takes up 392 characters in that format; below 1024 bits the key is considered weak.
p=reject is DMARC's maximum protection level; without the rua tag, the domain would have zero visibility into who is trying to forge messages under its name.
SPF authorizes IPs/servers to send for the domain. DKIM signs each message with a cryptographic key, proving it wasn't altered and came from the domain. DMARC defines what to do when SPF or DKIM fail (none, quarantine or reject) and generates reports. The three complement each other: SPF and DKIM authenticate, DMARC enforces the policy and provides visibility.
At most 10, a hard limit set by RFC 7208; mechanisms like include, a, mx, ptr, exists and redirect each count as one lookup, and going over the limit causes a PermError that gets the whole SPF record ignored.
Because SPF validates the IP of the server that made the final delivery, and once a message passes through forwarding that IP is no longer the original sender's; DKIM does not have this problem because its signature travels inside the message itself.
p=none only monitors and blocks nothing, useful for gathering reports before tightening the policy; p=quarantine sends suspicious messages to spam; p=reject outright rejects any message that fails alignment, the maximum protection.
Yes, for full protection: DMARC depends on alignment with SPF or DKIM to work at all, and without a DMARC record nobody enforces what SPF and DKIM already validated; since 2024, Google and Yahoo require at least a DMARC record, even p=none, from bulk senders.
The tool queries the TXT records for SPF (on the domain), DMARC (at _dmarc) and, if you provide the selector, DKIM. Each record is validated and gets a diagnosis with risks and fixes.
For safety, the browser queries the TXT records directly on a public resolver (Cloudflare) over DNS-over-HTTPS, passing only the name, the J-Kit server is never an intermediary, avoiding SSRF. All record analysis runs locally.