DKIM Selector Finder

The problem: checking DKIM without knowing the selector

Traditional DKIM tools ask for a domain and a selector. But most users don't know their DKIM selector. Result: they can't verify their configuration.

The DKIM Selector Finder solves this problem. Enter a domain, and the tool probes DNS to surface the active DKIM selectors among known names, without requiring you to type one in.

How does the discovery work?

1. Provider detection via MX

The tool queries your domain's MX records to identify your email providers, then tests their known selectors first:

• *.google.com → Google Workspace → selector google
• *.outlook.com → Microsoft 365 → selectors selector1, selector2
• *.mcsv.net → Mailchimp → selectors k1, k2, k3

2. Probing the catalog of known names

The tool tests known selector names in parallel by querying:

selector._domainkey.your-domain

For each name, a DNS TXT query is sent. If a DKIM record answers, it is analyzed. The scan always probes the full catalog of known names (generic and provider-specific, close to a hundred in total): provider detection via MX only reorders the internal priority, it does not change the number of names probed. The scan does not guarantee finding a custom selector, because discovery is never exhaustive (see below).

3. Analysis of each selector found

Each selector found is analyzed using the same engine as our DKIM Checker:

• Key type: RSA or Ed25519
• Key length in bits, decoded from the public key
• Record validity
• Security alerts (weak key, revoked key, test mode, invalid format)
• CNAME detection (delegation to provider)

Why "no selector found" proves nothing

This is the most important point to understand. DNS does not allow enumerating a zone's selectors: there is no wildcard on *._domainkey, and no central registry of selectors (RFC 6376). A selector's value is chosen freely by the operator of the signing domain, so it is unpredictable.

Concretely, this tool can only test a list of known names. An empty result simply means none of those names answered, never that the domain has no DKIM. A custom selector (campaign-2024-q3), a random token (Amazon SES), or a dynamically generated identifier (hash, UUID) escape the catalog by design.

When the catalog finds nothing, the reliable method is to read the selector directly from a received email (see the dedicated section below). It's the only way to get the real selector without guessing it.

When should you use this tool?

DKIM selectors for major providers

These values are common or observed, not guarantees: a provider may change its convention, allow a custom selector, or publish its key via a random CNAME token. No entry below is "the" guaranteed official selector of a provider.

This table covers the most common providers. The tool probes close to a hundred selector names in total, with no guarantee of exhaustiveness.

Why selector1 and selector2 (key rotation)

Many domains expose two selectors (selector1/selector2 at Microsoft, s1/s2 at SendGrid, brevo1/brevo2 at Brevo). This is not a duplicate: it's the key rotation mechanism.

At any given moment, one selector holds the active key (the one signing outbound emails); the other holds a standby key, already published in DNS. To rotate the key without interruption, the operator switches signing to the standby key, already propagated, then replaces the old one. No email is left without a valid signature during the transition.

M3AAWG recommends annual or biannual rotation (an observed frequency, not a universal rule nor "mandatory"); a short or aging key justifies more frequent rotation. If discovery surfaces only one selector, seamless rotation is impossible: planning for a second selector is good hygiene.

Find the real selector from a received email

This is the most reliable method, with no false negatives: the selector is written in the DKIM-Signature header that the sending server adds to every signed message. Open an email received from the domain and look for the s= tag:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...

Here, the selector is selector1 and the signing domain (d=) is example.com: the key therefore lives at selector1._domainkey.example.com.

Where to display the raw header by webmail:

• Gmail: open the message, ⋮ menu (three dots) at the top right, then Show original. Find the DKIM-Signature line and read s=.
• Outlook / Microsoft 365: open the message, File → Properties (desktop client) or ⋯ menu → View → View message source (web). Locate DKIM-Signature.
• Apple Mail: menu View → Message → All Headers.

Once you have the selector, paste it into the DKIM Checker to inspect the key in depth.

Manual method: dig / nslookup

If you know (or suspect) a selector, you can query DNS directly, without this tool:

dig TXT selector._domainkey.example.com +short

On Windows, the equivalent is:

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

A response containing v=DKIM1; ...; p=... confirms the selector exists and exposes the public key. An absence of response only means that this specific name does not resolve, not that the domain lacks DKIM.

Limitations of catalog-based discovery

DNS does not allow listing a zone's subdomains (no wildcard enumeration on *._domainkey). Discovery relies on a catalog of known selectors.

What will be found:

• Common selectors from the providers in the catalog
• Generic selectors (default, dkim, mail, s1, selector1, etc.)
• Common numeric selectors (dkim1, dkim2, k1, k2)

What will not be found:

