DKIM Key Rotation

Source: M3AAWG DKIM Key Rotation Best Common Practices (M3AAWG078, 2013, revised March 2019; reference URL m3aawg.org/DKIMKeyRotation). The 2019 revision changed the recommended cycle from quarterly to every six months and reworked the selector naming convention. DKIM mechanics (signature/key record syntax, algorithms) are in DKIM; this article covers the rotation practice.

Why rotate

• DKIM public keys are published in DNS and open to inspection, making them a target. Minimizing a key pair's active lifetime contains the damage if a key is cracked or stolen from a compromised signing system.
• Key length vs. cracking (RSA, per the document): 512-bit keys crack in hours (Zachary Harris cracked one in ~72 hours for ~$75 of AWS compute in 2012; 512-bit keys were formally deprecated by RFC 8301, Jan 2018); 1024-bit is "at the edge of attack" for general-purpose systems; 2048-bit is considered immune to cracking in today's computing environment. Nation-states could crack 768-bit keys as of ~2012.
• Regular rotation builds institutional knowledge, so an emergency out-of-cycle rotation after a compromise is fast. (Google rotated its keys within days after the 2012 disclosure; other companies took months.)

Cadence

Rotate at least every six months. M3AAWG members concluded semiannual rotation balances compromise risk against operational effort for organizations with complex flows and third-party dependencies; simpler flows can rotate more often (quarterly lowers cracking risk further, if operations permit). Yearly is discouraged: it raises compromise risk and erodes institutional knowledge. Pick dates that avoid business peaks — e.g., April and October for e-commerce.

Regular rotation also delivers: cross-department effectiveness (DNS team ≠ email team), cross-vendor effectiveness (third-party senders practice the process), ITIL/ISO-IEC-20000 conformance (planned rotation is a "standard change," not an "emergency change"), automation (scripts for key generation etc. — M3AAWG twice stresses developing scripts), and redundancy/bench depth.

The rotation workflow

Starting state (new DKIM deployment): generate two key pairs (≥1024 bits), publish both public keys in DNS, wait for propagation, sign with private key 1. Key 2 sits ready ("next in line").

dkim1._domainkey.example.com   ← active public key 1, used to sign
dkim2._domainkey.example.com   ← public key 2 published for future use

Each rotation:

1. Generate the next key pair (key 3) and publish its public key in DNS; wait for propagation before use.
2. Switch the signer from private key 1 to private key 2.
3. Keep public key 1 in DNS unchanged for a minimum of 7 days, up to 30 days, so receivers can still validate mail in transit or deferred validation.
4. Then retire key 1 by setting the record's p= field to empty ("v=DKIM1; p="). Do not delete the selector record — the empty p= signals the key was intentionally retired.

Repeat 1→2, 2→3, 3→4… Example after rotating key 2 → 3:

dkim1._domainkey.example.com   ← retired ("p=")
dkim2._domainkey.example.com   ← still validates old mail for 7–30 days
dkim3._domainkey.example.com   ← signs current mail
dkim4._domainkey.example.com   ← ready for future use

Operational notes:

