Home/DKIM Record Lookup
[ E.2 — DKIM ]

DKIM Record Lookup

Look up DKIM signing keys for any domain — auto-probes 50+ common selectors or checks a specific one. See key type, key length, and configuration warnings.

Last reviewed: May 2026

// look up a domain
Leave the selector blank to auto-probe common selectors (Google, Microsoft 365, SendGrid, Mailchimp, SES, HubSpot, and more). Reads {selector}._domainkey.{domain} TXT records via Cloudflare DoH.

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 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 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.

Key length matters

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.

DKIM + SPF + DMARC, 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.