DKIM checker: your key,
read to the bit.
The selector is optional: we probe the ten common names, or pull it from a pasted DKIM-Signature header. Then we go past “record found”: the p= tag is base64-decoded, the DER walked, the modulus measured. A 512-bit key passes every existence check and has been forgeable since 2012.
Four ways DKIM rots quietly
A DKIM record can sit untouched for a decade and still "exist". Existing was never the bar. Each of these four passes the existence check while the checkmark stays green, and fails the only test that matters.
The 512-bit relic
In 2012 a mathematician factored Google's 512-bit DKIM key with rented compute and mailed the founders as each other. Keys that size still sit in DNS today — valid, signed, and forgeable.
factorable ≠ theoreticalThe tombstone still in use
An empty p= means "this key is revoked" — correct hygiene for a retired selector. But if the old ESP config still signs with it, every one of those messages fails DKIM. Today.
p= · empty = revokedt=y since launch day
The testing flag was meant for rollout week. Left on, it tells receivers to treat your signed mail exactly like unsigned mail — your DKIM pass earns you nothing, forever.
RFC 6376 §3.6.1The selector you can't name
The record lives at selector._domainkey — and DNS offers no way to list selectors. You can't check what you can't name, so DKIM records go years without an audit.
s= · the hidden halfSix DKIM selector states
Most tools stop at "record found". The record is the envelope — the verdict lives inside the key, and in two flags most checkers never mention.
The modern baseline (RFC 8301 tells signers to use it). Decodes to a well-formed public key, big enough that factoring is not the attack anyone tries.
Acceptable and still common — but NIST retired 1024-bit RSA for signatures back in 2013, and every year it stays published the margin shrinks.
512-bit was publicly factored in 2012 on rented cloud compute; 768 fell academically in 2009. A key this size is a forgery kit with your domain's name on it.
RFC 6376's deliberate tombstone: "this key has been revoked." The right end state for a retired selector — and a live outage for anything still signing with it.
Receivers are told to treat your mail as if it were unsigned — even when the signature verifies. A rollout aid that quietly cancels DKIM when it's left on.
Verifiers get "no key available" and the signature permfails. The catch: from outside, a deleted key and a typo'd selector look identical — which is why we probe ten.
The selector problem, explained
Your public key lives at selector._domainkey.yourdomain.com — and DNS has no query that lists selectors. You can only know the name or guess it. Four ways to get it:
- Read a signed message: open any email you sent → "Show original" → the s= tag of the DKIM-Signature header is your selector.
- Paste the header here: we unfold it and extract d= and s= for you — no reading required.
- Ask your ESP: the DNS-setup page that gave you the CNAME/TXT names the selector.
- Or let us guess well: leave the field blank and we probe the ten names ESPs actually use — right, in probe order.
Who uses which selector
the 10 we probe · common defaultsWhat you can check by hand
Once you know the selector, the raw material is one dig away.
Common DKIM questions
Type your domain above — selector optional. We fetch the TXT record at selector._domainkey.yourdomain (probing ten common selectors if you left it blank), parse every tag against RFC 6376, then validate the key itself: the p= value is base64-decoded, the DER structure inside is walked field by field, and the modulus is measured and graded — under 1024 bits is weak, 1024 acceptable, 2048+ recommended. Free, no signup.
The selector is the name in front of ._domainkey — chosen by whoever set up signing, invisible to any DNS listing. Three ways to find yours: open a message you sent and read the s= tag in the DKIM-Signature header ("Show original" in Gmail); paste that whole header into this tool and we extract it; or leave the selector blank and we probe the ten most common defaults — google, selector1/2, k1/k2, s1/s2, default, dkim, mail. Finding two live selectors is normal — that's rotation working.
Acceptable, aging, and worth scheduling out. Nobody has publicly factored RSA-1024 — but NIST disallowed it for new signatures back in 2013, RFC 8301 tells DKIM signers they should use 2048, and the big mailbox providers sign with 2048 themselves. 1024 isn't the emergency — that's 512, factored in 2012 on rented cloud compute. It's the key you rotate on your schedule instead of, eventually, on an attacker's.
Testing mode. RFC 6376 §3.6.1 instructs verifiers to treat mail from a domain in testing mode no differently from unsigned mail — even when the signature verifies perfectly. It exists so you can dry-run DKIM during rollout without consequences. The catch is that it works too well: nothing breaks while it's on, so it never gets removed. Your domain then spends years signing mail for zero credit. If this tool finds one, the fix is deleting four characters.
Deliberate revocation. RFC 6376 defines an empty p= as "this public key has been revoked". It's the correct tombstone for a selector you've retired, and clearer than deleting the record, which looks the same as a typo. Two readings follow. If you rotated away from this selector and nothing signs with it, it's hygiene: leave it. If any sender still signs with it, every one of those messages is failing DKIM right now. Check your DMARC reports for dkim=fail with this selector.
Verifiers must support up to 4096 (RFC 8301). But a 4096-bit key produces a TXT value long enough to need string-splitting, which some DNS provider UIs mangle. It buys you no practical security over 2048 for a key you should be rotating anyway, so 2048 is the sweet spot. The other direction is k=ed25519 (RFC 8463): tiny 32-byte keys, modern crypto. Verifier support still isn't universal, so deployments that use it typically dual-sign with RSA. This tool reads k= and says which you've published.
Alone — no, and we'd rather say so. DKIM proves two things: the message wasn't altered since signing, and the d= domain vouches for it. It does not prove the From: line your reader sees matches that domain — a forger can sign flawlessly with their own domain while displaying yours. Closing that gap is DMARC's job (alignment), and saying which servers may send at all is SPF's. The working stack is SPF + DKIM + DMARC. This tool makes sure the DKIM leg is real — a revoked or testing-mode key quietly kneecaps the other two.
Free tools are just the start.
Uptimia keeps your sites healthy.
Uptime, SSL, domain expiry, page speed, transactions — monitored from 171+ locations worldwide. Free for 30 days.