Last updated: July 2026

In short: A DKIM selector subdivides a domain’s key namespace, allowing multiple public keys to coexist simultaneously in DNS. It is the core mechanism enabling third-party sending platforms and zero-downtime key rotation.

When your mail server applies a cryptographic DomainKeys Identified Mail (DKIM) signature to an outgoing email, it attaches the DKIM-Signature header to the message. Inside this header, the d= tag specifies your signing domain and the s= tag declares the exact selector used to sign the message. Receiving servers require both pieces of information to locate and fetch the correct public key from your DNS records.

Subdividing the key namespace

Under RFC 6376, selectors subdivide the key namespace (To support multiple concurrent public keys per signing domain, the key namespace is subdivided using "selectors".).

Without selectors, a domain would only be able to publish a single public DKIM key under _domainkey.example.com. However, modern organizations frequently send email from multiple independent platforms simultaneously—such as Google Workspace, a transactional email API, and a marketing automation platform. The selector (s=) solves this by creating unique subdomains beneath _domainkey.

For instance, if an incoming message’s signature header specifies d=example.com and s=mail2026, the receiving server queries the following TXT record:

mail2026._domainkey.example.com

A standard public key record returned by that DNS lookup looks like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Concurrent keys and zero-downtime rotation

Selectors enable two critical administrative practices:

  • Platform isolation: You can assign isolated selectors to each service provider, such as google._domainkey for your primary mailbox provider and crm._domainkey for your customer relationship system.
  • Seamless key rotation: Security best practices require rotating cryptographic keys regularly. With selectors, you can publish a new key under a fresh selector (such as s=2026b), activate signing on your mail server, and leave the old selector (s=2026a) active in DNS until all in-transit mail has been delivered and verified.

Optional tags within the key record

Beyond the selector string pointing to the DNS record, the published TXT string itself can contain optional control tags. According to RFC 6376, the s= tag (s= Service Type (plain-text; OPTIONAL; default is "*")) restricts the record to specific service types. Additionally, you can safely deploy new keys using testing mode: the t=y flag marks a domain in testing mode, and verifiers must not treat messages from signers in testing mode differently from unsigned email, even if the signature fails verification. A testing record is written as:

v=DKIM1; k=rsa; t=y; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Verifying your selectors

To confirm that your DKIM selectors resolve cleanly in DNS and that your public key string is syntactically valid, test your domain using the free MXAudit scanner.

To explore further concepts and technical details, check out the DKIM hub and practical walkthroughs like IONOS DKIM setup.

Further reading