• Custom or random selectors (e.g., campaign-2024-q3)
• Dynamically generated selectors (hash, UUID, Amazon SES tokens)
• Selectors published on a sending or bounce subdomain (e.g., bounce.yourdomain.com, mail.yourdomain.com). For those, re-run discovery on the relevant subdomain, or read the d= and s= in the header of an email sent from that flow.

For those cases, the safe path remains the DKIM-Signature header of a received email (see above).

Pitfalls behind a "not found" record

A known selector can exist without answering cleanly. Before concluding there is no DKIM, check these common causes:

• CNAME not yet propagated: many providers (Microsoft 365, SendGrid, Brevo, Amazon SES) publish the key via a CNAME pointing to their infrastructure. As long as the delegation hasn't propagated, or if it was removed, resolution fails.
• Revoked key: a record that is present but has an empty p= value means the key has been revoked (RFC 6376). The selector exists, but the key is dead. This is normal during a rotation, suspect if it lingers.
• Split or truncated record: a 2048-bit key exceeds the 255-octet limit of a TXT string and must be split into several concatenated segments. Incorrect splitting makes the key invalid.
• Selector on another domain: the signature's d= tag may point to a subdomain or a separate sending domain. The key is then not under your apex.

Understanding a selector's key strength

Finding the selector is only half the job: the key still needs to be strong. For each selector discovered, the tool decodes the public key and infers its type and length.

Very short RSA keys are another story: 512 bits factors in a few hours and 768 bits was publicly broken back in 2009 (Red Sift). Those are broken keys, never to be confused with 1024 bits, simply weak and to be rotated.

Ed25519 produces a fixed 256-bit key, cryptographically strong, but its interoperability is limited: according to Red Sift tests, Gmail, Microsoft 365, and Yahoo do not validate (or reject) Ed25519 signatures. In practice, publish Ed25519 alongside an RSA 2048 key, never alone.

The tool also flags two states to watch: a revoked key (empty p=) left in DNS, and a selector in test mode (t=y) often forgotten after going live, which makes the message treated as unsigned.

Which tool for what?

Selector discovery is the first step when you don't know the term "selector" or the value to enter. It gives you the list of active selectors. To go further:

1. You don't know any selector → start here, with discovery. The tool builds the inventory of active selectors and providers.
2. You have a specific selector to inspect → move to the DKIM Checker to analyze its key, validity, and configuration in detail.
3. You have an email at hand → the Email Header Analyzer extracts the s= and d= directly from the signature, no guessing.
4. You're preparing a new key → the DKIM Generator creates an RSA or Ed25519 pair ready to publish.

FAQ - Common questions

Q: What is a DKIM selector?

A: A DKIM selector is an identifier used to locate the DKIM public key in DNS. It is published at selector._domainkey.yourdomain.com. Each email provider uses its own selector, which allows multiple DKIM signatures to be active simultaneously.

Q: How can I find my DKIM selectors without sending an email?

A: This tool probes DNS: it tests a catalog of known selector names directly against your zone, without sending an email. It first detects your providers via MX to prioritize the right selectors. If nothing comes up, the most reliable path is to read the s= tag in the DKIM-Signature header of an email you received from that domain.

Q: What are the default DKIM selectors for major providers?

A: Google Workspace uses google. Microsoft 365 uses selector1 and selector2. SendGrid uses s1 and s2. Mailchimp uses k1, k2, and k3. Brevo uses brevo1 and brevo2. Amazon SES Easy DKIM publishes random tokens via CNAME (no fixed selector). These are common values, not guarantees. See the provider table above.

Q: Can you check DKIM without knowing the selector?

A: Yes, that's exactly what this tool does. Unlike traditional DKIM checkers that require a selector, it automatically tests known names in DNS, bearing in mind that a custom selector can escape this list.

Q: What does "DKIM selector not found" mean?

A: No TXT record answers for the tested names. This does not prove the absence of DKIM: DNS does not allow enumerating a zone's selectors (RFC 6376), the tool only tests a list of known names. Possible causes: a custom selector not in the catalog, a CNAME not yet propagated, a revoked key (empty p=), or DKIM genuinely not configured. To settle the doubt, read the DKIM-Signature header of a received email.

Q: Can the tool find all DKIM selectors?

A: No, and no tool can. Custom or dynamically generated selectors (hash, UUID, random tokens) will not be detected. For those cases, read the DKIM-Signature header of a received email (s= tag) or query the selector directly with dig TXT selector._domainkey.yourdomain.com.

Related tools

Useful resources

• RFC 6376 - DKIM Signatures (official specification)
• RFC 8463 - Ed25519 for DKIM (Ed25519 signatures)
• Google - Set up DKIM (Google Workspace guide)
• Microsoft - DKIM in Exchange Online (Microsoft 365 guide)