Skip to main content
Relaymetry

DKIM selectors and keys: what they are and how to find yours

A DKIM selector is just a label the sending domain picks to name one of its public keys. RFC 6376 makes the value arbitrary, so google, selector1, s1, and k1 are all equally valid. A verifier never guesses it: it reads the selector from the s= tag of the message’s DKIM-Signature header and looks up the key at <selector>._domainkey.<domain>. Because DNS cannot enumerate a domain’s selectors, you have to know yours before you can check it.

Quick answer

A DKIM selector is a label the sending domain picks to name one of its public keys, and its value is arbitrary. RFC 6376 §3.1 states that "the number of public keys and corresponding selectors for each domain is determined by the domain owner," so google, selector1, s1, and k1 are all valid selectors with no special meaning. The key itself lives in DNS at:

<selector>._domainkey.<domain>

A verifier never guesses the selector. It reads the s= tag from the message's DKIM-Signature: header and the signing domain from the d= tag, then queries <s=>._domainkey.<d=> for the public key (RFC 6376 §3.5, §3.6.2.1). There is no DNS mechanism to list the selectors a domain has published, so you have to know yours before you can look it up. If a lookup you expected to succeed returns nothing, that is the DKIM record not found case, which has its own set of fixes.

Why the selector is arbitrary, and why that matters

The selector exists for one reason: to let a single domain hold more than one DKIM key at a time. RFC 6376 §3.1 puts the choice of how many keys, and what to call them, entirely with the domain owner. A selector is just a DNS label. It can be a word, a number, or a date, and it carries no meaning to the verifier beyond pointing at one specific key record.

Two consequences follow, and both surprise people. First, you cannot deduce a domain's selector by inspection. Nothing in DNS enumerates the _domainkey subtree, so a checker can only test a selector you already supply. Second, the same domain can legitimately answer at several selector names at once, each returning a different key. A published key record at one of those names looks like this:

google._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

Per-provider selector conventions

Every sending platform picks its own selector and documents it on its DKIM setup page. The values below are the ones you will most often see, but treat them as commonly-observed conventions and confirm against your own platform's instructions, because a platform can change a selector or add a second one:

  • Google Workspace: google
  • Microsoft 365: selector1 and selector2
  • SendGrid: s1 and s2
  • Mailgun: k1
  • Amazon SES: long auto-generated tokens rather than a fixed word

Several of these platforms, including Microsoft 365, SendGrid, Amazon SES, and Mailgun, publish the key through CNAME delegation. Your record at selector._domainkey.yourdomain is a CNAME pointing at a record the platform controls and rotates, not a raw TXT value you paste once. That is why the exact selector and record format have to come from the platform rather than from a guess.

One domain, several selectors and keys

Because each key has its own selector, a domain that sends through more than one platform simply publishes one key per platform, each at its own <selector>._domainkey.<domain> name. A domain sending through Google Workspace, a transactional provider, and a marketing platform can carry three separate DKIM keys, and each message is verified against whichever selector its own DKIM-Signature: header names. The keys never collide, because they live at distinct DNS names.

The same design makes key rotation safe. To rotate, you publish a new key under a new selector, switch the platform to sign with it, and only then retire the old selector once no in-flight mail still needs it. At no point is there a window where a valid message cannot find its key, because the old and new selectors coexist during the handover.

The three ways to find your selector

There is no lookup that reveals a domain's selectors, so finding yours means reading it from one of three sources:

  1. A real message header. Send a message through your normal sending path to a mailbox you control, then open the original source (in Gmail, the three-dot menu, "Show original"). Find the DKIM-Signature: header. The s= tag is the selector and the d= tag is the signing domain. Together they give you the exact DNS name to query: <s=>._domainkey.<d=>.
  2. The platform's setup documentation. Google Workspace, Microsoft 365, SendGrid, Amazon SES, Mailgun, and the rest all publish the selector they use and the exact record to add. When you cannot read a live header, this is the authoritative source.
  3. A checker, once you know the selector. With the selector in hand, the DKIM checker confirms the record resolves and returns a non-empty key. A checker cannot discover a selector for you; it verifies one you already have.

