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.

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.