DKIM Selectors: What They Are and How to Find Them

How Does DKIM Work?

The DKIM, short for DomainKeys Identified Mail, adds a digital signature to an outgoing email so a receiving server can verify that the message came from an authorized sender and was not altered after signing. The sending system signs parts of the email message with a private key, and the receiving side looks up the matching public key in DNS to validate the signature.

The main components are straightforward. The private key stays with the sending platform and is used for DKIM signing. The public key is published in DNS so the receiving mail server can perform DKIM authentication. The DKIM signature header also includes the sending domain in the d= tag, which tells recipients which domain is taking responsibility for the signature.

What Is a DKIM Selector?

A DKIM selector is the identifier that points to the correct DKIM public key. It appears in the s= tag of the DKIM-Signature header and helps the receiving server know which DNS record to query. Without the selector, the server would not know which DKIM record to use for verification.

It helps to separate the selector from other parts of DKIM. The selector is not the same as the sending domain in the d= tag. The d= value identifies the domain tied to the DKIM signature, while the selector identifies which key under that domain should be used. Together, they guide the DNS lookup that supports DKIM validation. 

Related terms are easy to mix up, so here’s how to keep them distinct:

• DKIM key: the cryptographic key pair used for signing and verification.
• DKIM record: the DNS record that publishes the public key.
• DKIM protocol: the broader authentication method that defines how signing and verification work.
• DKIM selector: the label that points to the right public key record.

How Does a DKIM Selector Work?

The selector works as part of the DKIM signing and verification path. Each step is simple on its own, but together they explain why the selector matters:

1. The sending server signs the message

The sending system applies a DKIM signature to the outgoing email using its private key. That signature is added to the email header. 

2. The selector identifies the matching key

The DKIM-Signature header includes an s= value. That selector tells recipients which public key matches the signature used on the message. 

3. The receiving server builds the DNS lookup

The receiving server combines the selector with the domain in the d= tag to construct the DNS query. In practice, the lookup usually follows the pattern selector._domainkey.domain. 

4. The public key is returned and used for verification

If the correct DNS record resolves, the receiving server retrieves the public key and uses it to validate the DKIM signature. If the signature verifies, DKIM authentication passes. 

How Can You Find a DKIM Selector?

There are several common ways to find a DKIM selector. Some are manual, while others rely on admin settings or monitoring tools.

Method A: Inspect the email header manually

One of the most direct methods is to inspect the email header and look for the s= value inside the DKIM-Signature header. That is the selector field.

In Gmail, open the message, choose “Show original”, and inspect the authentication data and raw headers. In Microsoft Outlook, open the message properties or internet headers and look for the DKIM-Signature line. In both cases, the selector appears as the value after s=.

Method B: Check the email provider or admin console

Many platforms show the selector in their DKIM setup screens. In Google Workspace, admins generate the DKIM key and selector from the Admin console for Gmail authentication. Microsoft 365 also exposes selector information when DKIM is configured for custom domains.

Method C: Use a DKIM lookup or checker tool

A DKIM checker can also help identify or validate the selector. Mimecast’s DKIM Record Checker asks for the selector and domain name, then checks whether the record is correctly configured and visible in DNS. That makes it useful for troubleshooting or confirming a live DKIM setup.

Method D: Use DMARC monitoring and reporting

DMARC monitoring tools can help surface DKIM patterns across domains and mail streams. Aggregate reporting does not replace a direct DKIM lookup, but it can help teams identify which senders are signing, which streams are failing, and where different DKIM selectors appear across the environment.

Common selector naming conventions

Selectors usually appear in a format like selector._domainkey.domain. Many organizations use descriptive names tied to the provider, purpose, or rotation schedule. Common selectors might reference a platform, environment, or sequence, such as google, selector1, selector2, mktg2026, or a vendor-specific label. The best practice is consistency. A descriptive selector name is easier to track, rotate, and troubleshoot later.

How to Configure and Publish a DKIM Selector

The process for publishing a DKIM is usually short, but accuracy matters. Even small mistakes in the selector or DNS record can prevent receiving servers from validating the signature correctly.

Step 1: Choose or generate the selector

