Find the DKIM keys published on any domain. DKIM selectors cannot be enumerated from outside, so this probes the 32 selectors the major providers use and tells you plainly what that does and does not prove.
Type a domain. This probes 32 of the DKIM selectors used by Google, Microsoft, Zoho, SendGrid, Mailchimp, Brevo, Postmark, HubSpot, Mimecast and others, and reports which ones returned a key. It also reads SPF, DMARC and MX for context. Runs against Cloudflare's public resolver. Nothing is stored, nothing is sent to us.
SPF and DMARC live at predictable names. SPF sits at your domain's apex, DMARC at _dmarc.yourdomain.com. Anyone can query them without knowing anything about your setup.
DKIM does not work that way. Its public key lives at <selector>._domainkey.yourdomain.com, and the selector is an arbitrary string chosen by whoever set up signing. It might be google, selector1, k1, mandrill, s1, or a random hash a vendor generated in 2023. There is no directory, no index, and no way to list them.
So the tool above does the only honest thing available: it probes 32 of the selectors used by the major providers and reports which ones answered. If it finds keys, that is a fact. If it finds none, that is a hint and nothing more.
Any tool that tells you flatly that a domain has no DKIM is overstating what it can know. It probed a list, the list came back empty, and it dressed that up as a verdict. Your key could be sitting at a selector nobody thought to guess.
This is worth saying because the opposite error is expensive. Someone sees "no DKIM", panics, generates a new key pair, and replaces a perfectly good working configuration with an untested one, breaking signing for a week.
If the checker finds nothing, do not conclude anything yet. Go and read the selector from the source.
Google Workspace. Admin console, Apps, Google Workspace, Gmail, Authenticate email. The selector is shown there and defaults to google.
Microsoft 365. Defender portal, Email & collaboration, Policies, Email authentication settings, DKIM. Microsoft uses selector1 and selector2, published as CNAMEs rather than TXT records.
Sending platforms. SendGrid, Postmark, Mailgun, Brevo, Mailchimp and the rest all display the exact DNS records they want during domain authentication, and the selector is in the hostname they give you. Brevo uses brevo1 and brevo2, Mailchimp's Mandrill uses mandrill, Zoho uses zoho.
Or read it off a message you sent. This is the reliable method. Send yourself an email, open the raw source, and find the DKIM-Signature header. The s= tag is your selector and the d= tag is the signing domain. In Gmail, open the message, then the three-dot menu, then Show original.
A published key looks roughly like this:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...
The k tag names the key type, almost always rsa. The p tag holds the public key itself. A p= with nothing after it is a revoked key, which is a valid state and means signing with that selector has been deliberately turned off.
Key length matters a little. Google Workspace still defaults to 1024-bit in some tenants, and 2048-bit is the current recommendation. If your admin console offers the choice, take 2048. It is not urgent, but it is free.
SPF authenticates the server that handed the message over. Forward a message and the forwarding server becomes that server, so SPF fails through no fault of the original sender. Mailing lists, alias addresses and corporate gateways all break SPF routinely.
DKIM signs the message itself. The signature travels with it and survives forwarding, as long as nothing rewrites the signed headers or the body. That is why DMARC accepts either SPF or DKIM alignment, and why having both is not redundant: they fail in different situations.
If the checker finds three or four keys, nothing is wrong. Each sending service publishes its own, so a domain running Google Workspace for staff mail, HubSpot for marketing and Postmark for transactional will legitimately have three. What matters is that every service you actually send through has one, not that the number is small.
In our audit of 156 lead generation agencies, 21 returned no key on any of the 32 common selectors. We reported that as suggestive rather than conclusive, for exactly the reason above.
DKIM is one of three layers and the only one that cannot be fully verified from outside. Check the other two with the SPF record checker and the DMARC record checker. The SPF, DKIM and DMARC guide covers how they combine, and the deliverability checker audits your wider setup.