Free diagnostic

DKIM checker and selector finder.

Probe the common DKIM selectors for a domain, validate the published keys, estimate key strength, and spot revoked records.

Run DKIM check DKIM rotation guide

selectors auto-probed

2048

bit strength check

stored submissions

What a DKIM check can prove

A DKIM public key lives at selector._domainkey.yourdomain as a TXT record. The hard part is knowing the selector — this tool probes the common ones (google, selector1/2, default, k1, s1, mail and more) and validates whatever it finds: key type, estimated strength, and revocation flags.

Finds published selectors instead of asking you to guess them.
Flags revoked keys (empty p=) and keys shorter than 1024 bits.
Accepts an explicit selector when you already know it from a DKIM-Signature header.

What it cannot prove

A published key does not prove your ESP signs with it. The selector that matters is the s= value in a real message's DKIM-Signature header — verify that with the header analyzer or a full deliverability test.

Fundamentals

What is DKIM?

DKIM (DomainKeys Identified Mail, RFC 6376) lets a sending server sign selected headers and the message body with a private key. The matching public key is published in DNS at selector._domainkey.yourdomain, and receivers verify the signature on arrival. A valid signature proves the message was signed by whoever holds that key and that the signed parts were not altered in transit. The selector is the part everyone gets stuck on. One domain can publish many keys — google, selector1, selector2, default, k1, s1, mail are common conventions — and the only way to know which one a message used is the s= tag in its DKIM-Signature header. That is why this tool probes the common selectors automatically instead of asking you to guess. DKIM also carries the weight in forwarding scenarios: SPF breaks when a forwarder re-sends your message from its own IP, but a DKIM signature survives forwarding intact. For DMARC, a passing and aligned DKIM is often the only thing keeping forwarded mail authenticated.

Reading the output

How to read your results

Enter a domain and optionally a specific selector. The tool probes ten common selectors plus yours, and reports every published key it finds.

found: each selector with a published record, the record itself, and its parsed tags — key type (k=), hash algorithms (h=), and service types (s=).
keyStrength: estimated from the decoded p= length — 2048-bit keys are the current baseline; 1024-bit keys still work but should be rotated up when convenient.
flags: operational warnings — an empty p= means the key is revoked (deliberate, used during rotation), a very short p= means a weak or truncated key, and t=y means the record is in testing mode.
probed: the full selector list queried, so you can see coverage. If your ESP uses an unusual selector, enter it explicitly.

Troubleshooting

Common errors and how to fix them

Most DKIM problems are publication problems, not signing problems. The key exists at the ESP, but the DNS record is missing, wrong, or stale.

No selectors found: either no DKIM record is published, or your ESP uses an uncommon selector. Check the DKIM-Signature s= value on a real message with the header analyzer, then query that selector explicitly.
Record published but signature fails: the public key in DNS no longer matches the private key signing your mail — usually after an ESP migration or a rotated key that was never republished.
Revoked key (empty p=): deliberate during rotation, but a revoked selector still being used for signing means every verification fails. Republish the current key or move signing to the new selector.
1024-bit keys: functional, but 2048-bit is the baseline receivers increasingly expect. Rotate using the dual-selector approach in the DKIM rotation guide — publish the new key, sign with both, then retire the old.
Microsoft 365 CNAME setup: selector1 and selector2 are published as CNAMEs to your tenant's onmicrosoft.com records. If signing breaks, verify both CNAMEs still resolve and weren't flattened into stale TXT records.

Providers

Per-provider notes

Every major receiver verifies DKIM, but they differ in how much weight it carries and what they publish for their own outbound mail.

Gmail: requires DKIM for bulk senders (5,000+/day) since February 2024 and uses it heavily for reputation. A valid aligned DKIM signature is the single strongest signal after complaint rate.
Microsoft 365 / Outlook: signs with selector1/selector2 and expects custom domains to publish the matching CNAMEs. Since May 2025, high-volume senders to Outlook.com must pass SPF, DKIM, and DMARC.
Yahoo: has historically leaned on DKIM more than other providers; a missing or broken signature hurts more there than elsewhere.
Your own domain: publish 2048-bit keys, rotate every 6 months with two live selectors, and keep the old key published until in-flight mail drains (about 7 days).

Comparison

WillItInbox vs MXToolbox vs dmarcian

dmarcian's DKIM inspector is the classic reference tool; MXToolbox offers free ad-supported lookups with paid monitoring from $129/mo. WillItInbox probes the selector list for you, validates what it finds with no login and no retention, and connects the result to DMARC monitoring when you want alignment watched continuously rather than checked once.

Capability	WillItInbox	MXToolbox	dmarcian
DKIM record lookup	Free, no login	Free, ad-supported	Free inspector tool
Automatic selector finding	10 common selectors probed	Manual selector entry	Manual selector entry
Key strength + revocation flags	Yes	Partial	Yes
Alignment monitoring over time	DMARC monitoring	Paid plans	Core paid offering
Submitted-data retention	None	Varies by product	Varies by product

Live diagnostic

Check current evidence

This anonymous tool is rate limited and does not retain submitted input. It reports observable evidence without promising delivery, authentication alignment, or inbox placement.

No SMTP mailbox probing, account lookup, or tenant data is used.

Enter an input to see current evidence, limitations, official references, and the relevant next step.

DKIM key rotation

Rotate keys safely with the dual-selector strategy.

SPF, DKIM, DMARC explained

How the three authentication layers interact.

DMARC checker

Inspect the policy that sits on top of DKIM.

DMARC monitoring

Watch alignment and signing domains over time.

FAQ

What is a DKIM selector?

A selector is a name prefix that lets one domain publish many DKIM keys at once. The public key lives at selector._domainkey.yourdomain, and a message's DKIM-Signature header names the selector (s=) that signed it. ESPs pick their own conventions — Google uses 'google', Microsoft 365 uses 'selector1' and 'selector2'.

The tool found no selectors. Is my DKIM broken?

Not necessarily. Your ESP may use a selector outside the ten probed names. Find the s= value in a real message's DKIM-Signature header (paste the headers into the header analyzer) and enter that selector explicitly. If that also returns nothing, the record genuinely is not published.

What does an empty p= tag mean?

A revoked key. Publishing a selector with an empty p= is the standard way to retire a key — verifiers treat it as 'no key'. That is correct during a rotation, but if your ESP still signs with that selector, every DKIM verification fails.

Is 1024-bit DKIM still acceptable?

It verifies, but 2048-bit is the current baseline and the direction receivers are moving. Rotate with the dual-selector method: publish the new 2048-bit key under a new selector, sign with both for at least 7 days, then revoke the old key.

Does a valid DKIM key guarantee DMARC passes?

No. DMARC also requires alignment: the d= domain in the signature must match (or be a subdomain of) the visible From domain. A valid signature from your ESP's domain passes DKIM but fails DMARC alignment — check with the DMARC checker or a real-message test.

Do you store the domains I check?

No. The tool is anonymous, rate limited, and retains nothing. Selectors are probed live against public DNS and the results are discarded after the response.