Rotating DKIM keys with selectors

A DKIM signature names a selector (s=) and a domain (d=). The receiving server looks up the public key at <selector>._domainkey.<domain>. Rotation means publishing a second key under a new selector, switching signing to it, and then removing the old key. Because mail already in transit or in queues still carries the old signature, and because DNS answers are cached, the old key has to stay published for a while after the switch.

Who controls the key

A custom domain that uses the ITProMail selector itpro1 through the CNAME to itpro1._domainkey.itpromail.com depends on the key behind that CNAME, which ITProMail maintains. Ask support@itpromail.com before you change that record or the selector your domain signs with. The steps below apply directly if you sign with a key you generate yourself.

1. Confirm the current selector

Send a test message to a mailbox you control and read its headers. The signature looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=itpro1; c=relaxed/relaxed; ...

Note the d= and s= values. Check the published record:

dig +short CNAME itpro1._domainkey.example.com
dig +short TXT itpro1._domainkey.example.com

2. Generate a new key pair

Use 2048-bit RSA. Most receivers support it, and it is the safest choice for compatibility:

openssl genrsa -out dkim-2026q4.key 2048
chmod 600 dkim-2026q4.key
openssl rsa -in dkim-2026q4.key -pubout -outform DER 2>/dev/null | openssl base64 -A

The last command prints the base64 public key for the p= tag. Keep the private key on the signing host only, and back it up somewhere protected.

3. Publish the new selector

Choose a selector name that says when it was created, such as 2026q4. Publish the public key as a TXT record:

2026q4._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Long TXT values are split into quoted strings of at most 255 characters each. Most DNS providers do this for you.

4. Verify before switching

dig +short TXT 2026q4._domainkey.example.com

The output must match the public key exactly. A truncated or mistyped p= value makes every message signed with that selector fail DKIM. Wait until the record is visible from more than one resolver before you continue.

5. Switch signing to the new key

Configure the signer to use the new selector and private key. Then send test messages and check the result in the receiving headers:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=2026q4; ...
Authentication-Results: ...; dkim=pass header.d=example.com ...

Test a few different senders or clients if you have them. A signature that passes on one path can still fail if another path rewrites the message.

6. Keep the old key during overlap

Leave the old selector published. Messages signed before the switch may still be in queues, and cached DNS answers can persist for their TTL. A week of overlap is a common minimum. Some operators keep the old key for two weeks or longer.

7. Retire the old selector

Remove the old TXT or CNAME record only after the overlap period and only if no mail signed with it appears in your reports. Keep a copy of the old private key offline for the period you may need to verify archived mail, then delete it according to your retention policy.

Checklist

• New key is 2048-bit RSA, and its private key is readable only by the signer.
• The new TXT record reads back exactly through dig.
• Test messages show dkim=pass and the new s= value.
• The old selector stays published through the overlap.
• DMARC reports show no new DKIM failures after the switch. See DMARC reports.