Email DKIM Selector

Definition

A DKIM selector is a label used to identify which public key a receiving server should use to verify a DKIM-signed email. The selector is specified in the DKIM-Signature email header field (s= tag) and maps to a DNS record of the format {selector}._domainkey.{domain}. For example, if a message is signed with selector s1, the receiving server looks up s1._domainkey.example.com to retrieve the public key for verification. Selectors allow organisations to have multiple active signing keys simultaneously and to rotate keys without invalidating messages signed with the old key.

DKIM key rotation is the primary operational reason for using selectors. Security best practice recommends rotating DKIM keys every 6-12 months. Without selectors, rotating the key would require: publishing the new key, then changing the signing key on all senders. Messages signed during the transition period before all senders have updated would fail verification because the published key would be out of date. With selectors, the process becomes: publish the new key under a new selector (e.g., s2), update signers to use the new selector, keep the old selector (s1) active for verification of already-sent messages, and eventually remove the old selector after all signed messages have been delivered (typically 1-2 weeks).

Multi-selector strategies enable different streams of email to use different signing keys. A common approach is to use separate selectors for transactional and marketing email streams. This allows independent key rotation for each stream, limits the blast radius if a key is compromised (only messages signed with that specific key are affected), and enables domain-wide DMARC reporting to attribute authentication failures to specific streams. Some organisations use time-based selectors (e.g., 2024, 2025) that indicate when the key was introduced, simplifying key lifecycle management.

Best Practices

Use at least two selectors in rotation at all times. Maintain a current active selector (used for signing) and a previous selector (kept for verification of already-sent messages). When rotating, add a new selector, migrate signing to it, keep the old selector for verification, and remove the old selector after the verification overlap period (typically 14-30 days).

Use descriptive, systematic selector naming conventions. Adopt a convention that makes selector purpose and lifecycle clear. Examples: s1, s2, s3 for sequential rotation; 2024q1, 2024q2 for time-based naming; txn, mktg for stream-based naming. Avoid generic names like default that provide no lifecycle information. Document the naming convention for your operations team.

Rotate DKIM keys at least every 12 months, and immediately after any suspected key compromise. Regular rotation limits the window of vulnerability if a private key is compromised. In case of compromise, rotate immediately: publish a new selector key, update all signers, and remove the compromised selector after the overlap period. Use a 2048-bit or higher RSA key or an Ed25519 key for stronger security.

Monitor DKIM verification success rates per selector. Track the percentage of messages signed with each selector that pass DKIM verification at receiving servers. A declining success rate for a selector may indicate: the selector's DNS record has been removed prematurely, the DNS record is misconfigured, or the private key on a signer is mismatched with the public key in DNS.

Automate selector management in your key rotation workflow. Manual selector management is error-prone, especially when rotating across multiple servers or ESPs. Use automation scripts or tools that: generate new key pairs, publish the DNS records, update signer configurations, and manage the lifecycle of old selectors. Document the automation process and have a manual fallback procedure.