1. The Cryptographic Architecture of DKIM (RFC 6376)
DomainKeys Identified Mail (DKIM), formalized under RFC 6376, is an industry-standard asymmetric cryptographic authentication protocol. DKIM provides two essential security guarantees for email communications: Sender Domain Authentication and Message Tamper Resistance.
When an outbound email is dispatched by your mail transfer agent (MTA), the signing engine generates a cryptographic digest (hash) of the email's core headers (including From, To, Subject, and Date) and the body content using the SHA-256 algorithm. The MTA then encrypts this digest using your confidential RSA Private Key and attaches the resulting digital signature into the message headers under the DKIM-Signature field.
When the destination server receives the email, it extracts the selector and domain tags (s=mail; d=yourdomain.com) from the signature header, retrieves the corresponding RSA Public Key published in your DNS zone at mail._domainkey.yourdomain.com, and decrypts the signature. If the calculated hash matches the decrypted signature exactly, the email is certified authentic and unaltered.
2. Anatomy of the DKIM-Signature Email Header
An authentic DKIM header contains multiple standardized tags defined under RFC 6376:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yourdomain.com; s=mail; t=1724284800; h=from:to:subject:date:message-id; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...v=1: Identifies the DKIM specification version.a=rsa-sha256: The cryptographic signing algorithm (RSA with SHA-256).c=relaxed/relaxed: Canonicalization algorithms applied to headers and body.d=yourdomain.com: The organizational signing domain.s=mail: The selector name used to locate the public key in DNS.bh=: The Base64-encoded hash of the canonicalized email body.b=: The digital cryptographic signature over the headers and body hash.
3. Safe Key Rotation Strategies and Best Practices
To maintain robust cryptographic posture, organizations should rotate DKIM keys every 6 to 12 months. Never overwrite an active selector key in DNS without transitioning mail flows first:
2026b) and publish its TXT public key at 2026b._domainkey.domain.com.2026b.4. Frequently Asked Questions (DKIM Cryptography FAQ)
How does IncogSay generate DKIM keys securely?
IncogSay uses the native W3C Web Cryptography API (window.crypto.subtle) built directly into your browser engine. Cryptographic key pairs are mathematically computed on your local CPU. The private key is never transmitted across any network or saved on our servers.
Why is a 2048-bit DKIM key mandatory in 2026?
1024-bit RSA keys are cryptographically vulnerable to prime factorization attacks by modern GPU clusters and cloud compute. Google, Yahoo, and Microsoft enforce 2048-bit RSA signatures as mandatory for trusted deliverability.
What is a DKIM selector?
A DKIM selector is an alphanumeric string (e.g. 'google', 'selector1', 'mail') that allows a single domain to publish multiple distinct DKIM public keys in DNS simultaneously. Selectors enable key rotation without service disruption and support multiple independent sending services.
What is the difference between DKIM and SPF?
SPF authenticates the connecting IP address of the sending server against a DNS whitelist. DKIM attaches a digital cryptographic signature to the email headers and body itself. DKIM survives email forwarding through mailing lists and intermediate relays where SPF typically breaks.
How often should DKIM keys be rotated?
Industry security frameworks (such as NIST and M3AAWG) recommend rotating DKIM keys every 6 to 12 months. When rotating, publish the new selector key in DNS first, verify propagation, switch your mail server to sign with the new key, and retire the old selector after 14 days.
What is DKIM Canonicalization (c=relaxed/relaxed)?
Canonicalization specifies how email headers and message bodies are normalized before calculating the cryptographic hash. The 'relaxed/relaxed' algorithm ignores minor whitespace modifications and header case alterations introduced during transit, preventing false signature verification failures.