Shared DKIM key checker
Every DKIM checker reads your records back to you. This one compares the key material against 446 distinct public keys Warden measured across 105 B2B SaaS domains, and names the other companies publishing the same key as you — because in that sample, one key signed for 62 of them.
Compare your keys
Enter a domain. Warden finds its DKIM keys, fingerprints each one, and checks those fingerprints against 446 distinct public keys measured across 105 B2B SaaS domains — then names the other domains publishing the same key, if any do.
Why nobody else answers this
A DKIM record is easy to read. Every free checker will fetch selector._domainkey.yourdomain, parse the tags, and tell you the key is 2048-bit RSA and the syntax is valid. That is a lookup, and one domain’s records in isolation cannot answer the question underneath: is this key yours, or is it a key your provider publishes on every customer it signs for?
Answering that needs a corpus. You have to have already walked a meaningful number of other domains, decoded every key each of them publishes, and kept the key material so a new key can be matched against it. That is a measurement exercise rather than a DNS query, and it is the reason this comparison does not exist elsewhere: not because it is technically hard, but because the data has to be collected first.
Warden collected it, and published it. The 105-domain study found 742 published DKIM keys that were only 446 distinct keys once each p= value was hashed — 18 of those keys appeared on more than one domain, touching 91 of the 105 domains measured. This page runs your domain against that set.
How the comparison works
- Your domain's selectors are found the same way the selector finder finds them: by querying around a hundred documented provider default names at <selector>._domainkey.yourdomain. No sample email needed.
- For each selector that resolves, the base64 p= value — the public key itself — is hashed with SHA-256 and the first 16 hex characters are kept as a fingerprint. Two domains carrying byte-identical keys always produce an identical fingerprint.
- That fingerprint is looked up in the measured corpus. A hit names every other domain in the sample publishing the same key, and the page prints the dig command that proves it on any one of them.
- A revoked key — p= present and empty — has no key material, so it is reported and not compared. A domain publishing a wildcard under _domainkey is not compared either, because no hit there would be a selector anybody configured.
- Nothing secret is involved at any point. A DKIM key is published in DNS so that receivers can read it; the fingerprint is a hash of an already-public value.
The widest shared keys in the sample
Ranked by how many of the 105 measured domains publish the same key. The selector name is a hint about which service a key belongs to, not proof — the fingerprint is the evidence, and it is what the comparison above actually matches on.
| Selector | Commonly used by | Key | Domains |
|---|---|---|---|
| zendesk1 | Zendesk | 2048-bit RSA | 62 |
| zendesk2 | Zendesk | 2048-bit RSA | 62 |
| k1 | Mailchimp / Mandrill | 1024-bit RSA | 31 |
| mandrill | Mandrill | 1024-bit RSA | 30 |
| k2 | Mailchimp / Mandrill | 2048-bit RSA | 26 |
| k3 | Mailchimp / Mandrill | 2048-bit RSA | 26 |
| 200608 | Salesforce / ExactTarget | 1024-bit RSA | 17 |
| hs1 | HubSpot | 2048-bit RSA | 12 |
| hs2 | HubSpot | 2048-bit RSA | 12 |
| mte1 | Mailgun | 2048-bit RSA | 8 |
Read that top row carefully, because it is the finding that prompted this tool: the same 2048-bit key, byte for byte, signing mail as 62 different companies — including payment processors, identity providers and security vendors. That is normal multi-tenant operation. It is also a blast radius that none of those 62 companies controls.
What this does not tell you
The limits are the point, so they are stated rather than buried. No match means no domain in a 105-domain sample publishes your key; it is not evidence that your key is unique to you, and the sample is far too small to support that claim. A match tells you a key is shared, not that anything is wrong — shared-key signing is standard practice and the providers doing it are competent operators.
The corpus is frozen at 2026-09-21. Keys rotate, so a peer domain may have moved on since. And a selector chosen by hand, or minted per tenant as Postmark and Amazon SES do, will not be found by a dictionary probe at all — so a run that finds nothing is not evidence that a domain has no DKIM. Only a signed message proves that.
The full dataset, including the fingerprint of every key, is published as CSV under CC BY 4.0 with no email required: download it here and reproduce any figure on this page, or extend the comparison to your own list of domains.
Questions this raises
Is it bad if my DKIM key is shared with other companies?
Not in itself, and this is the important part. A multi-tenant mail platform that signs for every customer with one key is doing exactly what it was built to do — it is an operational trade, not a defect, and there is no CVE to file. What changes is who holds the risk: the key signing mail as your domain is held by a provider, protects every one of its customers at once, and can only be rotated by that provider. That is a fact worth knowing about your own inventory, and it is not one your scanner will tell you.
How can you tell two domains publish the same DKIM key?
By comparing the key material itself, not the selector name. The p= tag in a DKIM TXT record is a base64-encoded public key; hash that string and two domains carrying byte-identical keys produce an identical fingerprint. This page shows the fingerprint it computed and the exact dig command that returns the same p= value on a peer domain, so the claim is checkable rather than asserted.
Is it safe to publish a DKIM key fingerprint?
Yes. A DKIM key is a public key by definition — it is published in DNS precisely so that any receiving mail server can read it and verify a signature. Nothing here handles a private key, and the fingerprint is a hash of a value that is already public. No secret is exposed by this page or by the dataset behind it.
What does it mean when the check finds no match?
Only that no domain in this particular sample publishes the same key. The sample is 105 B2B SaaS domains measured on a single day, which is small and frozen deliberately so the result stays checkable. A key from a platform that no sampled domain happens to use will show no match while being shared with thousands of customers. No match is therefore not evidence that your key is unique to you, and the page never says that it is.
Which mail platforms share one DKIM key across customers?
In this sample, Zendesk was the widest: its zendesk1 and zendesk2 selectors published the same two 2048-bit keys on 62 of the 105 domains each. Mailchimp's k1 spanned 31 domains, Mandrill 30, Salesforce/ExactTarget's 200608 spanned 17, HubSpot's hs1 and hs2 12 each, Mailgun's mte1 and mte2 8 each. In total 18 distinct keys appeared on more than one domain, touching 91 of 105 domains. Other platforms mint a key per customer — a match or no match here is about how a specific platform chose to operate, not about its quality.
Should I stop using a provider that shares its DKIM key?
That is not the conclusion this check supports, and we would not draw it for you. Shared-key signing is standard practice at scale and the providers doing it are among the most competent operators in the industry. The reasonable action is inventory work: know which platforms can sign as your domain, confirm each one is still in use, and understand that for the shared ones your exposure is coupled to the provider rather than to your own key management. If a key is being held on your behalf, that belongs in your risk register as a fact, not as a finding.
Does this tool scan my systems?
No. It reads public TXT records — the same DNS any receiving mail server reads to verify a signature. No mail is sent, no host is connected to, and nothing inside your systems is accessed. Warden does not access, scan or investigate anything without agreed scope and explicit written authorization.
Where does the comparison data come from, and can I have it?
From Warden's own measurement of 105 B2B SaaS domains on 2026-09-21: 742 published DKIM keys that turned out to be 446 distinct keys. The full dataset is published as CSV under CC BY 4.0 with no email required, including the fingerprint of every key, so you can reproduce this comparison yourself or extend it to your own list of domains.
Where this sits against your other findings
A shared signing key has no CVE and no CVSS score, so it never appears on the report that drives a remediation queue — while being a live credential that can sign as your company and is held by someone else. The records next door have the same property. The selector finder tells you which keys exist at all and whether each can still sign, and the SPF lookup checker counts your chain against the RFC 7208 limit of 10 and totals how many IPv4 addresses it authorizes to send as you — routinely hundreds of thousands.
Each is a single signal. The exposure check reads them together with DMARC and the headers your homepage returns, and puts the result in priority order with the evidence for each.