A DKIM selector is a short label that tells a receiving server which public key to fetch in order to verify a message's signature. It is the part of DKIM that confuses people the most: the selector is not a password, not a setting in the message body and not something you see in the visible email. It lives in a header and in a DNS hostname, and if the two do not match, DKIM fails. People search for "what is a DKIM selector", "how to find my DKIM selector" and "DKIM selector examples" because a setup guide asked them to publish a key at selector._domainkey and they do not know what to put for the selector, or because a checker asks for a selector before it will test a domain. This guide explains how selectors work, how to find the one a message used, how to find the one your service uses, how to choose selector names and how to manage them over time with multiple senders and key rotation. We do not invent provider selectors; copy yours from the service that signs your mail, such as the DKIM records in your dashboard domain settings. For the overall record, see DKIM record explained.
What a DKIM selector is
When a sending server signs a message with DKIM, it adds a DKIM-Signature header. Two tags in that header identify the key: d= is the signing domain and s= is the selector. The receiver builds a DNS name from them, s._domainkey.d, and looks up the TXT (or CNAME that leads to a TXT) record there. That record holds the public key. The receiver uses it to check the signature. If the record is missing or the key does not match, DKIM fails.
The reason selectors exist is flexibility. A domain can publish many keys at once, each under a different selector. That allows several services to sign for the same domain without sharing a private key, and it allows you to rotate keys without breaking mail in flight.
What a selector looks like
Selectors are plain labels such as s1, mail or default, or longer strings that include a date or a service code. They are chosen by the system that signs. A made-up example of a header and the DNS name it points to:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...
DNS name: selector1._domainkey.example.comThis is an illustration with invented values. Your selectors will be different, and you should never copy another provider's selector into your DNS.
How to find the selector in a message
- Send a test message from the system you are checking to a mailbox you can open.
- Open the message source or the original headers. See how to read email headers.
- Find the line starting
DKIM-Signature:. - Read the value after
s=(the selector) andd=(the domain). - Look up
selector._domainkey.domainas a TXT record to see the published key.
A message can carry more than one DKIM signature, for instance one added by your sending service and one by an intermediate system. Each has its own selector and domain. What matters for DMARC is that at least one valid signature uses a domain that aligns with your From domain.
How to find the selector your service uses
The service that signs your mail tells you. Look in its domain authentication or sender setup area and copy the host names and values it shows. For ours, the DKIM records are listed in your dashboard domain settings; publish them exactly as shown. If you cannot find them:
- Send a test message through the service and read the
s=tag as above. - Check your DNS zone for existing names ending in
._domainkey, which can show selectors in use by other senders. Do not delete any you do not recognise until you know what signs with them. - Ask the service's support to confirm the selector and the record it expects.
Can you guess a selector from DNS?
Not reliably. DNS cannot list all names under _domainkey, so a checker needs the selector to look up the key. Some tools try common names, and that can find a key, but a failed guess does not mean DKIM is absent. When a checker asks for a selector, give it the one from a real message header or from your service's instructions. Our SPF, DKIM and DMARC checker is a quick place to confirm what is published.
Choosing selector names
If you control the signing system, the name is yours to pick. Good selector names help later maintenance.
- Make them descriptive: include the sender or purpose, such as the stream name, and a date or version so you can tell keys apart when rotating.
- Keep them unique per sender and per key. Never reuse a selector with a different key while old messages may still be verified.
- Avoid secrets in the name. The selector appears in headers of every message.
- Document them, with owner, purpose and key date, so retirement is safe.
Selectors and key rotation
Rotating a DKIM key means publishing a new key under a new selector, switching the signer to it and, after a safe overlap, removing the old one. Because the selector is part of the DNS name, old and new keys coexist, and messages signed with the old key still verify while they are in transit. See DKIM key rotation. Some services publish keys as CNAMEs to names they control so they can rotate for you; see CNAME records explained.
Multiple senders, multiple selectors
A domain that sends from a mailbox suite, a sending service and a support desk will normally have at least three selectors, one per system. That is the correct setup: each signs with its own key. Problems come from leftovers, such as selectors from services you stopped using, which leave valid keys that nobody monitors. Audit your _domainkey names when you review vendors. See managing multiple vendors on one domain.
Troubleshooting selector problems
| Symptom | Likely cause | Fix |
|---|---|---|
| DKIM fails, "key not found" | Record published at the wrong name or not at all | Compare the s= and d= in the header with your DNS |
| Key found but signature fails | Wrong key, value corrupted by quotes or breaks, or key rotated without the signer updated | Re-copy the value and ensure the signer uses the matching key |
| Doubled domain in DNS name | Panel appended the domain to a full hostname | Enter only selector._domainkey in such panels |
| Checker cannot test | Selector not provided | Read it from a message header |
| Passes, but DMARC fails | Signing domain does not align with the From domain | Sign with your own domain, not the service's. See alignment |
Checklist
- Know which systems send as your domain.
- For each, find its selector from the setup page or a test message.
- Confirm each record exists with a TXT or CNAME lookup.
- Check that signing domains align with your From domain.
- Record owners and dates, and retire unused selectors after confirming nothing signs with them.
Publish your DKIM records from the dashboard Copy the exact selector hostnames and values, then verify them with the free checker.
References and further reading
Frequently asked questions
What is a DKIM selector?
A label in the DKIM-Signature header (the s= tag) that tells receivers which public key to fetch from selector._domainkey.domain in DNS.
How do I find my DKIM selector?
Read the s= value in the DKIM-Signature header of a test message, or copy the hostnames from your sending service's domain authentication page.
Can a domain have more than one DKIM selector?
Yes. Each sender or key can use its own selector, which lets several services sign for the same domain and allows key rotation.
Is a DKIM selector secret?
No. It appears in the headers of every signed message. Only the private key is secret and it never appears in DNS.
Why does a checker ask for my selector?
DNS cannot list every name under _domainkey, so the tool needs the selector to build the lookup name. Take it from a real message header.