DKIM selectors

DKIM signs outgoing mail with a private key and publishes the matching public key in DNS, at <selector>._domainkey.example.com. The selector is chosen by whoever signs, which is what makes DKIM awkward to audit from the outside: there is no way to enumerate the selectors a domain uses, because DNS offers no way to list the names under a label.

So this check probes. It tries the selectors the major providers are known to use — google, selector1 and selector2 for Microsoft 365, k1, mandrill, dkim, and others — and reports what it finds. That makes a positive result trustworthy and a negative result weak: **finding nothing does not mean the domain has no DKIM**, only that it is not using a selector we know to guess.

This is also why the report follows CNAMEs here. Microsoft 365 publishes selector1._domainkey as a CNAME into onmicrosoft.com, so the answer lives in a zone the domain's own nameservers cannot serve — an authoritative-only lookup sees the CNAME and no key, and would report a working configuration as missing.

Two answers look like keys and are not, and both are excluded here. The first is an **empty p=**: RFC 6376 §3.6.1 defines a public key of the empty string as a revoked key, and a verifier must treat every signature naming that selector as failed. It is the correct way to retire a selector, so it is not a fault — but it is not a working key either, and it is not counted as one. The second is a **wildcard under _domainkey**. *._domainkey.example.com answers for every selector anybody asks about, including ones nobody ever created, so a probe run against a wildcarded zone returns the whole list. Before enumerating, this check asks for a random selector name that cannot exist; if that answers, the enumeration cannot distinguish a real selector from the wildcard and none is claimed — only a selector whose record *differs* from the wildcard's is counted.

DKIM matters more than SPF for durability. A forwarded message usually breaks SPF, because the forwarder connects from its own address; a valid DKIM signature survives forwarding as long as the message body and signed headers are untouched.

Turn on DKIM signing at every provider that sends as your domain. Every significant mail platform supports it, and it is generally a matter of enabling it in the console and publishing the two or three DNS records they give you.

Use a key of at least 2048 bits. 1024-bit keys are still widely deployed and are no longer a sensible choice for a new one.

Where a provider gives you a CNAME rather than the key itself, publish the CNAME rather than copying the key value. That is what lets them rotate the key without asking you to change DNS, and rotation is the thing organisations otherwise never get around to.

If this check reports nothing and you know DKIM is configured, that is expected for an unusual selector. Confirm by sending a message to an account you control and reading Authentication-Results in the received headers — that is the only observation that settles it.

If a wildcard under _domainkey was reported, remove it. It is almost always collateral from a * record higher up the zone, and it hides which selectors exist from you as readily as from anyone auditing you — including from a receiver debugging why your mail failed.