Authentication
DKIM explained: keys, selectors, alignment, and rotation
DKIM cryptographically signs the headers and body of each message, letting receivers prove the message was authorised by the signing domain and was not modified in transit.
How signing works
A signing MTA hashes selected headers (typically From, To, Subject, Date, etc.) and the body, then signs the hash with a private key. The signature, the list of signed headers, the canonicalisation rules, the signing domain (d=), and the selector (s=) all go in a DKIM-Signature header. The receiver fetches the public key at <selector>._domainkey.<domain> and verifies.
Selectors
A selector is just a label that lets you rotate keys without breaking in-flight mail. You can publish many DKIM keys for the same domain under different selectors (e.g. sg, mailo, k1). ESPs typically pick a selector for you; if you operate your own MTA, name selectors by date (e.g. 20240501) so rotation is obvious.
Key strength
Use 2048-bit RSA keys. 1024-bit keys are still common in the wild but considered weak; Microsoft and Google now warn on them. Some DNS hosts split long TXT records — make sure the published record concatenates correctly.
DKIM alignment
For DMARC to pass on DKIM, the d= domain in the DKIM-Signature must align with the From: header domain. Relaxed alignment allows organisational-domain match; strict alignment requires exact match. Most ESPs default to a sending subdomain that aligns relaxed with the root From.
Key rotation
Generate a new selector and publish the public key, wait 24-48 hours for DNS to propagate, then switch the signing MTA to the new selector. Leave the old selector record live for 1-2 weeks before removing it.
Frequently asked questions
- What happens if DKIM verification fails?
- DKIM failure alone doesn't reject mail. The result feeds into DMARC: if DKIM fails and SPF also fails (or doesn't align), DMARC fails and the receiver applies your DMARC policy (none/quarantine/reject).