Start with a unique selector name that matches the sending platform’s DKIM configuration. Some platforms generate this for you. Others let you define it manually.

Step 2: Generate or retrieve the DKIM key details

Collect the selector, record type, and DNS value from the email provider. This may include a TXT record with the public key or a CNAME record that points elsewhere, depending on the platform.

Step 3: Build the DNS host name

Format the host name as selector._domainkey.domain. This is what the receiving server will query during DKIM verification.

Step 4: Publish the DKIM record in public DNS

Add the exact host name and value at the domain’s DNS provider. This step should use the record type and value required by the sending platform.

Step 5: Enable DKIM signing in the sending platform

Once the DNS record is in place, activate DKIM signing in the email provider. Publishing the record alone does not guarantee that live mail is being signed.

Step 6: Verify that the selector is working

Check DNS resolution, then inspect live messages to confirm DKIM pass results. A record existing in DNS is useful, but real mail still needs to pass DKIM validation in practice.

Managing DKIM Selectors

DKIM selectors are not a one-time setup item. They should be tracked as part of ongoing email authentication hygiene, especially in environments with Google Workspace, Microsoft 365, Amazon SES, and multiple third-party senders.

Good documentation helps keep selector management organized over time. Teams should track the selector name, domain, sending service, key length, publish date, and planned key rotation timing. Ongoing visibility matters too, and a DMARC reporting tool can help teams spot failing sources, selector issues, and recurring authentication gaps across different mail streams.

A healthy DKIM selector lifecycle usually includes:

• Planning the selector and naming convention
• Publishing the record
• Enabling signing
• Rotating keys over time<
• Reviewing old selectors before decommissioning them

Old selectors should not be removed until teams confirm that no active mail stream still depends on them. Removing a selector too early can break DKIM authentication for systems that are still signing with it.

Why Do Organizations Use Multiple DKIM Selectors?

Organizations often use multiple DKIM selectors because one domain may support several sending services or mail streams. Microsoft 365, Google Workspace, Amazon SES, and third-party platforms may each use separate selectors, and the same can apply to different mail types such as marketing and transactional email.

Multiple selectors also make key management easier. They support smoother key rotation, staged changes, testing, and vendor transitions without interrupting mail authentication. Using multiple selectors is normal. The real issue is not the number of selectors, but whether each one is published correctly and tied to the right sending service.

DKIM Signing: TXT vs. CNAME Records

DKIM can be published through TXT-based or CNAME-based models.

TXT-based DKIM

With TXT-based DKIM, the public key is published directly in the domain’s DNS as a DNS TXT record. This is common in platforms like Google Workspace, where the domain owner publishes the DKIM key material directly.

CNAME-based DKIM

With CNAME-based DKIM, the selector record points to another domain that hosts the DKIM key material. Microsoft 365 commonly uses this model and requires CNAME records for DKIM on custom domains.

Both models can support valid DKIM authentication. The main rule is to follow the exact record type and format required by the email provider. Teams should not force TXT or CNAME based on preference if the provider expects something else.

Common DKIM Selector Problems & Troubleshooting

Selector-related issues are usually straightforward once teams know where to look. The most common problems include:

• Mismatch between the selector in the email header and the selector published in DNS
• Missing or outdated DKIM record
• Malformed DNS record
• Selector still in use after teams thought it had been retired

These mistakes can break DKIM checks, contribute to DMARC misconfiguration, and hurt email deliverability. They can also reduce sender trust over time if authentication failures become repetitive across important mail streams. The practical fix is to compare the live DKIM signature header, the DNS record, and the sending platform’s DKIM configuration side by side before making changes.

Keeping DKIM Verification Pointed in the Right Direction

DKIM selectors play a simple but important role in email authentication. They help receiving servers find the right public key for DKIM verification, which keeps the signature check tied to the correct DNS record and domain.

For organizations managing complex sending environments, Mimecast can help improve visibility into DKIM, SPF, and DMARC across domains, providers, and mail streams. Tools like DKIM Record Checker and DMARC Analyzer are especially useful for spotting selector issues, signing gaps, and broader authentication problems.