Every DKIM signature names a selector. It looks like a small detail, but selectors are what make it possible to run several DKIM keys for the same domain at the same time, and to replace a key without a moment of failed authentication.
If you have not met DKIM yet, start with what DKIM is and how it works.
What a selector is
A selector is a label that tells the receiver which public key to fetch. It appears as s= in the DKIM-Signature header, and it becomes part of the DNS name:
s=mail2026 -> mail2026._domainkey.yourdomain.comSo a domain can publish many keys side by side:
mail2026._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=KEY_A..."
newsletter._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=KEY_B..."
helpdesk._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=KEY_C..."Each sending system signs with its own private key and its own selector. Your mail server, your newsletter tool and your helpdesk never need to share a secret, and removing one of them is a matter of deleting one DNS record.
Choosing selector names
Selectors are free text made of letters, digits and hyphens. Good names make rotation easier:
- Include a date:
2026a,2026-10,mail2026q4. - Or name the system:
crm,news. - Avoid names that give away nothing when you read them six months later, such as
selector1, unless a vendor requires them.
Some providers fix the selector names (Microsoft 365, for example, uses selector1 and selector2, and publishes them as CNAME records). Follow the provider's instructions exactly.
Why rotate keys at all
A DKIM private key is a long-lived secret. If it leaks, anyone can sign mail as your domain, and the signature will verify. Rotating keys limits how long a stolen or weak key is useful. Reasons to rotate:
- A regular schedule (many security guidelines suggest at least yearly, often every six months).
- An administrator with access to the key left the company.
- A server holding the private key was compromised or migrated.
- You are replacing a 1024-bit key with a 2048-bit one.
How to rotate without breaking mail
The trick is to publish the new key before you use it, and keep the old key until nothing signed with it is still in flight.
- Generate a new key pair with a new selector, for example
mail2027. - Publish the new public key in DNS at
mail2027._domainkey.yourdomain.com. Wait until it is visible (see DNS propagation). - Switch signing on your mail server or service to use the new selector and private key.
- Send a test to a mailbox you control and confirm in the headers that
dkim=passwiths=mail2027(see how to check SPF, DKIM and DMARC). - Keep the old record for a while. Messages signed earlier may still be queued, delayed or checked later. A week or two is a common grace period.
- Delete the old record when you are sure nothing uses it.
Never edit the public key of a live selector in place. For a short time some receivers will have the old key cached while your server signs with the new one, and those messages fail verification. A new selector avoids that entirely.
What happens if a key is revoked
You can mark a key as revoked by publishing the selector with an empty p= value:
mail2026._domainkey.yourdomain.com TXT "v=DKIM1; p="Receivers read this as "this key is no longer valid", which is useful if you know a private key is compromised and want signatures made with it to fail immediately.
Rotation and DMARC
DMARC only needs one aligned pass from SPF or DKIM, so a failing signature during a mistaken rotation does not always lose mail, because SPF may still pass. Do not rely on that. Treat a DKIM failure as an incident and check your DMARC reports afterwards (see how to read them).
Checklist
| Task | Done when |
|---|---|
| New key generated, 2048-bit | Private key stored safely, never emailed |
| New selector published | DNS lookup returns the key |
| Signing switched | Test message shows s= new selector with pass |
| Old selector kept | At least a week of overlap |
| Old selector removed | No traffic signed with it in reports |
How Mailions handles keys
Every domain added to Mailions gets its own DKIM key pair, and the private half is kept encrypted at rest on the server. The panel shows the public key as a ready-to-paste TXT record. If you need a key changed for a security reason, contact us and we will plan the switch with you so that the new record is published before signing moves to it.