DKIM checker

Why DKIM cannot always be checked from a domain

A DKIM key lives at selector._domainkey.yourdomain. The selector is a name chosen by whoever sends your mail, and it appears in the signature on a message. It is not listed anywhere in DNS, and DNS provides no way to enumerate the names under a domain.

So a checker given only a domain has to guess. This one guesses well — it detects your mail platforms from your MX and SPF records and tries the selectors each platform is documented to use, plus a short list of common defaults — but a guess that comes up empty proves nothing.

That is why a scan here can return Not determined rather than Fail. Tools that report "DKIM missing" when they simply did not find a selector are stating something they cannot know, and people act on it: they generate new keys for a domain that was signing correctly all along.

The way to settle it

Send yourself a message and look at its headers. The DKIM-Signature header carries d=, the signing domain, and s=, the selector. The Authentication-Results header added by the receiving system carries the verdict. That is direct evidence, and it takes about a minute.

Analyse a message — the headers are parsed in your browser and never uploaded.

What is checked when a key is found

• Key length. Google's published sender guidelines require a DKIM key of 1024 bits or longer. 2048 is the current norm where the DNS provider supports the longer record.
• Revocation. An empty p= value is an explicit revocation under RFC 6376. Signatures made with that selector fail. This is a real and easily missed fault.
• Testing mode. t=y asks receivers not to treat a verification failure differently from unsigned mail, which is often left behind after setup.
• Delegation. Most hosted platforms publish the selector as a CNAME so they can rotate the key without you touching DNS. That is normal and is reported as such.