Understanding DKIM Selectors: A Beginner Guide for Domain Owners
A DKIM selector is a unique string token used by receiving mail servers to locate the correct public cryptographic key in your domain's DNS records and verify the digital signature of an incoming email. Because a single domain often sends emails through multiple different services, selectors allow you to manage multiple public keys simultaneously without naming conflicts. Without a properly configured selector, mail providers cannot validate your messages, which drastically increases the likelihood that your emails will land in the spam folder.
To diagnose your current configuration, you can use the DKIM Checker to quickly verify if your public keys are correctly published and readable in your domain's DNS zone.
The Core Anatomy of a DKIM Record
DomainKeys Identified Mail (DKIM) adds an invisible cryptographic signature to the header of every outgoing email. When an email leaves your server, your mail transfer agent signs specific headers and parts of the body using a private key. The receiving mail server reads the DKIM signature header to find out who signed the message, specifically looking for the domain name and the selector.
A standard DKIM signature header inside an email looks similar to this:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=google2024;
h=from:to:subject:date;
bh=2Jzy...; b=K9s8...
In this header, two critical tags define how the receiver validates the message:
d=example.com: The signing domain.s=google2024: The DKIM selector.
When the receiving server sees d=example.com and s=google2024, it automatically queries the Domain Name System for a TXT record at a very specific canonical address: google2024._domainkey.example.com. If that TXT record exists and contains a valid public key, the receiver uses it to decrypt the signature and confirm that the email was genuinely sent by the domain owner and was not altered in transit.
Why Do You Need Multiple Selectors?
Most modern organizations do not send all their emails from a single server. You might use Google Workspace or Microsoft 365 for corporate communication, Mailchimp or SendGrid for marketing campaigns, and Zendesk for customer support. Each of these vendors needs to sign emails on your behalf.
If every service tried to publish its public key at the exact same DNS address (@._domainkey.example.com), they would overwrite each other. Selectors solve this by allowing unique namespaces:
| Service / Vendor | Typical Selector Example | Resulting DNS TXT Record Lookup |
|---|---|---|
| Google Workspace | google |
google._domainkey.example.com |
| Email Marketing Tool | mksend |
mksend._domainkey.example.com |
| Helpdesk Platform | zendesk1 |
zendesk1._domainkey.example.com |
By assigning a distinct selector to each sending platform, you can safely host dozens of public keys side-by-side in your DNS provider without any conflicts.
How to Find Your DKIM Selector
If you did not set up your email authentication yourself, or if you inherited a domain and need to audit it, you must locate your active selectors. You can do this by inspecting an email you received from your own infrastructure or by reviewing your provider administration console.
Method 1: Inspecting Email Headers
- Open an email sent from your domain in your personal inbox.
- Open the raw message source or full headers view (in most email clients, this option is labeled "Show Original" or "View Message Source").
- Search for the line beginning with
DKIM-Signature:. - Look for the
s=tag within that line. The value immediately following the equals sign is your selector.
Method 2: Checking Your Provider Settings
If you are using a third-party service, log into your administrator dashboard and look under domain settings, email authentication, or deliverability sections. Providers almost always list the exact selector name they require you to publish.
Step-by-Step: Adding a DKIM Record to DNS
Once your email provider gives you a selector name and a public key string, you must publish it to your DNS host (such as Cloudflare, Route 53, GoDaddy, or Namecheap). Note that menu paths vary slightly depending on your registrar, but the core steps remain identical.
- Log into your DNS management dashboard.
- Navigate to your domain's DNS record management or zone editor page.
- Create a new record and select TXT as the record type.
- In the Name or Host field, combine your selector with the mandatory
_domainkeysubdomain prefix. For example, if your selector iss1, enters1._domainkey(some DNS panels automatically append your root domain, so check your provider's formatting rules). - In the Value or Points To field, paste the complete public key record provided by your vendor, usually starting with
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG.... - Save the record and wait for DNS propagation.
Verifying Your Setup with Command Line Tools
You can query your published public key directly from your terminal using standard network diagnostic tools.
Using dig on Linux or macOS:
sig=google2024
domain=example.com
dig TXT ${sig}._domainkey.${domain}
Using nslookup on Windows PowerShell:
$sig = "google2024"
$domain = "example.com"
nslookup -type=TXT "$sig._domainkey.$domain"
A correct response will return your TXT record containing the public key string, confirming that receiving servers can read your configuration.
Common Mistakes and How to Fix Them
Even experienced engineers occasionally make configuration errors when handling email security tokens. Watch out for these frequent pitfalls:
- Incorrect Hostname Formatting: Entering just the selector name (
google2024) into the DNS host field instead of the full required subdomain string (google2024._domainkey). Always ensure the._domainkeysuffix is included. - Exceeding DNS Length Limits: RSA 2048-bit public keys are quite long and often exceed the 255-character limit for a single DNS string chunk. Many DNS providers handle this automatically, but if yours does not, you may need to split the key into multiple quoted strings within the same TXT record.
- Selector Mismatch: The selector configured in your DNS record does not match the selector name that your outbound mail server is inserting into the email headers. Always cross-reference your provider dashboard with your actual DNS zone entries.
- Forgetting to Update Keys: Many enterprise mail services support automatic key rotation. If your provider rotates your keys and you fail to update the corresponding DNS TXT records, your emails will fail authentication.
Quick Checklist for DKIM Selectors
- Identified every platform and service that sends email on behalf of your domain.
- Obtained the unique selector name and public key string from each provider.
- Created individual TXT records in your DNS zone for every selector using the
selector._domainkeynaming convention. - Tested DNS record resolution using command-line tools or an automated checker.
- Sent a test message to an external mailbox and inspected the raw headers to verify a passing DKIM signature.