DKIM Explained: How Email Cryptographic Signatures Work

• DKIM (DomainKeys Identified Mail) adds a cryptographic digital signature to every outgoing email. This signature allows receiving servers to verify that the email was sent by an authorised server and has not been tampered with in transit.
• DKIM uses public-key cryptography. The sending server signs the email with a private key, and receiving servers verify the signature using a public key published in DNS.
• DKIM works through email forwarding because the signature travels with the email, unlike SPF which breaks with forwarding.
• DKIM is not a complete solution on its own. It does not prevent spoofing of the header From address without DMARC alignment.
• Use RSA 2048-bit keys as the minimum for 2026. 1024-bit keys are considered weak and are rejected by some providers. Ed25519 is an emerging alternative but should only be used with dual-signing alongside RSA-2048.

• SPF checks the envelope sender (Return‑Path) to verify the sending IP is authorised.
• DKIM checks the message content and headers using a cryptographic signature that travels with the email-so it works through forwarding.

1. Email composition: The sending server prepares the email message.
2. Hashing: The server creates cryptographic hashes of the message body and selected headers (e.g., From, To, Subject).
3. Signing: The server signs the combined hash with its private key.
4. Signature insertion: The signature is added to the email as a new DKIM-Signature header field.
5. DNS lookup: The receiving server looks up the public key for the domain using the selector specified in the signature (e.g., selector1._domainkey.example.com).
6. Verification: The receiving server uses the public key to verify the signature against the email content.
7. Result: The verification returns either pass or fail.

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=selector1; t=1690000000;
 bh=...; h=from:to:subject; b=...

• simple – No changes tolerated. The message must be byte‑for‑byte identical for verification to pass.
• relaxed – Allows minor modifications (whitespace changes, line wrapping) that often occur during email transit.

• From – REQUIRED in all signatures
• Sender
• Reply‑To
• Subject
• Date
• Message‑ID

• Key identification: The selector tells receiving servers which public key to use for a given email.
• Zero‑downtime rotation: You can publish a new key under a new selector while the old selector remains active.
• Multiple senders: Different sending services (e.g., marketing email, transactional email) can each have their own selector.

• Meaningful for forensic analysis (e.g., google_2026, mailchimp_q3)
• Sufficiently random so keys cannot be easily guessed
• DNS‑compatible (some DNS providers do not allow underscores in record names)

• Compromised keys: If a private key is leaked, attackers can sign fraudulent emails.
• Cryptographic obsolescence: Older algorithms and key lengths become weaker over time.
• Compliance: Some standards require periodic key rotation.

• Every 6 to 12 months is the widely recommended interval.
• Large organisations should rotate every 3 to 6 months.
• RSA‑1024 keys should be rotated immediately-they are now considered weak.

1. Generate a new key pair with a new selector name (e.g., selector2).
2. Publish the new public key in DNS under the new selector.
3. Keep both selectors active during the transition.
4. Update all sending systems to sign with the new key.
5. Wait for DNS propagation (48–72 hours).
6. Verify DMARC alignment still passes.
7. Remove the old selector from DNS after the grace period.

dig TXT selector1._domainkey.example.com +short

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Authentication-Results: dkim=pass header.d=example.com;

1. Use RSA 2048‑bit keys as the minimum. 1024‑bit keys are now considered weak and are rejected by some providers. 2048‑bit RSA is the recommended default for 2026, meeting RFC 8301, NIST specifications, and Google/Yahoo bulk sender requirements.
2. Sign key email headers. Always include the From header (REQUIRED), and include Sender, Reply‑To, Subject, Date, and Message‑ID when present.
3. Rotate keys regularly. Every 6 to 12 months using a parallel selector.
4. Test after configuration. Send test emails and verify the Authentication-Results header shows dkim=pass.
5. Monitor DKIM results. Use DMARC aggregate reports to see whether your DKIM signatures are being verified successfully.
6. Use relaxed/relaxed canonicalisation. This tolerates minor modifications during transit while maintaining security.
7. Set appropriate TTLs. Use a TTL of 300–3600 seconds to allow for quick changes during key rotation.
8. Maintain a selector inventory. For organisations using multiple sending services, keep a centralised list of active selectors, rotation schedules, and signing domains.

• DMARC requires either SPF or DKIM to pass.
• DKIM alignment (the domain in the d= tag matching the domain in the header From) is required for DMARC to pass.
• DKIM works through email forwarding, making it more reliable than SPF for DMARC alignment in forwarded mail.

• DKIM provides cryptographic verification that an email came from an authorised server and has not been tampered with.
• DKIM works through email forwarding because the signature travels with the email, unlike SPF.
• DKIM uses public-key cryptography with private keys on sending servers and public keys published in DNS.
• Use RSA 2048‑bit keys as the minimum for 2026. 1024‑bit keys are considered weak.
• Rotate DKIM keys every 6 to 12 months using a parallel selector for zero‑downtime transitions.
• DKIM is not a complete solution without DMARC alignment to verify the header From address.
• Ed25519 is emerging but should only be used with dual-signing alongside RSA‑2048.

• RFC 7208 – Sender Policy Framework (SPF)
• RFC 6376 – DomainKeys Identified Mail (DKIM)
• RFC 7489 – DMARC
• BIMI Specification