DKIM (DomainKeys Identified Mail) is a protocol for using public-key cryptography to verify that email is authentic and has not been tampered with. To accomplish this, DKIM uses public-key cryptography and hosts public keys on special subdomains that are located using an identifier called the DKIM Selector in an email’s headers. This makes the selector not merely an important part of DKIM but one that is absolutely integral: Without the selector, recipients wouldn’t know where to look for the public key.

In this article, we provide the details of what a DKIM selector does, using real examples of production DKIM selectors on live domains. We’ll then walk you through an illustrated guide to setting up your own DKIM keypair using Google Workspace, which you can point your selector to. Finally, we’ll provide some best practices to ensure that your DKIM selector is secure and reliable.

Before we begin, let’s cover some basic technical terminology that will be required to understand the rest of the content.

DKIM	DomainKeys Identified Mail, an authentication protocol for email using DNS and public-key encryption.
Public Key	A cryptographic key shared with the world to prove that a DKIM Authenticated email is legitimate.
DNS	Domain Name System, an internet system for looking up domain IPs, comments, mail servers, and more.
TXT Record	A DNS record containing metadata for a domain, such as DKIM, DMARC, and any other arbitrary comments admins wish to associate with a domain.

How a DKIM Selector Works

A DKIM selector is simply a specific DNS label or a name that identifies a location in the DNS where a public key is published. Setting up a DKIM selector is as easy picking a random name to use as your selector, configuring your mail server to use that as your DKIM selector, and publishing a TXT record with your public key to the subdomain selector._domainkey.example.com, where selector is whatever selector you chose, and example.com is your domain name. 

When you configure your outgoing mail server for DKIM, you’ll have to tell it what selector you’re using so it can include that selector in the DKIM-Signature header of all outgoing emails. Using this header, recipients will know what subdomain to query to find your public key and thus be able to verify your DKIM signature and know that your email is legitimate. 

But enough theory—let’s take a look at some existing DKIM selectors and see what they look like and how they work. 

Analyzing a Real DKIM selector

Gmail is the most popular email provider by a large margin, with over 50% of the US market, according to TechJury. Let’s look at the headers of an email sent from Gmail and find the selector. Here are the raw headers:

Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    	d=gmail.com; s=20210112;
    	h=mime-version:from:date:message-id:subject:to;
    	bh=5pSA59B/++wEmEvVdANtcX6VWOlY9vhzaru62DcmQas=;
    	b=A4U3Vs+mPJ/xCgPyvDHl5eIVwc2SBBXcdLV/PrN

The selector can be found via the s tag, which here points to 20210112. Now we just do a DNS lookup for TXT records at 20210112._domainkey.gmail.com and we should find the DKIM public key. Let’s see what happens:

$ dig -t TXT +noall +answer 20210112._domainkey.gmail.com
20210112._domainkey.gmail.com. 300 IN    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq8JxVBMLHZRj1WvIMSHApRY3DraE/EiFiR6IMAlDq9GAnrVy0tDQyBND1G8+1fy5RwssQ9DgfNe7rImwxabWfWxJ1LSmo/DzEdOHOJNQiP/nw7MdmGu+R9hEvBeGRQ"

Seeing that we do, in fact, see such a record, note that it contains three tags. The v tag refers to the version, which is DKIM1, and k refers to the key algorithm, which in the wild will always be rsa. Most important is the p tag, which contains the sought-after public key. 

Deploying a DKIM Selector Via Google Workspace

Now that we’ve had the pleasure of picking apart a DKIM selector created by highly experienced admins at Google, let’s solidify that understanding by creating our own DKIM keypair from scratch that we can publish and to which we can point the selector. To accomplish this, we’ll use Google Workspace.

First, log into your Google Admin Console.

From the Admin Console, open the hamburger menu in the top left corner and click Gmail. You should now see a page dedicated to Gmail admin settings that looks something like Figure 2.

Once here, click the Authenticate Email option and select the domain for which you want to set up the DKIM selector. You’ll see a button that says Generate New Record. Click it, and you should be presented with the menu in Figure 3

This is the screen where we’ll actually implement our selector! Set the key bit length to 2048, then change the selector from google to whatever you want. You can pick anything, or even leave it as google, which is the default. In the best practices section below, we’ll offer some recommendations for which of these choices is the best.

If you have any difficulty following the above instructions, an excellent video tutorial for implementing a DKIM selector can be found on the Google Workspace Youtube channel.

Best Practices

Before wrapping up, let’s look at some basic suggestions for implementing a DKIM selector in the most secure way.

Rotate DKIM Selectors

The key itself should be rotated frequently, replacing the old key with a new one. Given enough time, attackers could crack the key and thus be able to send emails from your domain that would pass DKIM verification. How much time is enough? According to a report by Quintessence Labs titled Breaking RSA Encryption – an Update on the State-of-the-Art, “It would take a classical computer around 300 trillion years to break a RSA-2048 bit encryption key.” So using a strong, 2048-bit key dramatically mitigates this risk. Nevertheless, it’s also possible for keys to leak by accident or be stolen, and sometimes this occurs without the admins ever finding out. 

A rotation policy means that even if a key is stolen, it will only work for a brief period of time. If the attacker gets a key after it has been rotated out, it will be useless.

Set a Low TTL on TXT Records

Keys are rotated by publishing a new key at a new location, not by editing an existing DNS record. However, if there is a mistake or error, it may be necessary to change the key on an old selector. If that happens, we want the new key to be quickly propagated. 

“TTL” stands for “Time to Live” and refers to the amount of time a DNS record lives in the cache of nameservers. A TTL between 60 and 300 seconds is optimal.

Publish Old DKIM Keys

Imagine that a hacker leaks sensitive emails from your organization to sell on the dark web, blackmail your employees, or cause a scandal in the press to hurt your business. The hacker would need some way to prove that the emails were authentic. Otherwise, buyers or the public may suspect that the emails weren’t real and that the attacker just created them.

If the emails have a valid DKIM header, that would be proof that the emails are authentic! In other words, DKIM can help attackers prove that stolen emails are legitimate.

To solve this, you can simply publish old private keys after rotating them out of use. That way, as long as the emails are old enough that the key for them has been rotated out, anyone could have created the email with a “valid” DKIM header. In other words, publishing old, rotated private keys offers plausible deniability in case old emails are stolen, making the authenticity of leaked emails from your organization harder for attackers to prove.

For a deeper explanation of this practice, read the article Ok Google: please publish your DKIM secret keys.

Conclusion

Email security protocols can look like an impenetrable labyrinth of obscure technical terminology. As the means for connecting the received email in a user’s inbox with the public key needed for verifying the authenticity of the email, the DKIM selector is a core feature of DKIM and, therefore, the email security ecosystem.

By breaking down complex concepts and looking at single features in isolation, such as DKIM selectors, new admins can build towards understanding the bigger picture.