DKIM adds a digital signature to every outgoing message: the mail server signs with a private key and the receiver verifies the signature with the public key published in DNS. A valid signature proves the message was not altered in transit and came from a server your domain authorises. Many organisations set DKIM up once and keep the same key for years, while administrators change, servers move and copies of the key end up in old backups. Rotating the key on a schedule is simply good hygiene.
Selectors make rotation possible
A domain can publish several DKIM keys at once, distinguished by selector. The public key lives in a TXT record named selector._domainkey.domain, and the s= tag in the DKIM-Signature header tells receivers which one to fetch.
DKIM-Signature: v=1; a=rsa-sha256; d=example.uz; s=mail2025; c=relaxed/relaxed; ...Instead of overwriting the old key, you publish the new one under a new selector, keep both for a while and switch signing over. No message fails verification along the way.
When to rotate
There is no mandatory interval, but common mail security guidance suggests at least once a year, more often for heavy senders. Rotate immediately if you suspect a server compromise or key leak, when an administrator or contractor with key access leaves, when mail moves to a new server or service, or when upgrading from a 1024-bit key. 1024-bit RSA is considered weak today, so generate 2048-bit keys; 4096-bit keys are very long for DNS and cause problems with some systems.
Generating the new key pair
openssl genrsa -out mail2026.private 2048
openssl rsa -in mail2026.private -pubout -outform der | openssl base64 -A > mail2026.pub
# or, with OpenDKIM installed:
opendkim-genkey -b 2048 -d example.uz -s mail2026Restrict the private key to the mail service (for example chmod 600) and never email it or commit it to a repository. On managed hosting, the control panel usually regenerates DKIM for you.
The four rotation steps
- Publish the new
mail2026._domainkeyTXT record and leave the old one in place. - Verify with
digthat every authoritative name server returns it. - Switch signing to the new selector and private key, then reload the mail service.
- Revoke the old key a few days later by publishing an empty
p=or removing the record.
dig +short TXT mail2026._domainkey.example.uz
mail2025._domainkey.example.uz. IN TXT "v=DKIM1; p="The delay matters because queued and delayed messages still carry the old signature, and some systems re-verify after delivery.
Long keys and TXT strings
A 2048-bit public key is about 400 characters, while a single TXT string is limited to 255, so the key is split into several quoted strings that resolvers join. Most DNS panels handle this, but when editing a zone file by hand make sure no stray spaces or line breaks end up inside the key; one wrong character breaks every signature.
Example: a private clinic in Samarkand
A Samarkand clinic emails lab results and appointment reminders. Its mail was set up by a contractor with a 1024-bit key. When the contract ends, the new administrator creates a 2048-bit key under selector clinic2026, publishes it, waits a day, switches signing and sends a test to Gmail, where "Show original" reports DKIM pass with s=clinic2026. The old selector is revoked a week later.
After the switch
Check the Authentication-Results header for dkim=pass and the new selector, and watch DMARC reports for a rise in DKIM failures, which usually means some other system, such as a website form on a separate server, still signs with the old key. On sayt.uz hosting the DKIM record for company mail is visible in the cabinet's DNS section, so you can compare it with what dig returns.