# DKIM Key Rotation > M3AAWG DKIM Key Rotation BCP (rev. March 2019) — semiannual rotation cadence, selector naming schemes, the two-live-keys workflow, p= retirement, CNAME/subdomain delegation for third parties, and rotation auditing. Source: emailmarketing.net — https://emailmarketing.net/learn/authentication/dkim-key-rotation If you sign mail with DKIM, your keys need to be replaced on a schedule. M3AAWG's *DKIM Key Rotation Best Common Practices* recommends how often and how. The document is M3AAWG078, first published in 2013 and revised in March 2019 (reference URL m3aawg.org/DKIMKeyRotation). The 2019 revision changed the recommended cycle from **quarterly to every six months** and reworked the convention for naming selectors. This guidance covers the practice of rotation. For how DKIM itself works (the syntax of signatures and key records, and the algorithms), see [DKIM](https://emailmarketing.net/learn/authentication/dkim). ## Why rotate - DKIM public keys are published in DNS, where anyone can inspect them, which makes them a target. Keeping the active lifetime of a key pair short limits the damage if a key is cracked **or stolen** from a compromised signing system. - Key length and cracking (RSA, according to the document): 512-bit keys can be cracked in hours. Zachary Harris cracked one in ~72 hours for ~$75 of AWS computing in 2012, and 512-bit keys were formally deprecated by RFC 8301 in Jan 2018. A 1024-bit key is "at the edge of attack" for general-purpose systems. **A 2048-bit key is considered immune to cracking with today's computing power.** Nation-states could crack 768-bit keys as of ~2012. - Rotating regularly builds knowledge within the organization, so an **emergency rotation outside the normal cycle** after a compromise can be done fast. (Google rotated its keys within days of the 2012 disclosure; other companies took months.) ## Cadence **Rotate at least every six months.** M3AAWG members concluded that rotating twice a year balances the risk of compromise against the operational effort, for organizations with complex mail flows and dependencies on third parties. Organizations with simpler flows can rotate more often: quarterly rotation lowers the cracking risk further, if operations allow it. Yearly rotation is discouraged, because it raises the risk of compromise and also lets the organization's knowledge of the process fade. Pick dates that avoid business peaks, for example April and October for e-commerce. Regular rotation brings other benefits: - Departments learn to work together, since the DNS team is not the email team. - Third-party senders practice the process, so vendors work together too. - Rotation conforms with ITIL and ISO-IEC-20000, because a planned rotation is a "standard change", not an "emergency change". - It leads to automation, such as scripts that generate keys. M3AAWG stresses developing scripts twice. - It builds redundancy, with more people able to do the work. ## The rotation workflow Starting state, for a new DKIM deployment: generate **two** key pairs (≥1024 bits), publish both public keys in DNS, wait for DNS propagation, then sign with private key 1. Key 2 is ready as "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 ``` At each rotation: 1. Generate the next key pair (key 3) and publish its public key in DNS. Wait for propagation before you use it. 2. Switch the signer from private key 1 to private key 2. 3. Leave public key 1 in DNS **unchanged for a minimum of 7 days, and up to 30 days**, so receivers can still validate mail that is in transit or validated later. 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 that the key was retired on purpose. Repeat the cycle: 1→2, 2→3, 3→4 and so on. After the rotation from key 2 to key 3, the records look like this: ``` 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: - Put the key activities (generation, deprecation) on a recurring operational calendar. The steps of a rotation can **all happen on a single day**: add key n+2 and retire key n−1 on the same day you switch signing, instead of spreading the work over several days. The timeline only has to leave time for DNS propagation before you sign with a new key, and time for mail in transit to be delivered before you retire an old one. - DKIM signatures support an expiration time. This is `x=` in the signature under RFC 6376; the text of the BP calls it `t=`, which RFC 6376 defines as the signature timestamp. An expiration time can ensure that signatures do not 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, so **fetching records over EDNS0 or TCP** is required. - The BP quotes the operations advice of RFC 4871: do not sign with a key whose selector will be revoked before verifiers can validate the signature. When you rotate, start signing with the new key immediately, and keep the old public key "for a reasonable validation interval." ## Selector naming schemes A selector should carry enough information to make rotation easier. **Never reuse a selector name.** Reuse makes old messages fail validation against the new key value, and it breaks receivers that have cached the old record. A suggested convention: start with the responsible department or stream, and include the key length and the planned activation date. For example, **`sales-201309-1024`** means the "sales" stream, a key put into active use in September 2013, and a 1024-bit key. A selector may contain the key length, the date, a random string, or a combination. Selectors that carry a date make auditing possible (see below). After a rotation on April 1, every message you sample should be signed with a selector dated in the style of `20130401`. ## Third-party and delegated domains **The request to rotate must come from the owner of the organizational domain**, usually the ESP's customer. M3AAWG does not recommend that third parties start rotation for their customers. Instead, teach customers to rotate according to this BP. Never share the same DKIM keys across several entities. There are three models of delegation. ### 1. Key delegation via domain or subdomain (keys held by the customer) The customer generates the key pairs, publishes the public keys in its domain (or a subdomain), and securely sends the private key to the third party, **only by encrypted email (GPG) or SFTP. Never send a private key in unencrypted email or by any other means that can be intercepted, and never save private keys locally.** This model needs coordination at every rotation. In a variant, the third party generates the key pair and gives the public key to the customer to publish in DNS. No private key is transferred, but the customer must confirm the key parameters (such as size) and agree on the date the key rotates out. ### 2. Key delegation via delegated subdomain The customer delegates a subdomain to the third party, which creates all the records itself. This is flexible, but it adds a risk unrelated to rotation: **the third party could publish a DMARC record on the subdomain that overrides the organizational policy.** Audit all delegated domains. ### 3. Key delegation via CNAME The domain holder publishes **three CNAME records** in the main domain, pointing at records the third party controls. The third party keeps one key valid while it rotates 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. Most ESPs use this model. The [Sending Domains BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-sending-domains) also describes the three delegation models. ## Preparation and readiness - **Take an inventory** of all mail streams (transactional, marketing, and conversational or employee mail), and identify who manages each domain and each stream. Every one of them has a stake in generating, publishing and using DKIM keys. Check mergers and acquisitions for streams you do not know about. **DMARC at `p=none` with aggregate (RUA) reporting is a useful way to discover streams**: the daily reports show what mail is being sent, or claims to be sent, with valid or missing DKIM signatures. - **Discuss the objectives with all parties.** Nobody, including third-party vendors, should be surprised when it is time to rotate. - **Stakeholders** include internal email administrators, DNS administrators and support staff, plus the customer and technical contacts at third-party vendors. Document how changes to a stream are requested (a ticket, an official request, a contract clause and so on). - **Be ready for a disaster**, meaning an unscheduled emergency rotation at any time. If you **publish the next public key in DNS in advance**, an emergency rotation needs action only from the mail administrator, the smallest possible group of people. ## Auditing - Schedule an audit shortly after each rotation (for example, a week later) to confirm that it happened and succeeded. - Keep a data store of rotations. For every mail stream, record all domains and subdomains, all selectors with the time ranges when they were active, and the responsible staff. - Audit by comparing the `d=` and `s=` values in the signatures of sampled messages with the values expected in the data store. A strict naming scheme for selectors, especially one that includes dates, simplifies ad-hoc audits and makes **automated auditing** possible. A wrong selector both reveals the failed rotation and, with a good naming scheme, tells you where to look. ## References The BP cites: RFC 6376 (DKIM signatures), RFC 5585 (service overview), RFC 5863 (deployment and operations), RFC 8301 (update on algorithms and key usage), 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).