DMARCLY

Everything about DMARC, DKIM, SPF, email authentication, deliverability, anti-spoofing, anti-phishing, security, and tools.

What Is DKIM Selector and How Does It Work: DKIM Selector Explained

In this article we will explain various concepts related to DKIM selectors: what are they, why do we need them, and how they work in DKIM authentication.

What is DKIM selector?

A DKIM selector, as indicated by the name, is a string used by the outgoing server to locate the private key to sign the email message, and by the receiving server to locate the public key in the DNS to verify the integrity of the email message.

Each time a private/public key pair is generated, a tuple { selector, private key, public key } is created, where the selector is used to locate the private key and the public key.

How to choose a DKIM selector?

A DKIM selector is specified when the user creates a private/public key pair with the email delivery service like SendGrid. It can be any arbitrary string.

Why do we need DKIM selectors?

Multiple private/public key pairs are required due to the following reasons:

  • DKIM key rotation which we will explain in the next section;
  • setting up DKIM with multiple email delivery services on a single domain; each service can have their own separate selectors so that signing/verifying with one service doesn't interfere with that with another.

Each time an email message is sent/verified, only one key pair is used. This is where a DKIM selector comes into play: the DKIM selector is chosen by the signing server to locate (select) the public key in the key pair; and the receiving server uses the same selector to find the private key in the key pair.

How do DKIM selectors work in DKIM authentication?

Once the signing server has chosen the selector, the server uses it to find the private key only accessible to the server, to compute the signature. After the signature is computed, the DKIM selector is inserted into the email headers as an s= tag, then the email is sent.

For example, let's assume that the selector chosen by the signing server is s1, the tag will look like s=s1. Again the selector can be any arbitrarily chosen string like thisismyselector1234, as long as it points to a valid private/public key pair.

Here is a practical example of DKIM signature header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmarcly.com; h=content-transfer-encoding:content-type:from:mime-version:subject: x-feedback-id:to; s=s1; bh=jCC0oQBCKfJ10bCI3PCG52Zwowyeh1haGJPACkWN9F4=; b=GzLBVZ0M1hMt1Y7hVT+ajaNrswTv+/FFVMrcaixD70hpTJwAmNwZUKJIzLslSC+iWHby 9gm+yfx6Z1qnXIL6qgBPnlZD4zwyK4D3Umd1je82jniuD7RJWYDqJH0zL+EevCDdoVZGmT IlxzZB6v95bws6539z/5qee+Xmu5KYe4Y=

The DKIM selector used in the above DKIM signature is s=s1.

When the email hits the receiving server, the server looks at the email headers to find the s= tag. If the tag is present, the server extracts the selector from the tag, then looks up the DNS for the private key at the following location: s1._domainkey.example.com.

If the private key is found, the server uses it to decrypt the message to check its integrity. If the check passes, DKIM authentication succeeds; otherwise it fails.

If no private key is found, DKIM authentcation fails.

What is DKIM key rotation?

DKIM has proven to be a highly effective means by which a receiver can verify that the signed fields of an email have not been modified in transit. DKIM is as secure as the weakest link - the private key, though. The private key of a DKIM keypair is vulnerable to being stolen if an attacker is able to compromise the system in which it is stored. Therefore, to minimize the risk of active DKIM keys being compromised, they should be changed frequently. This is a practice known as DKIM key rotation.

Each time a key is rotated, a new {selector, private key, public key} tuple is created. Then the public key will need to be published in the DNS, and you need to re-configure the outgoing email server to use the new private key. After this is done, the outgoing email server will use the new private key to sign all outgoing email messages.

The old key should be kept for a period of 7 days, after which it can be safely removed. The reason for that is there might be some delay between when an email leaves the originating server and when it's accepted by the receiving server. Sometimes this delay can be as long as several days due to some temporary errors on the receiving server. For DKIM authentication to pass though, the receiving server must be able to find the public key in the DNS using the selector set in the email headers.

Note that manual DKIM key rotation is necessary only if you run your own email delivery service in-house. If you are using services like SendGrid, Office 365, or GSuite to deliver emails, you don't have to do anything - DKIM key rotation is done automatically for you and is transparent to you.

DKIM selector VS DKIM record

If you use an email delivery service like SendGrid, it creates CNAME-typed DKIM records for you when you set up DKIM with them. A CNAME-typed DKIM record looks like this:

s1.domainkey.u5022280.wl431.sendgrid.net

You will need to publish such records in the DNS so that the receiving server has access to them. Note that the s1 part in the record above: it's the DKIM selector the receiving server uses to fetch the record for the private key, which is in turn used for DKIM authentication.

Refer to the DKIM RFC for more information: DKIM RFC6376.

Protect Your Business Email

Get a 14 day trial. No credit card required.

Create Account
Need to fix the "SPF PermError: too many DNS lookups" issue? Check out this post: Want to get the ultimate DMARC guide? Click the link below:
The Fastest Way to Set Up DMARC, DKIM, and SPF: Easy Email Authentication Deployment Explained How to fix "SPF PermError: too many DNS lookups"
Blog Comments powered by Disqus.