What Is a DKIM Selector and How to Manage It Across Multiple ESPs?

What Is a DKIM Selector?

A DKIM selector is a small text string included in a DKIM-signed email header that tells the receiving mail server where to find the corresponding public key in DNS. It is defined in the `s=` tag of the DKIM-Signature header.

Every DKIM signature includes a selector value. The selector, combined with the signing domain from the `d=` tag, forms a DNS query path that points to a specific TXT record containing the public key used to verify the signature.

Here is what the selector looks like inside an email header:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
c=relaxed/relaxed; q=dns/txt; h=from:to:subject:date;
bh=abc123…=; b=xyz789…=

In this example, `selector1` is the DKIM selector. The receiving server will query `selector1._domainkey.example.com` to retrieve the public key.

Organizations often operate multiple signing keys simultaneously depending on their emailing requirements. Each key gets its own selector, so both can coexist under the same domain without conflict.

Selectors also make key rotation possible without downtime. You can publish a new key under a new selector while the old selector remains active, then cut over once propagation is complete.

How Do DKIM Selectors Work?

When a receiving mail server gets a DKIM-signed email, it reads the selector (`s=`) and domain (`d=`) from the email header, queries DNS at `{selector}._domainkey.{domain}`, retrieves the public key from the resulting TXT record, and uses that key to verify the cryptographic signature on the message.

Here is the step by step:

Step 1: The sending server signs the email

Before the email leaves the sending mail server (or ESP), the server uses its private key to generate a cryptographic signature over specified header fields and the message body. This signature, along with the selector value and signing domain, is added to the email as the `DKIM-Signature` header.

Step 2: The receiving server extracts the selector and domain

When the email lands in the inbox, the receiving server parses the `DKIM-Signature` header and pulls two values:

1. The selector from `s=` 
2. The domain from `d=`.

Step 3: The receiving server queries DNS

The server constructs a DNS query by combining the selector, the fixed string `_domainkey`, and the domain: {selector}._domainkey.{domain} → TXT record

For example, if `s=google` and `d=example.com`, the DNS query is: google._domainkey.example.com

Step 4: DNS returns the public key

The TXT record at that DNS path contains the public key and associated parameters:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAO…

Step 5: The receiving server verifies the signature

The server uses the public key to verify the cryptographic signature in the email header. 

1. If the signature matches, DKIM passes. 
2. If the key is missing, the record is malformed.
3. If the signature does not match, DKIM fails.

The selector connects the email header to the DNS record because without the DNS record, the receiving server would not have a way to locate the correct public key, especially when a domain publishes multiple DKIM keys for different services.

DKIM Selector Syntax and Format 

DKIM selectors must conform to specific syntax rules defined in RFC 6376.

Allowed characters:

• Alphanumeric characters (a–z, A–Z, 0–9)
• Hyphens (-)
• Periods (.) for subdomain-style selectors

Constraints:

• Selectors are case-insensitive in DNS resolution, though lowercase is standard practice.
• There is no defined maximum length in RFC 6376, but practical DNS limitations apply. Most implementations keep selectors under 63 characters (the maximum DNS label length).
• Selectors cannot start or end with a hyphen.
• Periods in selectors create subdomain hierarchies in the DNS query. For example, `2024.jan._domainkey.example.com` is a valid query path if the selector is `2024.jan`.

The DNS TXT record format at the selector’s path contains the following tags:

Note: 2048-bit RSA keys produce public key strings that exceed the 255-character limit for a single DNS TXT string. DNS handles this through multi-string TXT records, where the value is split across multiple quoted strings that the resolver concatenates per RFC 6376. However, not all DNS management interfaces handle this efficiently, which is a common source of DKIM failures

How to Find Your DKIM Selector 

There are four reliable methods to discover the DKIM selectors in use for a given domain. Each has different strengths depending on whether you control the domain, have access to email headers, or are auditing from outside.

Method 1: Inspect Email Headers

Inspecting email headers is the most direct approach. Open a message sent from the domain in question and view the full email headers.

• In Gmail: Open the message → click the three-dot menu → “Show original.”
• In Outlook: Open the message → File → Properties → “Internet headers.”
• In Apple Mail: View → Message → All Headers.

Look for the `DKIM-Signature` header and locate the `s=` tag. That value is the selector.

If the email passed through multiple signing services, you may see more than one `DKIM-Signature` header, each with a different selector.

Method 2: Use a DKIM Lookup Tool

If you know the selector name, you can query the DKIM record directly at selector._domainkey.example.com. PowerDMARC’s DKIM record lookup, MXToolbox, or command-line DNS queries like dig and nslookup can return the TXT record published for that selector.

