What Is a DKIM Selector?

DomainKeys Identified Mail (DKIM) is an email authentication system that uses cryptographic signatures to verify that messages come from an authorized sender and haven’t been altered. A crucial component of DKIM is the DKIM selector, which plays a key role in how DKIM works.

DKIM selector explanation

In simple terms, a DKIM selector is a text string used to identify a particular DKIM key pair (private/public key) in use for signing email. It is included in the header of an outgoing email and helps receiving mail servers find the correct public key in DNS to verify the email’s signature.

The selector is specified in the s= tag of the DKIM‑Signature header, and it serves two important roles:

• on the sending side it tells the mail server which private key to use,
• and on the receiving side it tells the mail server which public key to fetch from DNS.

In essence, the DKIM selector acts as a namespace or label for a DKIM key, allowing you to have multiple DKIM keys under one domain without conflict.

When you publish your DKIM public key in DNS, you include the selector as part of the record’s name. The general format is:

<selector>._domainkey.<yourdomain>

For example, if your selector is mail and your domain is example.com, the DKIM TXT record’s name will be mail._domainkey.example.com. The content of that DNS TXT record will contain the public key (along with some metadata like the version and key type).

A practical example of two DKIM DNS records on the same domain could be:

• selector1._domainkey.example.com – contains public key 1
• selector2._domainkey.example.com  –  contains public key 2

Each email’s DKIM‑Signature header will reference one of these selectors (e.g., s=selector1 or s=selector2), telling the receiver which public key to use for verification

Why are DKIM selectors used

They allow domain owners to use multiple concurrent DKIM keys or to rotate keys seamlessly.

For instance, you might use one DKIM selector/key for your application’s transactional emails and another for your marketing emails or if you use two different email service providers. Each provider can manage its own key pair under a unique selector, and your DNS can host both public keys.

Multiple selectors are also used for DKIM key rotation  –  e.g., you generate a new key (new selector) every year and decommission the old one, without any email downtime. These practices improve security and prevent any single key from being a single point of failure.

Only one key is used to sign any given message (the selector in the signature tells you which one), but having multiple available keys gives you flexibility in operations.

How DKIM Selectors Work

When setting up DKIM, an organization chooses a selector string (it can be any arbitrary name, e.g. “mail”, “s1”, “2023key”) and configures their mail server to use that selector when signing emails. The mail server adds the selector to all outgoing email signatures as mentioned above (s=<selector> in the DKIM‑Signature header). On the DNS side, the domain owner creates a TXT record at <selector>._domainkey.<domain> containing the public key portion of the DKIM key pair

When an email is received, the receiver’s mail server does the following to validate DKIM:

1. It parses the DKIM‑Signature header in the email and extracts the domain (d= tag) and selector (s= tag).
2. It constructs a DNS query to <selector>._domainkey.<d= domain> to retrieve the DKIM TXT record.
3. It then uses the public key from that DNS record to verify the digital signature in the email header.

If the public key from DNS successfully verifies the signature, the DKIM check passes, confirming that the message was indeed signed by the legitimate domain and wasn’t tampered with. If the key can’t be found or the signature doesn’t match, DKIM verification fails. Without the correct selector, the receiving server wouldn’t be able to find the right key in DNS – which is why the selector is integral to DKIM functioning.

Related terms

In the broader context of email authentication, DKIM is one of three primary standards; the other two are SPF and DMARC.

• SPF (Sender Policy Framework): SPF allows a domain to specify which mail servers are authorized to send email on its behalf. This is done via a DNS TXT record that lists permitted IP addresses or hostnames. When an email claiming to be from your domain arrives, the receiver can check the SPF record to see if the sending server’s IP is on the list. If it’s not, the email fails SPF. In effect, SPF helps prevent fraudsters from spoofing your domain to send unauthorized emails.

• DKIM (DomainKeys Identified Mail): DKIM is an email authentication method that uses a digital signature to verify that an email was sent by the domain owner and hasn't been altered during transit. It works by signing outgoing emails with a private key and letting recipients verify the signature using a public key stored in the sender’s DNS records.

• DMARC (Domain-based Message Authentication, Reporting, and Conformance): DMARC is built on top of SPF and DKIM to enforce alignment (as discussed above) and to provide instructions to receiving servers on how to handle emails that fail authentication. With DMARC, the owner of the domain publishes a DNS record that tells receivers what policy to apply if an email doesn’t pass SPF and/or DKIM checks  –  for instance, do nothing, quarantine it (e.g. send to spam), or reject it outright.

Together, SPF, DKIM, and DMARC complement each other to improve email trust. SPF defines who can send for your domain, DKIM verifies a message’s integrity and sender via cryptographic signature, and DMARC ties the results together and specifies enforcement. Using all three in tandem is considered best practice for protecting your domain’s reputation and preventing fraudulent emails.

Wrapping up

In summary, the DKIM selector is a mechanism to select the correct key in DNS. It’s chosen when configuring DKIM on the sending side (it can be an arbitrary string, often provided or recommended by your email platform). When reading an email’s headers, you’ll see something like s=txn1; d=saasapp.com in the DKIM‑Signature  –  which informs us that the public key is published at txn1._domainkey.saasapp.com for domain saasapp.com.