DKIM Key Rotation and Selector Hygiene: 2048‑Bit Keys, Two Selectors and No Surprises

How DKIM works, briefly

DomainKeys Identified Mail, DKIM, is defined in RFC 6376. When your mail server or a sending service sends a message, it adds a DKIM-Signature header made with a private key. The header names your domain (d=) and a selector (s=). The receiving server looks up a DNS record named selector._domainkey.yourdomain, fetches the public key, and checks the signature. Together with SPF and DMARC, it helps receivers trust that a message from your domain is really yours. Our article on SPF, DKIM and DMARC covers the full picture.

What a selector is for

The RFC explains that selectors subdivide the key namespace of a domain. They allow several keys at once, for different services or offices, and they make it possible to replace public keys routinely. A domain might use one selector for its mail platform, one for its newsletter service and one for its invoicing system. Each has its own key, so one can be changed without touching the others.

Key length

RFC 6376 originally required at least 1024 bits for long-lived keys. RFC 8301, published in 2018, raised the bar: signers MUST use RSA keys of at least 1024 bits and SHOULD use at least 2048 bits, verifiers must be able to validate keys from 1024 to 4096 bits, and the SHA-1 signing algorithm must not be used. In practice: use 2048‑bit RSA keys with rsa-sha256 for new keys, and replace any remaining 1024‑bit keys. 4096‑bit keys are possible but, as RFC 6376 notes, large keys cost more CPU and can be awkward in DNS, and they give little extra benefit for email. RFC 8463 adds Ed25519‑SHA256 signatures, but support among receivers is not universal, so many senders keep RSA as the primary.

The two-selector rotation

RFC 6376 itself describes the method. If a domain wants to move from selector january2005 to february2005, it makes sure both public keys are published at the same time for the transition period, during which mail in transit may still be verified. At the start, the outbound servers are set to sign with the new private key. At the end, the old public key is removed. In steps:

• Generate a new 2048-bit key pair on the signing system (or ask your provider to issue one). Keep the private key where only the signer can read it.
• Pick a new selector name, for example the year and month, such as 2026nov. Do not reuse an old selector name.
• Publish the new public key in DNS as a TXT record at the new selector. Check that it is visible from several resolvers.
• Switch the signer to the new selector and private key. Send test messages to a mailbox that shows authentication results, and check that the DKIM result passes and the d= domain matches your From domain for DMARC.
• Leave the old record in place for a while. Mail that was signed before the switch can still be verifying when it is delivered, queued or retried; a few days is common practice for a long overlap, and the exact figure is your choice.
• Remove the old record, or revoke it by publishing it with an empty p= value; RFC 6376 says there is no defined difference in meaning between the two.
• Write down the date, the selector and the next rotation date.

Why not just replace the key under the same selector

The RFC's operations note answers this: reusing a selector with a new key makes it impossible to tell whether a message failed because the key is no longer valid or because it was forged. A receiver or your own DMARC reports will show failures with no clear cause, and mail already in transit signed with the old key will fail. A new selector keeps the story clear.

Selector hygiene

• Inventory: list every DKIM selector in DNS and match each one to a sending service. Your DMARC aggregate reports show which selectors are actually signing mail.
• Remove records for services you no longer use. An unused key that a former vendor still holds can sign mail as your domain.
• Do not name selectors after people, and consider the privacy of per-user selectors, which the RFC warns can allow outsiders to harvest information.
• Never use the testing flag (t=y) as a permanent state. In RFC 6376, receivers are told not to treat testing-mode signers differently from unsigned mail, so it only matters for your own tracking.
• Set a rotation schedule, for example once a year, and also rotate right away when a vendor relationship ends, an administrator leaves, or you suspect the private key was exposed.
• Where a provider manages DKIM for you (Microsoft 365, Google Workspace, a marketing platform), use its own rotation feature and follow its steps; Microsoft documents how to rotate DKIM keys for custom domains in its Defender documentation.

Watch the DNS details

A 2048‑bit public key is longer than the 255‑character limit of a single string in a DNS TXT record, so it has to be split into several quoted strings in one record. Many DNS control panels do this on their own, some need you to do it, and a few mangle it. After every change, look the record up and test it, rather than assuming. Also watch for CNAME-based DKIM setups where the vendor owns the key: there the vendor rotates it and your job is to keep the CNAME intact.

We can review the DKIM, SPF and DMARC setup for your domains, build the selector inventory and run the first rotation with you, as scoped and authorized work.

Sources

• RFC 6376, DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301, Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 8463, A New Cryptographic Signature Method for DKIM (Ed25519-SHA256)
• Microsoft Learn, Use DKIM to validate outbound email sent from your custom domain

This article is general information, not advice for your environment. Test every DNS and signing change before relying on it, and follow your email provider's current documentation. Last reviewed November 9, 2026.

Next article

Next · RegulationCMMC Level 2 and Your SPRS Score, Explained for Small Defense SubcontractorsIf you handle controlled unclassified information for a defense prime, two things decide whether you keep the work: your score in the Supplier Performance Risk System (SPRS) and your CMMC status. Here is what the rules say, in order, with the primary sources.9 min read

Related reading

• SecurityReading DMARC Aggregate Reports in Practice: XML Fields, Alignment vs Pass, Unknown Senders, Forwarding and ARC8 min
• SecurityBIMI, VMC and CMC Explained: A Logo in the Inbox, What It Needs and What It Does Not Prove7 min