DKIM Record Checker
Look up the DKIM key at selector._domainkey for any domain: follows CNAMEs, reads RSA key size and flags t=y or revoked keys. Free, runs in your browser.
Leave the selector empty to try the 23 selectors that common mail services use. Not sure which one you have? Open a message you sent, find the s= tag in its DKIM-Signature header, or paste the headers into the email header analyzer.
Your query is sent only to the resolver shown; this site keeps no logs. Copy link to this result
What this checks
DNSVerdict's DKIM checker looks up the public key a domain publishes at selector._domainkey.domain, follows any CNAME, and validates the record against RFC 6376. It decodes the RSA key size and flags revoked keys, t=y testing mode, weak or unsupported hash algorithms and malformed tags. Leave the selector empty to try the common selectors that mail providers use.
A DKIM record is a public key published in DNS at <selector>._domainkey.<domain>. Your mail service signs each outgoing message with the matching private key and puts the selector in the s= tag of the DKIM-Signature header. Receivers fetch the key at that name and verify the signature (RFC 6376 §3.6.2.1). This tool does the same lookup in your browser, so it shows what a receiving server would see.
The record is a list of tag=value pairs (RFC 6376 §3.6.1). p= holds the base64 public key and is required; an empty p= means the key was revoked, and every signature using it fails. k= is the key type (rsa by default, or ed25519 under RFC 8463), h= limits the hash algorithms, s= the service type, and t= carries flags: t=y means the domain is only testing DKIM, and t=s means the signing identity must match the domain exactly. If v= is present it must be DKIM1 and come first.
Many providers do not ask you to paste a key. Microsoft 365 and SendGrid, for example, have you publish a CNAME at the selector name that points to a key they manage and rotate. The tool follows the CNAME chain (up to 5 hops, RFC 1034 §3.6.2) and shows every step. A 2048-bit key does not fit in one 255-byte DNS string, so it is stored as several strings that receivers must join without adding anything (RFC 6376 §3.6.2.2). The resolver joins them before this tool sees them.
Key size is decoded from the public key itself. RSA keys under 1024 bits fail: verifiers must not treat their signatures as valid (RFC 8301 §3.2). A 1024-bit key still works but only meets the minimum, and RFC 8301 recommends at least 2048 bits, so it is reported as a warning. Ed25519 keys are valid and short, but not every receiver verifies them yet, so RFC 8463 advises signing with RSA as well during the transition. See the DKIM key length guide for how to rotate to a longer key.
If you leave the selector empty, the tool tries every selector that the mail providers in our data document (Google Workspace uses google, Microsoft 365 uses selector1 and selector2, and so on) and reports which ones exist. That cannot prove DKIM is missing, because the selector can be any label chosen by whoever signs your mail. The reliable way is to read it from the s= tag of a real message's DKIM-Signature header. Some domains answer every selector name with the same record (a DNS wildcard); the tool tests for that and tells you when results may be meaningless.
The same check in a terminal. dig google._domainkey.example.com TXT +short prints the record; use your own selector in place of google. If the selector is a CNAME, as at Microsoft 365, dig selector1._domainkey.example.com CNAME +short shows the target, and the same dig on that target shows the key. A healthy record looks like v=DKIM1; k=rsa; p=MIIBIjANBgkq and so on. As a size check, the p= value of a 2048-bit RSA key is about 392 base64 characters and that of a 1024-bit key about 216.
Common mistakes. Guessing the selector instead of reading s= from a real message; pasting quotes or line breaks into p= at a DNS host that does not split long values for you; leaving t=y in place after testing; copying a CNAME target with the domain name appended twice; and publishing a new key under the old selector, which breaks messages signed with the old key while caches still hold it. Rotate by publishing a new selector first. The tool accepts a bare selector or a full record name such as google._domainkey.example.com. See how DKIM works and how to publish it for the full procedure.
If it fails
- No record at the selector: check the spelling against the s= tag of a real DKIM-Signature, then publish the record your mail service shows in its setup page ([how to publish DKIM](/guide/setup-dkim/)).
- Key revoked or not a key record: the p= tag is empty or missing. Publish the current key your provider gives you, or switch signing to a selector that has a key.
- Key too short (under 1024 bits) or only 1024: generate a 2048-bit key in your mail service, publish it under a new selector and switch signing to it (see the DKIM key length guide).
- Testing flag t=y: remove it once messages sign correctly so receivers treat failures as real.
- CNAME dangling or too long: the provider-managed key is not published at the target. Re-copy the CNAME value from the provider's setup page, with no extra dot or domain suffix added by your DNS host.
FAQ
What is a DKIM selector and where do I find mine?
The selector is a label that lets one domain publish several DKIM keys, at <selector>._domainkey.<domain> (RFC 6376 §3.1). Your mail service picks it. Find it in the s= tag of the DKIM-Signature header of any message you sent, or leave the field empty to try the common ones.
Is a 1024-bit DKIM key still OK?
A 1024-bit key still works, but only just. RFC 8301 §3.2 makes 1024 bits the minimum size a verifier may accept, says signers should use at least 2048, and treats keys under 1024 bits as invalid. DNSVerdict reports a 1024-bit key as a warning. Rotate to 2048 bits under a new selector when your DNS host and mail service allow it, then retire the old selector.
What does an empty p= mean in a DKIM record?
An empty p= tag means the key was revoked on purpose (RFC 6376 §3.6.1). Every signature made with that selector then fails DKIM verification. If you did not revoke it, publish a new key for the selector or switch your mail service to a selector that has a valid key. DNSVerdict also checks whether a random selector gives the same answer, because a wildcard record can look like a revoked key.
Why does a Microsoft 365 or SendGrid selector show a CNAME and not a TXT record?
These services keep the key on their own DNS and rotate it for you, so you publish a CNAME at the selector name that points to it, the way any DNS name can be an alias for another. The tool follows the CNAME chain and checks the key at the end, which is what receivers do, since their resolvers follow the chain too.