DKIM Record Lookup
DKIM (DomainKeys Identified Mail) is a cryptographic signature on outgoing email: the sending server signs the message with a private key, and the receiver verifies it against a public key published in DNS. This tool looks up any domain's signing keys, auto-probing 50+ common selectors, and reports key type and length.
Corrections welcome — see our editorial policy.
What is DKIM?
DomainKeys Identified Mail is a cryptographic signature attached to outgoing email. The sending server signs the message body and a chosen set of headers with a private key; the receiving server fetches the matching public key from DNS and verifies the signature. If the signature checks out, the receiver knows the message was authored by someone holding the private key for that domain, and that the signed content hasn't been modified in transit.
That's the part that distinguishes DKIM from SPF: SPF authorises which servers can send for a domain; DKIM proves this specific message was signed by that domain and hasn't been tampered with along the way.
How do DKIM selectors work?
The public key lives at {selector}._domainkey.{domain}. A domain can publish many keys at different selectors — one per sending service, or one per rotation. When Google Workspace adds DKIM, it creates google._domainkey.yourdomain.com. When you add SendGrid, it creates s1._domainkey.yourdomain.com. The selector name is included as the s= tag in the DKIM-Signature header on every signed message, so the receiver always knows which key to fetch.
Why does this tool auto-probe?
Unlike SPF (one TXT record at the domain root) and DMARC (one TXT record at _dmarc.), DKIM keys can be published under any selector name the sender chooses. There's no DNS query you can run to list them — you either need to know the names or guess. This tool probes the most common selectors used by Google Workspace, Microsoft 365, Amazon SES, SendGrid, Mailchimp, Mailgun, HubSpot, Salesforce, Zoho, Postmark, Brevo, Fastmail, Proofpoint, Mimecast, and a long tail of generic patterns (default, k1, dkim, etc.). If your provider uses an unusual selector, supply it explicitly with the second input.
What DKIM key length should you use?
RSA was the only widely-supported key type for many years, with 1024-bit keys as the de-facto standard. NIST SP 800-131A formally deprecated 1024-bit RSA for new use, and Google switched its default to 2048-bit in 2024. Today 2048-bit is the minimum recommendation, with 4096-bit available for security-conscious deployments. The newer Ed25519 keys are much shorter (256 bits) and faster but not yet universally supported by mail servers; expect dual-publishing (RSA + Ed25519) to remain common for years.
Anything 1024-bit and under will be flagged as a warning or error above. The cost of upgrading is trivial — generate a new key, publish at a new selector, switch your sending service to use it, and revoke the old one by emptying its p= value when you're ready.
How do DKIM, SPF, and DMARC work together?
Each on its own answers a different question. SPF says "this IP is allowed to send for this domain." DKIM says "this specific message was signed by this domain and hasn't been altered." DMARC says "if SPF or DKIM authenticated a domain that aligns with the From: header, deliver — otherwise apply this policy." The trio closes the gap that any single one leaves open. The SPF checker and DMARC checker grade those two records; this tool shows what the third leg looks like. The email header analyzer ties the loop together by showing the SPF/DKIM/DMARC results for a specific received message.