If the record still does not resolve, or resolves to an empty key, work through DKIM record not found for the specific causes and fixes. Two nearby failure modes look like a selector problem but are not: when the key resolves yet mail still arrives unsigned, see DKIM published but unsigned; when the signature is present but fails against the body, see DKIM body hash did not verify.

Inside the key record: the tags

The TXT record at the selector name is a tag-value list defined by RFC 6376 §3.6.1:

  • v: version. If present it must be DKIM1, and it must be the first tag in the record.
  • k: key type. The default is rsa; the ed25519 type was added later by RFC 8463.
  • p: the base64-encoded public key. This is the only required tag. An empty p= has a specific meaning, covered below.
  • t: flags. y marks the domain as testing DKIM, which tells verifiers not to treat the mail differently from unsigned mail; s requires the i= identity to match d= exactly rather than be a subdomain of it.
  • h: the acceptable hash algorithms, as a colon-separated list.
  • s: the service types the key applies to, * for all or email for mail.
  • n: human-readable notes, ignored by software.

An empty p= is a revocation, not a gap. RFC 6376 §3.6.1 says plainly that "an empty value means that this public key has been revoked." A verifier treats a revoked selector as a permanent failure, never a temporary one. Platforms use this to retire an old key during rotation without deleting the record, so a selector whose p= has nothing after it is intentional. The fix is never to add a key back at that name; it is to sign with a current, live selector instead.

Key length and rotation

RFC 6376 §3.3.3 requires signers to use RSA keys of at least 1024 bits for long-lived keys, and requires verifiers to validate keys from 512 to 2048 bits. Read 1024 as the floor, not the target: the modern baseline is a 2048-bit RSA key, which is what the major mailbox providers expect to see. Keys larger than 2048 bits risk overflowing a single 512-byte DNS UDP response, which is part of why 2048 is the practical ceiling for RSA. The ed25519 keys from RFC 8463 are far shorter and avoid that packet-size pressure entirely, though not every receiver validates them yet, so platforms that offer ed25519 usually publish an RSA key alongside it.

Rotating keys on a schedule limits the damage if a private key ever leaks. Because each key carries its own selector, rotation is a publish-then-retire sequence rather than an in-place swap, and mail in flight is never left without a matching key. One thing the selector does not control is alignment: the d= domain your key signs for still has to line up with your visible From domain for DMARC to pass, which is DMARC alignment rather than a selector setting. Your DKIM keys sit alongside your SPF record and your DMARC policy in the same set of DNS records, all of which ladder up to email authentication.

Frequently asked questions

What is a DKIM selector?

A DKIM selector is a label the signing domain chooses to name one of its DKIM public keys. RFC 6376 section 3.1 says the number of keys and selectors for a domain is decided by the domain owner, so the value is arbitrary. A verifier reads the selector from the s= tag of the DKIM-Signature header and fetches the key at <selector>._domainkey.<domain>.

How do I find my DKIM selector?

There are three reliable ways. Read the s= tag in the DKIM-Signature header of a real message you sent (in Gmail, use Show original). Read your sending platform’s DKIM setup documentation, which names the selector it uses. Or run a DKIM checker once you know the selector to confirm the key resolves. DNS has no way to list every selector a domain has published, so you must already know it.

Can one domain have multiple DKIM records?

Yes. A domain can publish many DKIM keys at once, each under its own selector at <selector>._domainkey.<domain>. RFC 6376 section 3.1 designed selectors so that a domain can run several concurrent keys, one per sending platform and a second key during rotation, without them colliding.

What does an empty p= mean?

An empty p= (the tag present with no value) means the public key has been revoked, per RFC 6376 section 3.6.1. A verifier treats it as a permanent failure, not a missing record. Platforms often revoke an old selector this way during key rotation instead of deleting the record outright.

How long should a DKIM key be?

RFC 6376 section 3.3.3 requires signers to use RSA keys of at least 1024 bits for long-lived keys, and requires verifiers to validate keys from 512 to 2048 bits. The modern baseline is a 2048-bit RSA key; 1024 is the floor, not the target. RFC 8463 adds ed25519 as a compact alternative key type.

Other SPF, DKIM & DMARC reference pages

References

Browse all guides →