How to find a DKIM selector for any domain

A DKIM selector is a label that lets a domain publish more than one DKIM public key at the same time, each at a different DNS location. It exists because providers rotate keys, run multiple sending systems, or need to hand different keys to different ESPs - without selectors, a domain could only ever have one active DKIM key.

Why selectors matter beyond just finding them

• Key rotation: a provider can publish a new selector's key, switch signing over to it, and only then retire the old selector - with no gap where DKIM is unsigned.
• Granular control: different sending systems (marketing ESP, transactional mail, internal tools) can each sign with their own selector and key, so revoking one doesn't affect the others.
• Troubleshooting: knowing the exact selector a message used tells you exactly which DNS record to check, instead of guessing at a domain's entire _domainkey namespace.

Finding the selector from a real email

The most reliable method is reading the headers of a message the domain actually sent - selectors are not predictable from the domain name alone.

1. Open the message's original/raw headers (in Gmail: the three-dot menu > "Show original"; other clients have an equivalent "view source" option).
2. Find the `DKIM-Signature` header. It looks like:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=s1; t=1700000000;
    h=from:to:subject:date; bh=...; b=...

1. Read the `s=` field - that is the selector. In this example it's s1.

Confirming it with dig

Once you have the selector and the domain, look up the published key directly:

$ dig s1._domainkey.example.com TXT +short
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."

A result confirms the selector is live and shows the actual public key being used to verify that domain's signatures.

If you don't have a sample email

• Check your ESP's own dashboard. Most platforms show the exact selector(s) they're using for your domain under their authentication/domain settings - this is the fastest route if you set up DKIM yourself and just forgot the value.
• Guess common conventions as a last resort, not a first step. Providers often use predictable patterns (google for Google Workspace, s1/s2 for several ESPs, a date-stamped string for others) but these are conventions, not guarantees - always confirm with dig rather than assuming a guessed selector is correct just because it resolves to something.

What not to do

• Don't assume a selector that worked for one domain will be the same for another, even on the same ESP - selectors can be assigned per account or per domain.
• Don't delete an old selector's DNS record the moment you add a new one if you're mid-rotation - some signed mail already in transit or queued may still verify against the old key.
• Don't confuse the selector with the domain in the d= field - they're two different parts of the same header and both matter for the lookup.

DKIM selector quick reference

Example: full signature to selector walkthrough

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=yourdomain.com; s=mkt2026; t=1700000000;
    h=from:to:subject:date:message-id;
    bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
    b=AbCdEf123456...

From this header: the domain is d=yourdomain.com, the selector is s=mkt2026. The lookup location is therefore mkt2026._domainkey.yourdomain.com.

FAQ

Why do some domains have selectors with dates in them, like `20241015`? Date-stamped selectors are a common convention for marking when a key was generated, which makes key rotation and expiry tracking easier for the sender - it's a naming choice, not a technical requirement of the DKIM specification.

Can two different ESPs use the same selector name for the same domain? Technically yes if coincidence produces the same string, but it would cause one to overwrite the other's DNS record since they'd be publishing to the same hostname - in practice, ESPs use sufficiently specific selector names to avoid this collision.

MailPilot checks DKIM configuration as part of its authentication monitoring for every mailbox domain it warms, so you don't need to manually hunt down selectors

Does the selector itself need to stay secret? No - the selector is public by design, since receivers need it to look up the public key in DNS. What stays private is the signing key held by the sender; only the public half is ever published.

Why do some DKIM selectors look like random strings rather than readable words? Many providers generate selectors programmatically at key-creation time rather than using a human-chosen label, since the selector only needs to be unique and resolvable - readability was never a design requirement of the mechanism itself. just to confirm a signature is correctly published and verifying.