Using dig:

bash

dig TXT selector1._domainkey.example.com +short

 

Using nslookup:

bash

nslookup -q=TXT selector1._domainkey.example.com

This method requires you to already know the selector name, or to try common defaults.

PowerDMARC’s DKIM lookup can also auto-detect selectors for many domains, validate DKIM syntax, identify missing or malformed records, and help troubleshoot common DKIM configuration issues. 

Method 3: Check Your ESP’s Admin Console

Most email service providers display the DKIM selector and public key in their authentication settings. For example:

• Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate email
• Microsoft 365: Defender portal → Policies & rules → Threat policies → Email authentication → DKIM
• Mailchimp: Website → Domains → Authentication → DKIM settings

Method 4: DMARC Aggregate Reports

This is the most powerful method for discovering -all selectors actively signing mail for your domain, including ones you may not know about.

DMARC aggregate reports (RUA reports) include the DKIM authentication results for every message received by reporting mail servers. Each result includes the selector used, the signing domain, and the pass/fail status.

If your organization runs multiple ESPs or if third-party services are signing on your behalf, DMARC reports will surface selectors you might not find through header inspection alone. This is especially valuable for uncovering shadow IT email services that were authorized once and never decommissioned.

PowerDMARC’s DMARC analyzer parses these aggregate reports automatically and surfaces all active DKIM selectors per domain in a single dashboard, eliminating the need to manually extract and cross-reference XML data from multiple reporting sources.

Note: There is no DNS wildcard or enumeration method to discover all selectors under `_domainkey.{domain}`. DNS does not support listing all subrecords of a zone from the outside. You cannot brute-force all possible selectors. The four methods above are the practical options.

5. ESP Default DKIM Selectors: 2026 Reference Table 

One of the most common tasks in DKIM management is identifying which selector belongs to which email service. The table below lists the default DKIM selectors used by 14 major ESPs as of early 2026.

Important: ESPs can change default selectors at any time, and some platforms assign account-specific or randomized selectors. Always verify the selector shown in your own ESP admin console against this table.

If your domain sends email through three or four of these platforms simultaneously, you will have three or four active DKIM selectors in your DNS, and each one of them needs to be tracked, verified, and rotated independently. 

Managing multiple DKIM selectors across several ESPs becomes difficult at scale, especially when each platform has different rotation schedules, selector formats, and DNS requirements. 

PowerDMARC Hosted DKIM helps centralize selector management through a single dashboard, making it easier to add, rotate, validate, and monitor DKIM selectors without repeatedly modifying DNS records manually.

Start a free trial

Naming Conventions and Best Practices

DKIM selectors can be named almost anything within the syntax rules. Without a consistent naming convention, selector management degrades quickly as services are added and keys are rotated.

Recommended Naming Patterns

A structured naming approach makes it much easier to identify ownership, track rotations, troubleshoot failures, and avoid operational confusion later on. 

Pattern 1: ESP + Date

Examples:

• google-2026q1
• sendgrid-202601
• hubspot-2025q4

This is the most operationally useful pattern. At a glance, you can identify which service owns the key and when it was last rotated. During an audit, you can immediately flag any selector with a date more than 12 months old.

Pattern 2: Service function + Sequence

Examples:

• marketing-01
• transactional-01
• corporate-01

Useful when multiple ESPs serve the same domain and you want selectors organized by mail stream rather than vendor.

Pattern 3: ESP default (no custom naming)

Many ESPs do not allow custom selector naming. Google Workspace always uses `google`. Microsoft 365 uses `selector1` and `selector2`. In these cases, you work with what the platform provides and track the mapping externally.

Naming Practices to Avoid

Poorly structured or overly generic names can create confusion during audits, troubleshooting, and key rotations, especially in environments with multiple ESPs and large numbers of active selectors. Avoid the following naming practices: 

• Generic names with no context: `key1`, `test`, `dkim` provide no information about the ESP or rotation state.
• Selectors containing sensitive information: Do not embed internal infrastructure details, server hostnames, or employee identifiers in selector names. Selector names are publicly visible via DNS.
• Excessively long selectors: While technically allowed up to 63 characters, selectors over 30 characters add unnecessary complexity to DNS records and lookup commands.

A single-domain, single-ESP setup is simple. You generate a key pair, publish the public key under the ESP’s selector, and you’re done. The operational challenge begins when that same domain sends email through multiple platforms.

A Practical Management Framework

The following five-stage lifecycle provides a structured approach to selector management:

Stage 1: Inventory

Document every active DKIM selector for every domain you manage, including the ESP, key length, date published, and the person or team responsible. DMARC aggregate reports are the fastest way to build this inventory because they reveal every selector currently signing mail for your domain, including the ones nobody remembers setting up.

