How to find my DKIM selector?

A DKIM selector is the short label that tells a receiver where in DNS to find your public DKIM key. If your DKIM-Signature header says d=example.com; s=s1, the receiver looks up s1._domainkey.example.com to find the public key. Selectors are how one domain can have multiple active DKIM keys at once — different services, different key rotation schedules, different algorithms. The trick is finding what selectors your domain currently uses, because unlike SPF and DMARC there is no fixed DNS location to query.

Why DKIM is selector-based

Imagine one domain with four mail flows: Google Workspace for employee mail, SendGrid for transactional, Mailchimp for newsletters, and Zendesk for support. Each signs with its own key. If every signer had to share one DNS location, rotation would be a nightmare and any service could delete another service's key.

Selectors solve this by namespacing the keys:

google._domainkey.example.com.    TXT "v=DKIM1; k=rsa; p=MIIBIjANB..."
s1._domainkey.example.com.        TXT "v=DKIM1; k=rsa; p=MIIBIjANB..."
mailchimp._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANB..."
zendesk1._domainkey.example.com.  TXT "v=DKIM1; k=rsa; p=MIIBIjANB..."

Each service independently uses its own selector. The receiver only looks up the selector referenced in the signature on each specific message.

Method 1: read a signed message

The easiest way to find an active selector is to look at a real signed email. Open any message you have received from your own domain — even one you sent to yourself — and view the raw headers.

Look for DKIM-Signature: and find the s= tag:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
  s=dkim202601; t=1704902432; ...

In this case the selector is dkim202601. The record lives at dkim202601._domainkey.example.com.

In Gmail, click the three-dot menu on a message and select "Show original". In Outlook, File → Properties → Internet headers. In macOS Mail, View → Message → All Headers.

Method 2: query common selectors

If you do not have a signed message handy, you can guess. Most ESPs use predictable selectors:

• Google Workspace: google
• Microsoft 365: selector1, selector2 (both are CNAMEs to selector1-example-com._domainkey.example.onmicrosoft.com)
• SendGrid: s1, s2, or em+domain-id CNAMEs
• Mailchimp: k1 or mx1
• Mailgun: mx, mailo, or smtp
• Postmark: pm or a longer identifier
• Amazon SES: three CNAMEs like abc123._domainkey, def456._domainkey, ghi789._domainkey
• SpamExperts / SolarWinds MSP: mailfilter (2026: also default)
• Generic / hand-built: default, dkim, mail, or the year like dk2026

Query with dig:

dig +short TXT google._domainkey.example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT s1._domainkey.example.com
dig +short TXT default._domainkey.example.com

A response means the selector is published. An empty response means either the selector is not used or the subdomain does not exist.

Method 3: check your sending service's dashboard

Every ESP shows you what selector they use in the DKIM setup section. In Google Workspace it is under Apps → Google Workspace → Gmail → Authenticate email. In Microsoft 365 it is Security & Compliance → Email Auth → DKIM. In SendGrid it is Sender Authentication → Domain Authentication.

If a service claims DKIM is enabled but you cannot find the selector, the ESP is signing with its own domain, not yours. That is technically DKIM-valid but fails DMARC alignment. Fix it by enabling "custom domain authentication" or whatever the equivalent feature is called in that platform.

Method 4: enumerate via _domainkey

You cannot list all subdomains of _domainkey.example.com because DNS does not support wildcard enumeration without either a zone transfer (almost always disabled) or NSEC/NSEC3 walking (only works on DNSSEC-signed zones that do not use NSEC3 with opt-out).

What you can do is check if there is a _domainkey TXT record at the exact name. Some domains publish a DKIM policy record (_domainkey.example.com) that lists signing practices. This is rare but if present it gives hints.

Reading the selector record

A DKIM record looks like:

v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Tags:

• v=DKIM1 — version.
• k=rsa or k=ed25519 — algorithm.
• t=s — strict mode; the From domain must exactly match the d= tag in the signature (no subdomain flexibility).
• t=y — testing mode. Receivers should not penalize signature failures. Remove this once you are confident.
• p=... — the base64-encoded public key. If p= is empty, the key is revoked.
• h=sha256 — allowed hash algorithms.
• s=email — service type.

