DKIM (DomainKeys Identified Mail): RFC 6376 Cryptographic Signing, Selectors & Key Rotation

Cryptographic Signing & Verification Lifecycle

DomainKeys Identified Mail (DKIM) solves the fundamental vulnerability of plain text SMTP: the susceptibility of messages to tampering and forging in transit. Unlike SPF, which binds authentication to a transient IP connection, DKIM cryptographically anchors authentication directly to the message payload.

The operational lifecycle consists of two discrete stages:

1. Outbound Signing: The sending MTA (e.g. PowerMTA or KumoMTA) computes a SHA-256 cryptographic hash of the message body (and critical headers), signs the hash using a private key stored securely on the server, and inserts a DKIM-Signature header.
2. Inbound Verification: The receiving MX server extracts the signing domain (d=) and selector (s=) from the header, fetches the corresponding public key from DNS at <selector>._domainkey.<domain>, and validates the digital signature against the received message content.

Because the signature survives intermediary forwarding hops (unlike IP-based SPF), DKIM represents the most resilient authentication mechanism in high-volume email delivery.

Deconstructing the DKIM-Signature Header

A production DKIM header contains critical key-value tags defined by RFC 6376:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s202610;
  t=1730000000; x=1730604800;
  h=from:to:subject:date:message-id:feedback-id:mime-version:content-type;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=dB9s...[2048-bit Base64 Encoded Digital Signature]...

Canonicalization Modes (c=relaxed/relaxed vs simple)

Email transit frequently alters whitespace, line wrapping, and header casing as messages pass through MTAs and security gateways. Canonicalization (the c= tag) specifies how whitespace is normalized before hashing:

• simple: Tolerates zero modifications. Any alteration in whitespace, blank lines, or casing invalidates the signature. Extremely brittle; strongly discouraged for body hashing.
• relaxed: Converts sequences of whitespace to a single space, folds whitespace within header lines, and ignores trailing line whitespace. This allows benign MTA modifications without breaking cryptographic integrity.

Universal Production Recommendation: Always configure c=relaxed/relaxed (relaxed headers, relaxed body) on all sending MTAs.

Key Lengths & Algorithms: RSA-2048 vs. Ed25519

The cryptographic strength of your DKIM keys directly impacts both security and deliverability:

• RSA-1024 (Deprecating): Can be factored in cloud computing environments. In 2024, Google and Yahoo officially deprecated 1024-bit keys. Messages signed with 1024-bit RSA may be flagged or fail sender guidelines.
• RSA-2048 (The Enterprise Standard): Highly secure and universally supported by 100% of global mailbox providers. The public key requires a 400+ character DNS TXT record, necessitating DNS TXT string chunking in BIND and cPanel zones.
• Ed25519 (RFC 8463): Modern elliptic curve cryptography. Offers superior security with tiny keys (around 44 characters), easily fitting inside a single DNS string. Supported by Gmail and Fastmail, but still partially unsupported by certain legacy enterprise gateways.

Selector Architecture & DNS Delegation

A selector is an arbitrary string that points to a specific public key. Because selectors live beneath _domainkey, a domain can publish dozens of concurrent keys without conflict:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzv5h...[2048-bit Public Key]...IDAQAB

For cloud services, CNAME delegation provides automated key management without exposing private keys:

s1._domainkey.example.com.  CNAME  s1._domainkey.autosmtp-relay.com.

Zero-Downtime Key Rotation Sequence

Cryptographic hygiene requires rotating DKIM keys every 6 to 12 months. Executing rotation without causing signature validation failures on in-flight emails requires a strict 4-step sequence:

1. Generate New Keypair with New Selector: Create a new RSA-2048 keypair assigned to a new selector (e.g., k2027q1).
2. Publish New Public Key in DNS: Deploy the public key TXT record at k2027q1._domainkey.example.com. Wait for DNS TTL propagation (minimum 24–48 hours).
3. Switch Sending MTA to New Selector: Update your MTA configuration (PowerMTA, KumoMTA) to sign outbound mail using the new private key and new selector.
4. Retire Old Public Key (After 7 Days): Keep the old public key in DNS for at least 7 days to allow messages queued on destination MTAs or delayed in bounce cycles to verify successfully before deleting the old record.

Top 5 Production DKIM Verification Failures