Understanding DKIM Selectors: How to Choose & Find Them

What is a DKIM Selector? The Key to Your Digital Lock

A DKIM selector is like a key ID or a label that tells receiving mail servers exactly which public key to use when verifying your email signature. It's an arbitrary string value that you define when setting up DKIM, and it becomes part of the DNS record path where your public key lives.

Here's the technical breakdown: DKIM records are published at a specific DNS subdomain address: [selector]._domainkey.[yourdomain.com]. The selector is whatever name you choose—"google," "mail," "s1," "2026-05"—anything alphanumeric that makes sense for your infrastructure.

When your mail server signs an outgoing message, it includes the selector in the s= tag of the DKIM-Signature header. The receiving server reads this tag, constructs the DNS lookup address using your domain (from the d= tag) and the selector, then fetches the corresponding public key to verify the signature.

Why Domains Use Multiple Selectors: The Multi-Vendor Reality

In modern business environments, a single domain rarely sends all its email from one place. You might use Gmail or Office 365 for internal employee emails, Mailchimp or Klaviyo for marketing newsletters, SendGrid or Amazon SES for transactional receipts, and Zendesk or Intercom for customer support tickets.

Each of these services needs its own DKIM key pair to sign messages on your behalf. However, you cannot publish two different public keys under the same DNS record. That's where multiple selectors become essential:

• Google Workspace might use selector: google → DNS: google._domainkey.yourdomain.com
• Mailchimp might use selector: k1 → DNS: k1._domainkey.yourdomain.com
• SendGrid might use selector: s1 → DNS: s1._domainkey.yourdomain.com
• Your own mail server might use selector: mail → DNS: mail._domainkey.yourdomain.com

Each selector points to a different public key. The service uses its private key to sign emails, includes its designated selector in the signature, and receiving servers fetch the correct public key based on that selector. This system keeps keys organized, prevents conflicts, and allows you to revoke a single vendor's access without affecting others.

Multiple selectors also enable key rotation without downtime. You can publish a new key under a new selector, update your mail server to start using the new selector, keep the old selector active for a transition period, then finally retire the old selector—all without a single verification failure.

How to Find Your Active DKIM Selector: A Practical Guide

If you don't know which selector your email service is using, you cannot verify your DKIM configuration or troubleshoot failures. Here are three reliable methods to discover your active selector:

Method 1: Inspect Email Headers (Easiest)

1. Send a test email from your domain to any address you control (or use Gmail/Yahoo/Outlook).
2. Open the email and view the raw message source or original headers:
   • Gmail: Open the email → Click three dots menu → "Show original"
   • Outlook (web): Open the email → Click three dots → "View" → "View message source"
   • Apple Mail: Open the email → "View" menu → "Message" → "Raw Source"
3. Search for the header that starts with DKIM-Signature.
4. Look for the s= tag within that header. The value immediately after the equals sign (up to the next semicolon) is your selector.

Example: DKIM-Signature: v=1; a=rsa-sha256; s=google; d=yourdomain.com; ...
In this example, "google" is the selector.

Method 2: Check Your Email Service Provider's Dashboard

Most ESPs (Email Service Providers) display your DKIM selector in their authentication settings:

• Google Workspace: Admin console → Apps → Gmail → Authenticate email → DKIM → "DKIM key selector" field
• Microsoft 365: Defender portal → Policies & rules → Threat policies → Email authentication settings → DKIM
• Mailchimp: Account → Settings → Domain authentication → View details
• SendGrid: Settings → Sender Authentication → Domain Authentication → View details

Method 3: DNS Lookup (Advanced)

If you know your domain but not the selector, you can brute-force common selector names using DNS lookup tools like dig or online DNS checkers. Try common values like: default, mail, selector1, google, mx, s1, k1, dkim, and any vendor-specific defaults.

Selector Best Practices for Long-Term Success

Choosing and managing selectors correctly prevents future headaches:

• Use meaningful, versioned names: Instead of generic names like "selector1" or "default," use names that indicate the purpose and date: google-workspace, mailchimp-2026, s1-transactional. This makes key rotation obvious and manageable.
• Plan for rotation from day one: Assume you'll rotate keys every 6-12 months. Use selectors that include a date or version number (v2026-01) so you can publish v2026-07 later without confusion.
• Document all selectors: Maintain a spreadsheet or wiki page listing every selector, which service uses it, when it was created, and when it expires. Your future self will thank you.
• Remove old selectors after transition: After a 7-10 day overlap period following key rotation, delete obsolete DNS records. This keeps your DNS zone clean and prevents accidental use of compromised old keys.
• Avoid special characters: Stick to letters, numbers, and hyphens. Underscores are technically allowed but can cause issues with some DNS providers. Spaces and other special characters are not permitted.

Use our DKIM Checker to verify that your selector records are correctly published and returning the expected public keys. Simply enter your domain and known selector, and the tool will perform a DNS lookup and validate the record format.