A p= value longer than 255 characters is usually split across multiple TXT strings. Most DNS UIs handle this transparently.

Rotation

Best practice in 2026 is to rotate DKIM keys every 6 to 12 months. The pattern:

1. Publish a new selector (e.g., dk2026q2) alongside the old one.
2. Configure your signer to use the new selector.
3. Send through the new selector for two weeks.
4. Revoke the old key by either deleting the record or setting p= to empty.

Never delete the old selector while messages signed with it are still in flight — they will fail verification. 7 days is a conservative grace period.

Troubleshooting

"Receiver says DKIM fail, but the record exists." Check for whitespace in p=. Some DNS providers mangle the key when the record is longer than a certain length. Also check the signature's b= value — if the body was modified in transit (mailing list injecting a footer, MTA rewriting), the signature fails.

"Multiple TXT records at the selector." Only one is allowed. Most resolvers pick one at random, which breaks verification intermittently.

"The signature passes but DMARC fails." The d= tag does not align with the From header. Change your ESP config to sign with your own domain.

When to use IntoDNS.ai

IntoDNS.ai scans a long list of common selectors across all major ESPs and reports which ones are active on your domain. It shows the key length, algorithm, testing flag, and whether the record is properly formatted. If you are onboarding a new sending platform and need to verify your DKIM setup before going live, it saves the guesswork of querying each selector by hand.

Debugging a failing DKIM signature

When DKIM fails verification, the problem is usually one of:

1. Body modification in transit. A mailing list, spam scanner, or gateway added a footer or altered content. The signature was computed over the original body; the modified body produces a different hash. Fix: use c=relaxed/relaxed canonicalization so trivial whitespace changes do not break the signature. Severe modifications cannot be fixed at the DKIM layer; ARC helps.

2. Header modification. The signer chose to include headers like From, To, Subject in the signature. If a downstream relay rewrites any of them, DKIM fails. Limit signed headers to stable ones.

3. Wrong selector in DNS. The signature's s= tag does not match any published selector. Check for typos.

4. Public key mismatch. The private key on the signer does not match the published public key. Happens after a rotation where one side updated but the other did not.

5. Key too long for a single TXT string. 2048-bit keys exceed 255 characters. Some DNS providers truncate or split incorrectly. Verify with dig +short TXT selector._domainkey.example.com and ensure the returned value reassembles correctly.

6. Base64 padding. A p= value with missing = padding can parse inconsistently across resolvers.

Selector naming conventions

There is no technical requirement for selector names. Any valid DNS label works. Conventions that scale well:

• Service-based: google, mailchimp, sendgrid.
• Year/quarter-based: 2026q2, jan2026.
• Rotation-tracking: s1, s2, alternating.
• Environment-separated: prod-s1, stage-s1.

Avoid selectors that look like filenames or contain special characters beyond hyphens. Short names save bytes in the DKIM-Signature header.

Multiple active selectors on one service

It is fine to have two selectors active simultaneously during a rotation window. The signer picks one per message; verifiers look up the selector stated in the message's signature. No conflict.

What is not fine is:

• Two TXT records at the same selector name. Resolvers pick randomly.
• A selector that was revoked (p= empty) but is still being signed with. All verifications fail.
• A CNAME and a TXT at the same selector name. RFC violation; behavior varies.

Automating selector discovery

For operational visibility across many domains, automate the discovery:

SELECTORS="google s1 s2 selector1 selector2 default dkim mail em k1 mailo smtp pm mxs mailfilter"
for sel in $SELECTORS; do
  result=$(dig +short TXT "${sel}._domainkey.example.com")
  [ -n "$result" ] && echo "$sel: ACTIVE"
done

Run this across your domain inventory and you get a matrix of which selectors each domain uses. IntoDNS.ai does this discovery automatically as part of a scan.