DKIM explained: selectors, keys and rotation

This guide is for agencies and IT providers setting up or checking DKIM on client domains: what the signature does, where the keys live, how long they should be, how to make sure the signature counts for DMARC, and how to change a key without a gap.

What DKIM does

DKIM (DomainKeys Identified Mail, RFC 6376) has the sending server sign each message with a private key. The matching public key is published in DNS, so any receiver can check the message really came from someone holding the key and wasn't changed on the way.

Selectors and where keys live

A domain can have many keys, one per service, each at its own name called a selector. The key sits at selector._domainkey.domain:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

v=DKIM1

Marks the record as a DKIM key.

k=

The key type: rsa, or ed25519 for newer keys.

p=

The public key itself. An empty p= means the key has been withdrawn.

The key above is cut short. A real 2048-bit key runs to about 400 characters, more than the 255 a single TXT string can hold, so DNS stores it as two or more strings that receivers join back together. Most DNS providers split it for you; a few older control panels don't, which is where a “value too long” error comes from.

Some providers publish a CNAME at the selector instead, pointing at a key they manage and rotate for you. Microsoft 365 works this way.

To find a domain's selectors, paste the headers of an email it sent into the email header analyser, which picks out the selector (s=) and signing domain (d=). The DKIM checker then looks the key up, or tries the common selectors if you don't have an email to hand.

Key length

RFC 8301 set the current rules: receivers must accept RSA keys from 1024 bits up, signers should use 2048 bits, and anything shorter than 1024 bits is to be ignored. Older set-ups often still use 1024-bit keys; they work today, but are worth replacing, and our checks flag them as something to improve.

Ed25519 keys (RFC 8463) are much shorter and fit a single TXT string, but on their own they're still poorly supported by receivers. Publish one only alongside an RSA key, with the message signed by both. If a service asks you to supply your own key, the DKIM key generator makes a 2048-bit pair and the record to publish, in your browser.

Signing with the right domain

Many services sign with their own domain by default, such as a newsletter tool signing as itself. The signature passes, but it doesn't match the From domain, so it doesn't count for DMARC. Look for “custom domain” or “domain authentication” in each service's settings, and publish the records it gives you. The DMARC reports show which services are signing as themselves; how to read a DMARC report explains where to look.

Changing keys without a gap

1. Create the new key in the provider's settings, under a new selector.
2. Publish it in DNS and wait for it to be visible everywhere, usually within an hour.
3. Switch signing to the new selector.
4. Leave the old key published for a week or so, since messages already sent may still be checked, then remove it.

Hosted DKIM. If editing the client's DNS for every key change is the hard part, Domain Health Hub can serve the keys instead. Delegate _domainkey.<domain> to ns1.dkim.domainhealthhub.com and ns2.dkim.domainhealthhub.com with two NS records, and every selector is answered from our own nameservers. We import the keys already published in public DNS and the selectors seen in the domain's DMARC reports, and check each key is present and a sensible length. If the DNS is at Cloudflare, one click adds the NS records; elsewhere you add them once. See how hosted records work.

Doing this for clients? Domain Health Hub checks every client domain each day and puts the results in a monthly report card with your logo. Start a free trial; no card needed.