• Map key activities (generation, deprecation) onto a recurring operational calendar. Steps can be aligned to a single day per rotation (add key n+2 and retire key n−1 on the same day you switch signing) instead of spread over several days — the timeline just has to leave DNS-propagation time before signing with a new key, and in-transit-delivery time before retiring an old one.
• DKIM signatures support an expiration time (t= in the signature, i.e., x= semantics per the BP's "expiration" note); it can ensure signatures don't outlive the rotation period — but only if rotation is guaranteed to happen before the signatures expire.
• DNS servers must support long TXT records for ≥1024-bit keys: EDNS0 or TCP-based record fetches are required.
• RFC 4871 operations advice quoted in the BP: don't sign with a key whose selector will be revoked before verifiers can validate; on rotation, start signing with the new key immediately and retain the old public key "for a reasonable validation interval."

Selector naming schemes

The selector should carry enough information to facilitate rotation. Never reuse selector names — reuse makes old messages fail re-validation against the new key value and breaks receivers with stale cached records.

Suggested convention: prepend the responsible department/stream, and include key length and the planned activation date — e.g., sales-201309-1024 = "sales" stream, rotated into active duty September 2013, 1024-bit key. A selector may contain key length, date, and/or a random string.

Date-bearing selectors enable auditing (below): after an April-1 rotation, every sampled message should be signed with a selector containing 20130401-style dating.

Third-party and delegated domains

The rotation request must come from the organizational domain owner (usually the ESP's customer). M3AAWG does not recommend third parties initiate rotation for customers — instead, educate customers to run rotation per this BP. Never share the same DKIM keys across several entities.

Three delegation models:

1. Key delegation via domain/subdomain (customer-held keys)

Customer generates the key pairs, publishes public keys in their domain (or subdomain), and securely transmits the private key to the third party — encrypted email (GPG) or SFTP only. Never send a private key in unencrypted email or by any interceptable means; private keys should never be saved locally. Requires recurring coordination each rotation. Alternate: the third party generates the pair and hands the public key to the customer for DNS publication — no private-key transfer, but the customer must confirm key parameters (size, etc.) and agree on the rotation-out date.

2. Key delegation via delegated subdomain

Customer delegates a subdomain to the third party, which creates all records itself. Flexible, but adds risk unrelated to rotation: the third party could publish a DMARC record on the subdomain overriding the organizational policy — audit all delegated domains.

3. Key delegation via CNAME

Domain holder publishes three CNAME entries in the main domain pointing at records the third party controls; the third party keeps one key valid while rotating the others (key_1 expired → key_2 signing → key_3 next in line):

key1._domainkey.example.com  CNAME  key1.example.com.acme.com
key2._domainkey.example.com  CNAME  key2.example.com.acme.com
key3._domainkey.example.com  CNAME  key3.example.com.acme.com

key1.example.com.acme.com  TXT  "v=DKIM1; p="            (expired)
key2.example.com.acme.com  TXT  "v=DKIM1; p=ADfe34556…"  (signing)
key3.example.com.acme.com  TXT  "v=DKIM1; p=A783Fg4556…" (next)

The third party can then rotate on its own schedule without touching the customer's DNS again. (This is the model most ESPs use; the three delegation models are also treated in the Sending Domains BCP.)

Preparation and readiness

• Inventory all mail streams (transactional, marketing, conversational/employee) and identify who manages each domain and each stream — every one is a stakeholder in generating, publishing, and using DKIM keys. Audit mergers and acquisitions for unknown streams. DMARC p=none with RUA aggregate reporting is a useful stream-discovery tool — daily reports show what mail is being sent (and purportedly sent) with valid vs. missing DKIM signatures.
• Discuss objectives with all parties — nobody, including third-party vendors, should be surprised when rotation time comes.
• Stakeholders: internal email admins, DNS admins, support personnel, plus customer/technical contacts at third-party vendors; document how stream modifications are initiated (ticket, official request, contract clause…).
• Disaster readiness: be prepared for an unscheduled emergency rotation at any time. Pre-publishing the next public key in DNS means an emergency rotation only requires action by the mail administrator — the smallest possible set of people.

Auditing

• Schedule an audit shortly after each rotation (e.g., one week later) to confirm it happened and succeeded.
• Maintain a rotation data store: for every mail stream, all domains/subdomains, all selectors with activity time ranges, and responsible personnel.
• Audit by comparing the d=/s= values in sampled message signatures against expected values in the data store. A strict selector-naming scheme (especially date-bearing) streamlines ad-hoc audits and enables automated auditing; a wrong selector both flags the failed rotation and (with a good naming scheme) tells you where to look.

References cited by the BP

RFC 6376 (DKIM signatures), RFC 5585 (service overview), RFC 5863 (deployment/operations), RFC 8301 (algorithm/key-usage update), RFC 3766 and keylength.com (key strength), M3AAWG Best Practices for Implementing DKIM To Avoid Key Length Vulnerability (rev. July 2017), and the Wired article "How a Google Headhunter's E-Mail Unraveled a Massive Net Security Hole" (Oct 24, 2012).