When we talk about email authentication, we often focus on the big three: SPF, DKIM, and DMARC. While all are crucial, DKIM has a particular component that can sometimes cause confusion: the selector. It's a small but mighty part of the DKIM signature, and understanding it is key to ensuring your emails are properly authenticated and delivered. Without the right selector, your entire DKIM setup can fail, undermining your efforts to build a trustworthy sending reputation.
Think of the selector as a specific pointer. It tells receiving mail servers exactly where to look in your domain's DNS records to find the public key needed to verify your email's signature. This process confirms that the email genuinely came from your domain and hasn't been tampered with in transit. In this guide, I'll break down what DKIM selectors are, show you a list of the most common ones used by major email providers, and explain how you can manage them effectively.
At its core, a DKIM selector is a simple string of text included in the DKIM-Signature header of every email you send. This header is added by your outbound mail server. The selector's job is to be a unique identifier. Since a single domain can have multiple public keys published in its DNS for different sending services, the selector acts like an address, guiding the recipient's server to the correct one.
When a receiving server gets an email, it looks for the DKIM-Signature header. Inside this header, it finds two crucial pieces of information: the domain (in the d= tag) and the selector (in the s= tag). It then combines these to form a DNS query. For a selector named selector1 and the domain example.com, the query would go to selector1._domainkey.example.com.
The server expects to find a DNS TXT record at that address containing the public DKIM key. It uses this public key to verify the cryptographic signature in the email header. If the verification is successful, it proves the email's authenticity. If the selector is wrong or the record doesn't exist, the DKIM check fails, which can hurt your deliverability.
You might wonder why a domain would need more than one DKIM key. The primary reason is that most organizations send email from multiple platforms. For instance, you might use Google Workspace for your day-to-day corporate emails, Mailchimp for your marketing newsletters, and SendGrid for transactional emails like password resets. Each of these services needs to sign emails on your behalf, and each should have its own unique DKIM key and selector.
Using multiple DKIM records with different selectors helps isolate your sending reputation. If an issue arises with deliverability from one provider, it doesn't automatically impact the others. It also provides greater security. If one provider's private key were ever compromised, you could revoke it by removing the corresponding DNS record without affecting your other email streams.
Another critical reason is DKIM key rotation. For security, it's a best practice to periodically change your DKIM keys, typically every 3 to 6 months. Using multiple selectors allows you to implement a new key on a new selector, test it, and then switch over without any downtime or authentication failures. Once the new key is active, you can safely remove the old one.
While you can name a selector almost anything you want, most third-party email service providers (ESPs) use standard, predictable selectors. This makes setup easier for their customers. When you configure DKIM with a provider, they will typically tell you exactly what selector and DNS record to use. Below is a list of some of the most common selectors you'll encounter.
Provider
Common Selectors
This list is not exhaustive, and providers can change their conventions. If you're ever unsure what selector to use, the best place to look is in your provider's documentation or their domain settings panel. If that fails, you can send a test email to yourself and inspect the email's original source code. Look for the DKIM-Signature header and find the s= tag, which will tell you the exact selector that was used.
If you manage your own mail server or use a service that allows for custom selectors, you have more flexibility. Creating your own is a straightforward process. First, you'll need to generate a DKIM key pair: a private key that stays on your server and a public key that you'll publish in your DNS. Many tools, including OpenSSL, can generate these keys for you. Some providers also have DKIM record generators that simplify this step.
Next, choose a name for your selector. While you can use a generic name like default, it's better to be descriptive. A good practice is to include the date or the service it's for, such as q3-2024-marketing or transactional-mail. This makes management much easier, especially as you add more services or rotate keys.
Finally, you need to publish the public key in your domain's DNS. This is done by creating a TXT record with a specific name and value. The name will be your-selector._domainkey.yourdomain.com. The value contains the public key itself, along with a couple of other tags. It will look something like this:
DKIM TXT Record Example
dns
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...your public key...AQABOnce this record is published, and your mail server is configured to use the corresponding private key and selector, you're all set. Receiving servers can now successfully look up your public key and verify your emails, boosting your deliverability and protecting your domain's reputation.
DKIM selectors may seem like a minor technical detail, but they are fundamental to how email authentication works. They provide the necessary link between an individual email and your domain's public authentication key. Using distinct selectors for different mail streams is a key strategy for managing reputation and enhancing security.
Whether you're using the standard selectors provided by your ESP or creating your own, ensuring they are configured correctly is non-negotiable for anyone serious about email deliverability. It's a critical piece of the puzzle that, when combined with SPF and DMARC, creates a powerful defense against phishing and spoofing, ensuring your legitimate messages reach the inbox.
What happens if I use the wrong DKIM selector?
Can I have multiple DKIM records on my domain?
How often should I rotate my DKIM keys?
Do I need a DKIM selector if I only use one email service?
Matthew Whittaker
11 Jul 2025
Learn what a DKIM selector is and why it's a crucial part of email authentication. This guide provides common selector name examples from services like Google and Microsoft 365, and offers best practices for creating and managing your own selectors to improve email security and deliverability.
Michael Ko
11 Jul 2025
Struggling with DKIM 'temperror' results in your DMARC reports from Microsoft? This article breaks down what these temporary errors mean, why they are common with Outlook and Microsoft 365, and provides actionable strategies to diagnose your setup and reduce their frequency. Learn how to strengthen your email authentication and improve deliverability.
Matthew Whittaker
12 Jul 2025
Struggling with 'dkim=temperror' in your DMARC reports? This guide breaks down what this temporary error means, from common causes like DNS timeouts and syntax issues to a step-by-step process for diagnosing and fixing the problem to improve your email deliverability.
Matthew Whittaker
12 Jul 2025
Struggling with the 'DKIM record published no DKIM record found' error? This guide breaks down what this confusing message means, explores common causes like DNS propagation and hostname typos, and provides a clear, step-by-step process to diagnose and fix the issue, ensuring your email authentication is set up correctly for better deliverability.
