DKIM (RFC 6376) cryptographically signs selected headers and the body of a message with a private key. The corresponding public key is published in DNS. Receivers fetch the public key, verify the signature, and use the result — together with SPF — as inputs to DMARC and their own filtering decisions.
How the signing works
The sending MTA computes a canonical form of the message (headers plus body, optionally normalised for whitespace), signs a hash of it with the private key, and adds a DKIM-Signature: header describing which headers were signed, the domain (d=), the selector (s=), the algorithm (typically rsa-sha256), and the signature itself. Receivers use s= and d= to look up the public key in DNS: <selector>._domainkey.<domain>.
Selectors
A selector is an arbitrary name under _domainkey that lets a single domain publish multiple keys concurrently. Use different selectors per stream (marketing, transactional, corporate) so keys can be rotated independently. Selectors are also how key rotation is done without downtime: publish the new key under a new selector, switch the signer, and only then remove the old selector.
Key length and rotation
2048-bit RSA is the current default. 1024-bit is still accepted by all major providers but should be considered legacy. Rotate keys on a schedule — every 6 months is a common cadence — and always after any suspected compromise. Some DNS providers cap TXT length; long keys may need to be split into multiple concatenated strings.
Body canonicalisation
Two canonicalisation modes exist: simple (byte-exact) and relaxed (whitespace-normalised). Relaxed is the practical default because many mail systems modify whitespace in transit. Header canonicalisation similarly comes in simple and relaxed variants.
What breaks DKIM in transit
- Message modification by intermediate hosts (some mailing lists, some corporate gateways)
- Signing with a body-length limit (l=) then any body modification past the limit
- Public-key TTL / DNS caching issues after rotation
DKIM and DMARC alignment
For DMARC, the d= domain in the DKIM signature must align with the header From domain — exactly (strict) or on the organisational domain (relaxed). A valid DKIM signature that does not align gets no credit from DMARC.
Recommended posture
2048-bit keys. Per-stream selectors. Rotation every 6 months, published a week before switchover. Monitor DMARC aggregate reports to confirm the signature is validating and aligning as expected. Do not use body-length limits.
Related articles
- SPF ExplainedHow Sender Policy Framework works, how to author a record correctly, and how to avoid the common failure modes.
- DMARC GuideHow DMARC ties SPF and DKIM together, staged policy rollout from monitor to reject, and how to use aggregate reports.
- Google Postmaster GuideHow to set up Postmaster Tools, what each metric means, and how to interpret the reputation graph.
- PowerMTA OptimizationVMTA design, queue tuning, per-domain policy, and the configuration mistakes that quietly cost inbox rate.
- IP Warm-upHow to warm a new IP without wasting weeks or torching reputation. Volume curves, segmentation, and when to stop.
- Dedicated vs Shared IPWhen each is appropriate, the volume thresholds that make dedicated worthwhile, and the myths on both sides.