Stage 2: Validate

For each selector in your inventory, query DNS to confirm the public key is published and correctly formatted. Run a test email through each ESP and verify DKIM passes. Check key lengths, and flag any selector using a 1024-bit key.

Stage 3: Standardize

Adopt a naming convention and apply it to every selector you control. For ESPs that use fixed selector names, document the mapping clearly. Decide on a rotation schedule and assign ownership.

Stage 4: Monitor.

Use DMARC aggregate reports to continuously monitor DKIM pass/fail rates per selector. A sudden failure rate spike on a specific selector usually points to a DNS change, a key expiration, or a configuration change at the ESP.

Stage 5: Decommission

When you stop using an ESP, revoke its DKIM key by publishing an empty `p=` value in the selector’s DNS record. Do not simply delete the DNS record. An empty `p=` value explicitly tells receiving servers the key has been revoked. Deleting the record entirely results in a DNS lookup failure, which is ambiguous and can be interpreted differently by different receivers.

PowerDMARC provides a centralized dashboard that maps all active DKIM selectors across every domain in your account, pulling data from DMARC aggregate reports and DNS monitoring simultaneously. For MSPs managing large client portfolios, this replaces the spreadsheet-based tracking that becomes unmanageable beyond a few dozen domains.

DKIM Key Rotation and Selector Strategy

DKIM key rotation means generating a new key pair and publishing the new public key under a new (or updated) selector, then configuring the sending service to sign with the new private key.

A DKIM private key that remains unchanged for years represents a growing risk. If the key is compromised through a server breach, an insider threat, or a vulnerability in the key storage system, an attacker can sign emails that pass DKIM authentication on behalf of your domain. Regular rotation limits the window of exposure.

How to Rotate DKIM Keys Without Downtime

The standard rotation process uses two selectors in sequence:

1. Generate a new key pair: Create a new 2048-bit RSA (or Ed25519) key pair.
2. Publish the new public key under a new selector: For example, if your current selector is `google-2025q3`, publish the new key under `google-2026q1`.
3. Wait for DNS propagation: Allow 24 to 48 hours for the new TXT record to propagate globally. For Microsoft 365 specifically, allow up to 96 hours to fully propagate.
4. Update the signing configuration: Configure the ESP or mail server to sign outgoing messages using the new private key and new selector.
5. Verify: Send test messages and confirm DKIM passes with the new selector.
6. Revoke the old key: After a transition period (typically 7 to 14 days, to allow in-flight messages signed with the old key to be delivered), publish an empty `p=` value for the old selector.

DKIM Key Rotation in Multi-ESP Environments

Each ESP has its own rotation mechanism:

• Microsoft 365: provides built-in selector rotation between `selector1` and `selector2`. Initiate rotation through the Defender portal.
• SendGrid: rotates automatically between `s1` and `s2`.
• Google Workspace: requires manual key regeneration through the Admin Console.
• Most marketing platforms: require manual rotation through their domain authentication settings.

Rotating all selectors on the same day creates a concentrated risk window and makes troubleshooting harder if something breaks. Spread rotations across different weeks or months.

PowerDMARC’s hosted DKIM feature handles key generation, DNS publishing, and selector rotation for all domains in your account, with configurable rotation schedules per domain and per ESP.

Start a Free Trial

Common DKIM Selector Errors and How to Fix Them 

When DKIM fails, the cause almost always traces back to one of a handful of selector or DNS configuration errors. The table below covers the most common failures, their symptoms, and how to resolve them.

The 2048-Bit Truncation Problem in Detail

When organizations upgrade from 1024-bit to 2048-bit DKIM keys ( given that 1024-bit RSA is considered weak for DKIM purposes), the base64-encoded public key roughly doubles in length. The resulting string typically exceeds 400 characters.

DNS TXT records have a 255-character limit per string within the record. The solution, defined in RFC 6376, is to split the value across multiple strings within a single TXT record. Receiving mail servers concatenate these strings automatically.

Most of the popular DNS management interfaces do not handle this efficiently:

• Some interfaces silently truncate the value at 255 characters without warning.
• Some interfaces reject the entry entirely with a vague error message.
• Some interfaces require the administrator to manually split the string and wrap each segment in quotes.

If you publish a 2048-bit key and DKIM immediately starts failing, check the actual DNS response using `dig` or `nslookup`. Compare the returned `p=` value against the full public key from your key pair. If the returned value is shorter, your DNS provider truncated it.

To avoid this: 

