Free DKIM Record Checker & Lookup
Enter a domain and selector to look up the public DKIM key, identify record problems, and connect the DNS result to a real-message test.
What is a DKIM record?
A DKIM record publishes the public key a receiver uses to verify a message signature. Each key lives at a selector-specific DNS name. A public lookup can validate that record, while a real-message test is still required to prove that the production path signed the message and that the signature passed at the receiver.
How to read your DKIM result
| Result | What it means | What to do |
|---|---|---|
| Usable public key | The exact selector name returns a DKIM record with a readable public key. | Send a new production message and confirm that the receiver records dkim=pass for the same d= domain and s= selector. |
| No record found | DNS returned no usable record at the selector and signing-domain combination entered. | Confirm d= and s= from a real message or the provider, then check authoritative DNS before changing anything. |
| Malformed or incomplete | The TXT value cannot be interpreted as the public key the sender expects. | Compare it byte-for-byte with the provider value, remove accidental quotes or line breaks, publish the correction, and wait for TTL. |
| Empty p= value | The selector is revoked and no longer supplies a public key for verification. | Stop signing with that key or activate the intended replacement selector before retesting. |
| DNS valid, message fails | The record exists, but the receiver could not verify the signature on the tested message. | Check the exact message path, d= and s= values, body-hash result, post-signing modifications, and DMARC alignment. |
How to run an exact DKIM lookup
Start with a message sent through the production path you need to verify. In its DKIM-Signature header, copy the d= signing domain and s= selector. The checker queries selector._domainkey.signing-domain. A domain-only scan can try common selectors, but DNS cannot enumerate every selector reliably.
If the result conflicts with a provider dashboard, query the authoritative nameserver and compare the exact owner name and value. Common causes are the wrong selector, the root domain being used instead of the signing domain, a provider CNAME pointing to an inactive target, or a record that has not reached the authoritative zone.
What this checker can prove
This checker proves what public DNS returns for one selector and whether the record contains a usable key. It cannot prove that all sending systems sign, that a receiver accepted a particular signature, or that DKIM aligns for DMARC. Those answers require the original headers of a newly delivered message.
Verify DKIM on a real email
Send the same message type through every important production path, preserve the receiver's original source, and read a trusted Authentication-Results header. A dkim=none result normally means that path did not sign. A dkim=fail result requires the recorded reason, selector lookup, and any post-signing content changes. A pass still needs alignment: compare the DKIM d= domain with the visible From domain using the DMARC checker and the message result together.
Related DKIM checks and repairs
Email authentication knowledge base
The tags you'll find inside a DKIM record and what each one means.
- v
- The version tag specifies DKIM’s version, consistently required to be 1.
- p
- The public key tag, a character string created in DKIM setup, must not be left empty to remain valid.
- t
- This tag enumerates flags as a colon-separated sequence, with “y” and “s” as defined flags; any undefined flags should be disregarded.
- s
- This tag details service types relevant to the record. Absent or unrecognized service types must be overlooked by receiving servers.
- h
- This tag specifies permitted hash algorithms, defaulting to allow all. Receivers should ignore unknown algorithms, with the sender determining the list’s entries.
- n
- This tag serves as an optional note field for administrators, recommended for use only when needed.