DKIM — DomainKeys Identified Mail

DKIM adds a signature header to every email you send. Receivers fetch your public key from DNS, recompute the signature against the message body, and verify the message has not been altered in transit.

Unlike SPF, DKIM survives forwarders. If your alumni-network mailing list rebroadcasts an email to its members, the SPF check fails (the source IP changed) but the DKIM signature still validates — because the body is unchanged. This is why DKIM is the most important auth signal in 2026.

The DKIM record

dnsvolt._domainkey.acme.dev. IN CNAME volt.domainkey.voltmail.dev.

A CNAME pointing at our authoritative DKIM endpoint. We host the actual TXT public-key record on our side, so when we rotate keys, your CNAME does not change.

Why two selectors

Publishing two CNAME records — volt._domainkey and volt2._domainkey — lets us rotate the active key with zero downtime. While selector volt signs new mail, selector volt2 is the warm spare. We promote it, the old one becomes the spare, the cycle repeats.

Key length — 1024 vs 2048

Use 2048-bit keys. 1024 is still accepted by every receiver, but Google has been saying "we will deprecate" since 2020 and 2048 is now the default. The cost is a slightly larger DNS record (above 255 bytes, which means split TXT strings — every modern resolver handles this fine).

Alignment with the From: header

For DMARC to pass, the d= tag in the DKIM signature must match (or be a parent of) the From: header domain. If you sign with d=voltmail.dev but mail goes out from acme.dev, DKIM passes but DMARC fails on alignment. We handle alignment automatically when you verify a domain — the signature uses your domain, not ours.

Common mistakes

• Using one selector and rotating in-place — guaranteed signature failure during the propagation window.
• Sharing the DKIM key across multiple senders — compromise of one leaks everyone's signing power.
• Skipping rotation entirely — old keys leak via developer laptops, GitHub, and former employees.