• Use a DNS provider that natively supports long TXT records (Cloudflare, AWS Route 53, and most enterprise DNS platforms handle this correctly).
• Use CNAME-based DKIM, where the selector DNS path points to a CNAME hosted by the ESP. The ESP manages the TXT record on their infrastructure, avoiding the issue entirely.
• If you must use a provider that requires manual splitting, split the key into strings of 250 characters or fewer, each enclosed in quotes, within a single TXT record.

DKIM Selectors and DMARC Alignment 

DKIM and DMARC are separate protocols, but they interact in a way that catches many administrators off guard. DKIM can pass while DMARC still fails. When that happens, the cause is almost always a domain alignment mismatch tied to how the selector’s signing domain relates to the `From:` header domain.

How DMARC Alignment Works with DKIM

DMARC requires that at least one authentication mechanism (SPF or DKIM) both passes and aligns with the domain in the `From:` header.

For DKIM alignment specifically, the `d=` domain in the DKIM-Signature header must match the domain in the `From:` header. The selector itself is not evaluated for alignment. Alignment is based solely on the `d=` domain.

DMARC supports two alignment modes:

The Two Scenarios Where DKIM Passes but DMARC Fails

One of the most confusing email authentication outcomes is seeing DKIM pass while DMARC still fails. This usually happens when the signature itself is valid, but the signing domain does not align correctly with the visible From: domain used in the message.

Scenario 1: Third-party ESP signs with its own domain

Some ESPs, when DKIM is not explicitly configured for your domain, will sign outgoing messages with the ESP’s own domain in `d=`. For example, an email sent on behalf of `[email protected]` might carry a DKIM signature with `d=esp-provider.com`.

DKIM verification passes (the signature is valid), but DMARC fails because `esp-provider.com` does not align with `example.com`.

Configure DKIM signing in the ESP to use your own domain in the `d=` tag. This typically involves adding the ESP’s DKIM selector as a DNS record under your domain and enabling custom DKIM signing in the ESP’s settings.

Scenario 2: Subdomain signing with strict DMARC alignment

If your DMARC policy uses strict alignment (`adkim=s`) and your ESP signs with `d=sub.example.com` while the `From:` address uses `example.com`, DMARC will fail even though DKIM passes.

Either switch to relaxed alignment (`adkim=r`, which is the default) or ensure the `d=` domain in the DKIM signature exactly matches the `From:` domain.

Auditing Alignment Across Multiple ESPs

In multi-ESP environments, each sending platform may sign with different `d=` domains. One ESP might sign with your root domain, another with a subdomain, and a third might default to its own domain until you configure custom signing.

DMARC aggregate reports show the `d=` domain and alignment result for every DKIM-signed message. Review these reports to identify any ESP that is signing with a misaligned domain. PowerDMARC’s DMARC reports highlight alignment failures per sending source, making it straightforward to identify which ESP needs reconfiguration.

Conclusion

The organizations that treat selector management as a continuous operational practice, rather than a one-time setup task, are the ones that maintain consistent deliverability, pass audits cleanly, and respond to incidents quickly.

If you manage more than a handful of domains or work with multiple ESPs, centralizing your DKIM selector visibility is worth the investment.

PowerDMARC provides that centralized view, combining DMARC aggregate report analysis, DNS monitoring, and hosted DKIM management into a single interface designed for exactly this kind of operational complexity.

Manage DKIM selectors across multiple ESPs with ease. Sign up for a trial to monitor DKIM records, improve DMARC alignment, and protect email deliverability.

FAQs

How do I find my DKIM selector?

You can find your DKIM selector by viewing an email’s full headers and locating the DKIM-Signature field. The value after s= is the selector. For example, in s=google, the selector is google.

How many DKIM selectors can a domain have?

There is no technical limit on the number of DKIM selectors a domain can have. Organizations commonly use multiple selectors simultaneously for different email providers, departments, or key rotation periods.

Can multiple ESPs use different DKIM selectors on the same domain?

Yes. Each email service provider typically uses its own DKIM selector. For example, Google Workspace, SendGrid, and Mailchimp can all have separate selectors under the same domain without conflict.

What’s the difference between a DKIM selector and a DKIM key?

The selector is the label used to locate the DKIM record in DNS, while the DKIM key is the actual cryptographic public/private key pair used to sign and verify emails.

Why does DKIM pass but DMARC still fail?

This usually happens because of DMARC alignment failure. The DKIM signature may validate successfully, but the d= domain in the DKIM signature does not align with the From: domain used in the email.

How often should DKIM selectors and keys be rotated?

Security best practices recommend rotating DKIM keys every 6–12 months. During rotation, both the old and new selectors should remain active temporarily to avoid validation failures during DNS propagation.