Understanding DKIM Selectors: What They Are and How to Manage Them

When a receiving mail server validates a DKIM signature, it needs to fetch the public key that matches the signature. But a domain can publish many DKIM keys at once — for different email providers, different departments, or different rotation cycles. The DKIM selector is the mechanism that tells the receiving server exactly which key to look up. Understanding selectors is essential for anyone managing email authentication, debugging delivery failures, or planning a key rotation.

What Is a DKIM Selector?

A DKIM selector is a short string — chosen by you or your email provider — that forms part of the DNS name under which the DKIM public key is published. It acts as a label that uniquely identifies a particular key within a domain.

The DNS record containing the public key is always published at the following location:

selector._domainkey.example.com

For example, if your selector is google and your domain is example.com, the public key is found at:

google._domainkey.example.com

You can verify this manually with a DNS lookup:

dig TXT google._domainkey.example.com

The response will contain a TXT record starting with v=DKIM1, followed by the key type (k=rsa or k=ed25519) and the Base64-encoded public key (p=...). If the record is missing or the key does not match the signature, DKIM verification fails.

How DKIM Selectors Work

When your mail server or email service provider sends a message, it signs the email with a private key and inserts a DKIM-Signature header. That header includes, among other fields:

• d= — the signing domain (e.g. example.com)
• s= — the selector (e.g. google)
• h= — the list of headers that were signed
• b= — the cryptographic signature itself

When a receiving mail server gets the message, it:

1. Reads the d= and s= values from the DKIM-Signature header.
2. Constructs the DNS name s._domainkey.d — for example, google._domainkey.example.com.
3. Fetches the TXT record from DNS and extracts the public key.
4. Uses that public key to verify the cryptographic signature in the header.
5. If the signature is valid and the domain aligns with the From: header, DMARC DKIM alignment passes.

The selector is the bridge between the signature in the email and the key in DNS. Without it, a receiver would have no way of knowing which of potentially many published keys to use for verification.

Common Selector Names

Selectors can be any string, but email service providers typically use predictable values. Knowing the common ones helps when you need to diagnose a DKIM failure quickly.

Microsoft 365 is a notable example of a provider that uses two selectors by design — selector1 and selector2 — to support seamless key rotation. At any given time, one selector is active for signing while the other is published but not yet in use.

Why Multiple Selectors Matter

A single domain often sends email through several independent services: a primary mail server, a marketing automation platform, a transactional email provider, and perhaps a support ticketing system. Each of these may use a different DKIM key — and therefore a different selector.

There are three main reasons to maintain multiple selectors:

• Different sending services. Each ESP or mail system signs with its own private key. The corresponding public key must be published at a unique selector so receivers can verify signatures from each service independently.
• Key rotation. When you rotate a DKIM key, you need the old key to remain valid long enough for in-flight messages to be delivered and verified. A second selector lets you publish the new key before retiring the old one, with no gap in authentication coverage.
• Parallel deployment. During a migration from one ESP to another, or when testing a new signing configuration, running two selectors in parallel lets you validate the new setup without disrupting existing mail flows.

Because selectors are independent DNS records, there is no limit to how many you can publish simultaneously. Each one maps to a distinct key pair and can be added, replaced, or removed without affecting the others.

How to Look Up a DKIM Selector

There are two common approaches to looking up a DKIM selector for a domain.

Using command-line tools. If you already know the selector name, use dig or nslookup to query the DNS record directly:

dig TXT selector._domainkey.example.com
nslookup -type=TXT selector._domainkey.example.com

A successful response includes a TXT record containing v=DKIM1 and a p= field with the Base64-encoded public key. An empty response or NXDOMAIN means the selector does not exist in DNS.

Using DMARCFlow DKIM Checker. If you do not know which selector is active, the easiest approach is to use the DMARCFlow DKIM Checker. Enter your domain, and the tool will probe common selectors and display the key details, validity, and algorithm for each one found. You can also retrieve the selector directly from a message header — look for the DKIM-Signature header in a sent email and read the s= value.

DKIM Key Rotation Best Practices

Rotating DKIM keys periodically reduces the risk that a compromised private key can be used indefinitely to forge signatures. Most security frameworks recommend rotating at least once per year; organisations with stricter security requirements often rotate every 90 days.

The correct sequence for a safe rotation is:

1. Generate the new key pair. Create a new private key and its corresponding public key. Assign it a new selector name (e.g. increment from s1 to s2, or use a date-based name like 2026q2).
2. Publish the new selector in DNS. Add the new TXT record at new-selector._domainkey.example.com. Do not yet switch your mail server to sign with the new key.
3. Wait for DNS propagation. Set the TTL on the new record to a low value (300–600 seconds) before publication to allow fast propagation. Wait at least the TTL duration — typically 5 to 15 minutes — before proceeding.
4. Switch signing to the new key. Update your mail server or ESP configuration to sign outgoing messages with the new private key and reference the new selector in the DKIM-Signature header.
5. Keep the old selector live. Leave the old selector's DNS record published for at least 48 hours (ideally 7 days) after switching. Messages that were signed with the old key and are still in transit need the old public key to verify correctly.
6. Remove the old selector. Once you are confident no in-flight messages reference the old selector, delete the old DNS TXT record and revoke or securely destroy the old private key.

The dual-publish window — the period when both the old and new selectors are live in DNS — is the most critical phase. Removing the old record too soon will cause DKIM failures for messages that were signed before the switch but delivered after it.

How DMARCFlow Helps

DKIM selector issues surface in DMARC aggregate reports as failed DKIM results or as records where DKIM alignment does not pass. DMARCFlow parses every DMARC report and provides per-record insight into DKIM outcomes, making it straightforward to identify selector-related problems.

• DKIM result tracking. DMARCFlow shows the DKIM authentication result — pass, fail, neutral, temperror, or permerror — for every sending source in your DMARC reports. A sudden rise in DKIM failures often indicates a selector that was removed too early during a rotation, or a new ESP that has not yet been configured with a valid key.
• Alignment insight. A DKIM pass is necessary but not sufficient for DMARC. The authenticated domain in the d= tag must also align with the From: header domain. DMARCFlow evaluates alignment for every record and clearly flags cases where DKIM passes but alignment fails — the typical symptom of a third-party ESP signing with its own domain rather than yours.
• Detecting missing selectors. When a sender appears in your DMARC reports with a DKIM result of none or permerror, DMARCFlow surfaces that source so you can investigate whether the selector is missing from DNS, misconfigured, or simply not yet set up for that sending service.
• Security score and maturity tracking. DKIM alignment is a direct input to your domain's security score and DMARC maturity level in DMARCFlow. Selector problems that reduce your DKIM pass rate are reflected immediately in your score, and the recommendations engine tells you exactly which senders to fix.

Conclusion

DKIM selectors are a small but critical piece of the email authentication puzzle. They make it possible to publish multiple DKIM keys for a single domain, enabling support for several sending services at once and providing a safe path for key rotation. Without a valid selector in DNS, DKIM verification fails — and a DKIM failure means one fewer mechanism available to pass DMARC.

The most common selector-related problems — a missing record, an expired key left in place, or an ESP signing with the wrong domain — all produce patterns that are visible in DMARC aggregate reports. Monitoring those reports consistently is the fastest way to catch selector issues before they affect deliverability.

DMARCFlow gives you that visibility automatically. It parses your DMARC reports, classifies every DKIM result by outcome and alignment, and surfaces actionable recommendations so you can keep your selectors healthy and your email authentication solid.