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:
- It parses the DKIMâSignature header in the email and extracts the domain (
d=
tag) and selector (s=
tag). - It constructs a DNS query to
<selector>._domainkey.<d= domain>
to retrieve the DKIM TXT record. - 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
.
Originally published at https://sidemail.io/articles/what-is-dkim-selector/
Top comments (0)