DKIM Checker
Look up a DKIM record by selector and validate the key.
Related Tools
SPF Checker
Check a domain's SPF record. Follows every include and counts the 10-lookup limit.
Use tool →DMARC Checker
Check a domain's DMARC policy. Tags explained in plain English, reporting verified.
Use tool →SPF, DKIM & DMARC Generator
Generate SPF, DKIM, and DMARC DNS records for Google Workspace, Microsoft 365, or custom setups.
Use tool →Email Header Analyzer
Parse raw email or message headers to trace delivery path, authentication, and delays.
Use tool →How to Check a DKIM Record
Type your domain, type the selector, hit Check. The tool queries selector._domainkey.yourdomain.com over HTTPS, straight from your browser to Cloudflare's public DNS resolver, and validates what comes back. It confirms the public key is there and decodes as base64, estimates RSA key size, parses every tag, and flags revoked keys, testing mode, and duplicate records. Keys split across 255-character DNS strings get joined for you, the way verifiers actually read them.
Don't know your selector? Click one of the chips under the selector field, or hit Find my selector and we'll probe 18 names the big providers use. If DKIM passes here, check the other two legs of email authentication with our SPF Checker and DMARC Checker.
How DKIM Signing Actually Works
Your mail server holds a private key. When it sends a message, it hashes the body and a chosen set of headers, signs the hash, and drops the result into a DKIM-Signature header along with two pointers: the domain (d=) and the selector (s=). The receiving server uses those to fetch the public key from DNS, verify the signature, and conclude two things. The message came from a server holding that private key, and nobody changed the signed parts in transit.
DKIM alone says nothing about the From address people actually see, though. That's DMARC's job. DMARC checks whether the d= domain in the signature aligns with the From domain, and an aligned, passing DKIM signature is what keeps your mail deliverable when SPF breaks on forwarded messages. To see how a real message scored on all of this, paste its headers into the Email Header Analyzer.
Why DKIM Keys Live at Weird DNS Names
google._domainkey.example.com looks odd until you see what it buys you. The _domainkey label is a reserved namespace, so keys never collide with real hostnames. The selector in front means one domain can publish as many keys as it wants, which is what makes rotation painless. Publish a new key at a new selector, switch your server to sign with it, and delete the old record once mail in transit has cleared. No downtime, no window where signatures fail.
Selectors also enable delegation. Most ESPs ask you to publish a CNAME at your selector pointing into their DNS, so they can rotate the actual key material without you ever touching your zone again. This tool follows those CNAMEs and shows the chain, so a record served "via CNAME" is expected behavior, not a problem.