DKIM glossary
What is a DKIM selector and how do you find it?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
A DKIM selector is the label that tells a receiving server which public key to use to verify a message. It's the s= value in the DKIM-Signature header, and it points to a DNS record at <selector>._domainkey.<domain>. To find yours, open a sent message's raw headers and read the s= tag.
selector at a glance | |
|---|---|
| Tag | s (selector) |
| Valid values | Any DNS-label string the sender chooses, e.g. google, selector1, s1, k1 |
| Default | No default — every signature carries a selector, and each key needs its own. |
| Where it goes | The s= tag inside the DKIM-Signature header; also the leftmost label of the DNS key name. |
How selector works
A domain can publish many DKIM keys at once, so a receiver needs to know which one signed the message in front of it. The selector is that pointer. The s= tag in the DKIM-Signature header names it, and the receiver fetches the matching public key from DNS at <selector>._domainkey.<yourdomain>.
To find your own selector, open a message you've sent and view its raw headers — in Gmail, use the three-dot menu and choose Show original. Read the s= value in the DKIM-Signature line. Selector names vary by sender: Google Workspace often signs with google, and Microsoft 365 commonly uses selector1 and selector2. Labels like s1 or k1 are common at various ESPs, so the header is the only authoritative source.
Selectors are what make key rotation painless. Publish a new key under a new selector, switch signing to it, then retire the old one — with no window where mail goes out unsigned. That's why a single domain routinely has several selectors live at the same time.
Correct record vs common mistake
Correct
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...The s= selector resolves to a real key at selector1._domainkey.example.com, so the receiver can fetch the public key and verify the signature.
Common mistake
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=oldkey; ...Signing with a selector whose DNS record was deleted. The receiver looks up oldkey._domainkey.example.com, finds nothing, and DKIM fails.
Troubleshooting selector
| Issue | Likely cause | Fix |
|---|---|---|
| DKIM fails with 'no key for signature' | The selector in the header has no matching TXT record in DNS | Publish the key at <selector>._domainkey.<domain>, or point the sender at a selector that already exists |
| Can't tell which selector to publish | Vendor docs are vague and the header hasn't been checked | Send a test message to yourself, read the s= tag in the raw headers, and create exactly that selector |
| Key rotation broke signing | Signing switched to the new selector before its DNS record propagated | Publish and propagate the new selector's key first, then move signing over, then retire the old selector |
Why it matters for MSPs
Every client sender — Microsoft 365, Google, the CRM, the invoicing tool — signs under its own selector, so one tenant can easily have a dozen. Miss one while auditing and a legitimate stream fails DKIM quietly. Track selectors per sender, per client, not just per domain, or alignment gaps hide in plain sight.
Trusted by MSPs
“We increased our meetings booked by 21% and slept better at night knowing our emails are now secured”
Marc-André Campagna — CEO, gaiiaRead the case study →
DMARC software that does the work
Palisade discovers which selectors each client domain is actually signing with, straight from the DMARC reports rather than guesswork, so every legitimate sender stays aligned as it walks the domain from p=none to reject.
1 domain free up to 1,000 emails/month
Questions readers ask