A DKIM key configured years ago still verifies email, and the protocol raises no objections. This was an intentional design choice: DKIM's authors expected operators to update keys periodically, but left the timing entirely up to them.
Below, we trace this specification from the original RFCs and examine the real-world state of mail domains today.
DKIM Allows (but doesn't require) Rotation
Published in May 2007, RFC 4871 introduced the first DKIM specification. RFC 6376 superseded it in September 2011.
Both standards treat signing keys as standard DNS TXT records, leaving updates entirely up to domain operators.
In fact, RFC 6376 (§3.3.3) uses key rotation to justify modest key sizes:
RFC 6376 (§3.3.3): "Keys can be replaced on a regular basis; thus, their lifetime can be relatively short."
While the designers assumed operators would rotate keys, they never mandated it.
The standard only defines seven key-record tags (§3.6.1): v, h, k, n,
p, s, and t.
The x= Tag
Some might point to DKIM's expiration tag, x=. However, this tag applies to
individual messages, not published keys.
RFC 4871 (§3.5) defines x= as "Signature Expiration" inside the
DKIM-Signature header attached to outgoing email. It expires only that
specific message's signature.
Key Rotation Schedules
Recommendations to "rotate keys every N months" do exist outside the RFC.
RFC 8301 (January 2018) raised minimum key sizes. It requires at least 1024-bit RSA keys and recommends 2048-bit.
Nevertheless, it says nothing about rotation intervals. The familiar six-month rotation window seems to come from the M3AAWG DKIM Key Rotation Best Common Practices (2019).
The lack of guidance on key management explains why a key generated in 2008 can still sign corporate email in 2026. For instance, some compromised Debian OpenSSL keys are still signing email today.
Widespread Abandonment in Domain Records
Security researcher Hanno Böck summarized the consequence in 2024:
Hanno Böck: "DKIM has no requirement to rotate keys. It appears that a sizeable number of companies configured DKIM TXT records in 2007 and never changed them."
Our 2026 audit confirms this pattern. We scanned 111,010 Korean mail domains
across 11 common selectors and found that 8,559 domains published DKIM keys,
mostly under predictable selectors like google, default, or selector1.
Of those 8,559 domains:
- 53% sign with legacy 1024-bit keys.
- 45% use 2048-bit keys.
- 17 domains publish corrupt records that fail verification outright.
While DNS records lack creation timestamps, 1024-bit keys on default selectors
point to set-and-forget configurations—keys generated during initial setup and
abandoned. Worse, 16 of the 17 corrupt records operated under a DMARC policy of
p=none or no policy at all, causing dead keys to fail silently without
alerting operators.
Set Your Own Rotation Schedule
Rotating DKIM keys is simple:
- Generate a new key under a fresh selector.
- Point your mail signer to the new selector.
- Remove the old DNS record once active messages clear transit.
Establish a clear internal policy such as rotating keys every six months.
Also, if you end up rotating a 1024-bit key, take the opportunity to upgrade it to 2048-bit or above.
When did your organization last publish a new DKIM selector? Is an outdated record still active in your DNS?
References
- RFC Editor — RFC 4871: DomainKeys Identified Mail (DKIM) Signatures (May 2007)
- RFC Editor — RFC 6376: DomainKeys Identified Mail (DKIM) Signatures (September 2011)
- RFC Editor — RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM (January 2018)
- M3AAWG — DKIM Key Rotation Best Common Practices (March 2019)
- Hanno Böck — 16 years of CVE-2008-0166 - Debian OpenSSL Bug - Breaking DKIM and BIMI in 2024 (first published 12 May 2024)
- Panke — A 2008 Debian Bug Still Signs Corporate Email (15 September 2026)
- Panke — DKIM scan of 111,010 Korean mail domains (first-party measurement, September 2026)
Instagram