DKIM Checker: Probe the Selectors and Size the Published Keys

Try the selectors senders use most often, read the key each one publishes, and understand why a private selector is indistinguishable from no DKIM at all.

By Net Insight Published 2026-09-17 Updated 2026-09-17

What a DKIM record is, in one paragraph

DomainKeys Identified Mail lets a sending system sign a message with a private key, and it publishes the matching public key in DNS so a receiver can verify the signature. The verification proves two things and only two things: that whoever signed the message held the private key, and that the signed headers and body were not altered in transit.

That is a narrower claim than people usually assume. It is also the reason DKIM survives forwarding, where SPF usually does not: a forwarded message keeps its original signature, and the signature stays valid as long as the parts that were signed were not rewritten.

Why the selector cannot be guessed

The public key is published at <selector>._domainkey.<domain>. The selector is an arbitrary label chosen by whoever set up the signing configuration, and it exists so that a domain can have several keys at once — one per sending system, or two during a rotation. The protocol does not require any particular name.

This is a design decision with an operational cost. Because the selector is arbitrary, a lookup tool can only try a list of names that commonly appear, which is what this page does. A domain signing with a selector nobody would guess is therefore indistinguishable from a domain that does not sign at all. The report says this explicitly rather than labelling the absence of a record as a failure.

The reliable way to find a selector is to look at a message. The DKIM-Signature header carries s= for the selector and d= for the signing domain, and entering that selector here checks exactly the record a receiver will use.

Reading the key

The p tag contains the public key encoded in base64. The report estimates its size by taking three quarters of the encoded length to get the byte count and rounding to the nearest 64 bits. It is an estimate because the published record may include whitespace and the encoding is not perfectly aligned to bit boundaries, and the page says so instead of presenting the figure as exact.

Size is the one thing worth checking. Keys shorter than 1024 bits are refused by many large receivers, and 1024 itself is being phased out as senders move to 2048. A short key is not a configuration error in the strict sense — the record is valid — but it weakens the guarantee to the point where some receivers treat it as inadequate.

The counterweight is header length. A 2048-bit signature is a long string, and it travels inside the message header rather than the body. A signing tool that does not fold the header across continuation lines can produce a message whose header line exceeds the limit that intermediate servers accept, and the message is then rejected for a reason that has nothing to do with authentication.

The tags a valid record must contain

A published DKIM key record needs a version tag, the key itself, and a key type. Because these records are TXT records carrying text for machines, a missing component does not necessarily stop a receiver from attempting verification — it stops it from succeeding, which looks the same at the sending end as nothing being configured.

The key could also be published as revoked, which is what a p tag with an empty value means: the selector is announced and deliberately carries no key. That is the correct way to retire a selector, because it lets a receiver distinguish a withdrawn key from a typo in the query name. A record in that state is reported as present rather than absent, which is the useful distinction.

What DKIM does not do

It does not say the sender is trustworthy, and it does not say the domain is the one the recipient sees. Signing proves a key was used, not that the signer had any right to the domain in the From header. That alignment question is DMARC’s job, and it is why the DMARC checker matters alongside this page.

It does not survive arbitrary modification. That is the point of signing, but it creates a practical trap: a mailing list that adds a footer to the body, or a gateway that rewrites a link, invalidates the signature. The message then fails DKIM for a legitimate reason, which is precisely the case DMARC’s alignment rules are designed to accommodate through SPF or through a relaxed canonicalisation setting.

It does not report how many messages are signing. A published key and a signing configuration are different things, and a key can be published by a system that no longer signs anything. Confirming that signing actually happens requires a signed message to inspect, and the email deliverability test can only confirm that a key is reachable, not that it is in use.

It also does not tell you where the message ends up. Authentication decides attribution; reputation and content decide placement. Those are separate questions, described in why legitimate email goes to spam and governed by the policy in the DMARC policy guide.

Keep this setup

Save the settings to your Sitefarm account. Uploaded files and generated results are not stored.

Questions worth asking

Why can this not find my DKIM record?

Because the selector is chosen by whoever set up signing, and it cannot be derived. The tool tries the names that appear most often; a provider using its own selector looks the same as no DKIM at all, which is why this result is inconclusive rather than a failure.

Where do I find my selector?

In a received message. The DKIM-Signature header contains an s= tag with the selector and a d= tag with the signing domain. Take those two values and enter the selector here to check the exact record.

Is a 1024-bit key still acceptable?

Increasingly not. Many receivers refuse keys below 1024 bits, and 1024 itself is being retired by senders upgrading to 2048. The record stays compatible, but a short key undermines the point of signing.

Why does a longer key cause delivery problems?

Because the signature travels in a header. A 2048-bit key makes the DKIM-Signature header longer, and a signing tool that does not fold the header across lines can push a message over a line-length limit, at which point intermediate servers may reject it.

Does passing DKIM mean my mail reaches the inbox?

No. DKIM proves the message was signed by a holder of the private key and that it was not altered in transit. It says nothing about sender reputation, complaint rates or how a receiver will treat the message.