DKIM key checker

What a selector is

DKIM lets one domain hold several signing keys at once, so a signature has to say which key made it. Every DKIM-Signature: header carries an s= tag, and that value is the selector. A verifier takes the d= domain and the s= selector out of the header, joins them into <selector>._domainkey.<domain>, and reads the key published there.

Selectors are arbitrary labels. Providers pick whatever they like: a date such as 20230601, a product name, a shard number, a random string. Nothing about the name means anything to the protocol, and a domain may publish as many as it wants. That is what makes rotation possible. You publish a new key under a new selector, start signing with it, and retire the old one once nothing still depends on it.

How to find a selector

Read a message the domain has already sent you. Open its full headers and look for the DKIM-Signature: header. The s= tag in it is a selector that domain is signing with right now, and the d= tag is the domain to pair it with. One message can carry more than one signature, each with its own s=, which is what a domain mid-rotation or signing with two algorithms looks like.

Most mail clients keep headers behind a menu item along the lines of Show original or View source. Once you have the raw text, the header reader on the tools page will pull the signature apart for you and show the s= and d= values without you having to hunt through the text.

If the domain is yours, the selector is also wherever you set the signing up: your mail provider’s DNS instructions name it, and so does the record you pasted into your zone.

Why no tool can list them for you

Because DNS cannot be asked that question. There is no query that returns the children of a name, so nothing can enumerate what exists under _domainkey. A zone transfer would, and no public zone allows one.

A tool that appears to discover your selectors is guessing. It tries a list of strings providers commonly use, reports the hits and says nothing about the rest. On a domain that chose its own label, the guess list finds nothing and the tool reports a domain with no DKIM, which is simply false. We would rather ask you for the selector than present our guesses as your configuration.

What the record is made of

A key record is one TXT record written as semicolon-separated tags (RFC 6376 §3.6.1). Seven of them are defined, and most records use three.

• v=DKIM1 is the version. It is optional, and if it is present it must come first. A verifier is required to ignore a record whose version it does not recognise, so a wrong value is worse than an absent tag.
• k= is the key type. It defaults to rsa when absent, and RFC 8463 adds ed25519.
• p= is the public key, in base64. This is the record. Present and empty has its own meaning, covered below.
• t= carries flags. t=y is testing mode and t=s stops subdomains using the key.
• s= lists the service types the key may be used for. A list without email or * in it tells a verifier checking mail that this key does not apply.
• h= lists the hash algorithms the signer will use. It is advisory.
• n= is a note for whoever reads the record. Verifiers ignore it.

Anything else in the record is ignored by verifiers, which is deliberate: it is how the format stays extensible. Unrecognised tags are reported here as information, not as a problem.

What the key size means

RFC 8301 §3.2 sets two different numbers, and the gap between them is what makes a 1024-bit key confusing. Signers should use at least 2048 bits. Verifiers must be able to validate signatures from 1024 bits upward. So a 1024-bit key is still checked by everybody, and is below what the RFC asks of whoever generated it.

Below 1024 bits, no verifier is obliged to accept the signature at all. That makes such a key unusable in practice rather than merely dated.

Ed25519 keys are 256 bits and that is the entire algorithm (RFC 8463). The number is not comparable to an RSA modulus and nothing is asking for a bigger one. Support is not universal, so a domain signing with Ed25519 usually publishes an RSA selector alongside it and signs with both.

The size is a fact worth reading, not a grade. A 1024-bit key on a large provider is usually a selector that has been in place for years, and the RFC’s own two numbers are the useful part.

An empty key is a revocation, not a broken record

p= with nothing after it is not a truncated record. RFC 6376 §3.6.1 gives it one specific meaning: this public key has been revoked. It is the documented end state for a retired selector, and it is a deliberate act rather than an oversight.

Leaving the name in place with an empty key is the point. Any message still carrying a signature from that selector fails cleanly against a key that says it was revoked, instead of the name simply disappearing. You can see it on a live domain today: 20230601._domainkey.gmail.com publishes exactly this, and so does the wildcard at *._domainkey.example.com.

Testing mode cancels DKIM quietly

t=y puts the signing domain in testing mode, and RFC 6376 §3.6.1 tells verifiers to treat a message signed with that key as though it were not signed at all. The signature is checked and then set aside.

The flag exists for a rollout: publish the key, sign with it, watch the reports, then turn it off once the results look right. Left on afterwards it is close to invisible. The record looks complete, the signature verifies, and DKIM still contributes nothing, which means a DMARC policy relying on DKIM alignment is relying on nothing.

A selector that does not exist is an answer

If the name returns NXDOMAIN, the domain does not sign with that selector. That is usually the fact a reader came for, and it is not a failure of the lookup. The common causes are a typo, a selector taken from an old message after a rotation, or a selector belonging to a different sending service than the one you meant.

A name that exists but carries no key record is a different answer. It normally means a CNAME pointing at a provider that has not published the key yet, or a record that was deleted while the alias to it was left behind.

Two key records at one selector is a third. RFC 6376 §3.6.2.2 leaves the outcome undefined when a selector publishes more than one, and verifiers differ over which to use, so the honest report is that the name is ambiguous rather than a guess at which one a given receiver would pick.

What this cannot tell you

That a key is published does not mean mail is being signed with it. The key is one half of DKIM; the other half is the sending server adding a DKIM-Signature: header on the way out, and only an actual message can show you that.

It also cannot tell you whether DKIM is doing anything for the domain’s DMARC. DMARC requires alignment: the d= domain in the signature has to match the domain in the From: address, exactly or by organisational domain depending on how strict the policy is. A perfectly valid key signing under an unrelated domain passes DKIM and contributes nothing to DMARC.

And it says nothing about SPF, about the DMARC policy itself, or about what any particular receiver will do with a message. Those are separate records with separate answers.

Answers are cached for a few minutes so that a popular link does not turn into a flood of identical DNS queries. If you have just published a key and are still seeing the old answer, the result will say it came from the cache.

What DKIM does not protect

A signature proves a message really came from the domain it claims, and that nobody rewrote it along the way. It says nothing at all about who handed that domain your address in the first place, or what they did with it afterwards.

That half is yours to control. Giving each sender its own address is the thing Maski does, and it means that when one of them leaks or starts selling you on, you switch off that one address instead of rebuilding your mail setup.