Following DKIM selector best practices means giving every signing key its own selector label and never overwriting one in place. A DKIM selector is the name before _domainkey in a DNS hostname that tells a receiving server which public key to fetch. This article covers how selectors work, how to read your own domain's selectors, and what a well-run set looks like. A common mistake is rotating a key by overwriting the same selector rather than publishing a new one alongside it.
Contents
What a DKIM selector is
A DKIM selector is the name carried as the s= tag in the DKIM-Signature header that tells a receiver which public key record to fetch (RFC 6376 s3.5, RFC 6376). It works alongside d=, the signing domain, to build one DNS lookup. Together they answer one question: which key verifies this signature.
For s=selector1 and d=example.com, the receiver queries selector1._domainkey.example.com as a TXT record. The record requires a p= public key; v=DKIM1 is recommended and must come first when present, and k= defaults to rsa if omitted (RFC 6376 s3.6.1).
A selector is not secret. Every message you sign shows its selector in plain text in the header, so anyone who receives your mail can see it (RFC 6376 s3.5). Choosing an obscure name buys nothing; the value comes from key strength and rotation discipline, not naming.
How DKIM selectors work end to end
DKIM verification runs as a DNS lookup, not a handshake. The sender's system signs a message with a private key, adds d= and s= to the DKIM-Signature header, and the receiver reads s=, builds the DNS query above, and fetches p= to verify the signature (RFC 6376 s3.6.2.1).
Multiple selectors can exist at once because each points to its own DNS record. A domain can run Microsoft 365 under selector1 and selector2 while a separate marketing platform signs under its own selector, all resolving independently.
Tags in a key record are separated by semicolons, and a tag name repeated in one list invalidates the whole record (RFC 6376 s3.2). DNS also limits each TXT string to 255 octets, so a 2048-bit key gets split across several quoted strings inside one TXT record (RFC 1035 s3.3; Google Workspace guidance).
Generate the new key
Create a 2048-bit RSA or Ed25519 keypair under a fresh selector name
Publish alongside the old
Add the new TXT record without touching the existing selector's record
Switch signing
Point the sending service at the new selector once the record resolves
Verify it passes
Check a sent message's headers and confirm DKIM=pass with the new s=
Retire the old selector
Remove the old TXT record a few days later, per NCSC guidance
Why selector hygiene matters
Selector hygiene matters because an old, unrotated key sitting behind one selector for years stays trusted until you revoke it with an empty p= value or remove its record. If that key leaks, anyone holding it can sign mail that verifies until you revoke or remove the record.
Reusing one selector across services with different keys can cause DKIM verification to fail for legitimate mail. DMARC may then fail too if aligned SPF does not pass. RFC 8301 requires verifiers to reject RSA keys under 1024 bits and to reject rsa-sha1 outright, so a key generated years ago may already fail checks a receiver enforces today.
NCSC calls DKIM "a stronger authentication mechanism than SPF" and recommends configuring it on every domain you send from (NCSC: create and manage a DKIM record).
How to check your domain's DKIM selectors
Start with a message you actually sent. Pull its raw headers and read the live s= and d= values in the DKIM-Signature line to see what your mail platform is using today.
Next, query selector._domainkey.yourdomain.com as a TXT record to confirm the key is published and readable. The free DKIM checker probes 18 selectors signed out and 46 signed in, plus up to 10 you type, and reports whether each publishes a v=DKIM1 key. It does not report key type, length, revocation or the t= flag, so treat a pass as presence, not strength.
Cross-check the wider picture with the SPF, DKIM and DMARC checker, which validates your DMARC record against RFC 9989 alongside SPF, though it does not look up DKIM keys itself. For Microsoft 365 domains, confirm both selector1._domainkey and selector2._domainkey resolve as CNAME records, never TXT, as Microsoft's own documentation specifies (Microsoft: configure DKIM).
- Every active sending service has its own selector, none shared
- Keys are RSA 2048-bit or Ed25519, none under 1024 bits
- No selector name contains a person's name, ticket ID or secret
- A record exists for each selector named in recent DKIM-Signature headers
- Old selectors are removed within days of a completed rotation
- Selector records use semicolons between tags, not commas
What good DKIM selector practice looks like
Good practice starts with plain, short selector names. Use something that describes the sender or rotation cycle, such as s1, s2, mkt2026, or a provider's own default like google; never encode ticket numbers or staff names, since the selector is visible in every message header.
- Key size, generate RSA at 2048 bits (RFC 8301 s3.2 sets 1024 as the floor, 2048 or more as the recommendation), and if you add Ed25519 under
k=ed25519, sign with it alongside RSA for backward compatibility (RFC 8463 s6) - Dual algorithms, run two selectors if signing with both RSA and Ed25519, since one selector holds only one key record (RFC 8463 s6)
- Rotation, publish the new key under a new selector, switch signing to it, then remove the old record a few days later, following NCSC's suggested roughly 12-month cycle; Microsoft 365 is the exception, since it rotates between its two fixed selectors and needs both CNAME records to stay published
- Separation by stream, use different selectors for your marketing platform, helpdesk and main mail server to make their keys easier to manage separately
Pro Tip: Before deleting a selector, check recent email headers or your mail platform's logs for its s= value, and confirm that every sender has switched to the new key.
Common misunderstandings about DKIM selectors
A selector is not a secret, and hiding it protects nothing; it appears in every signed message's headers regardless (RFC 6376 s3.5). DKIM passing also does not mean the domain is safe from spoofing on its own: DMARC (RFC 9989) is what tells a receiver what to do with mail that fails alignment, and a DKIM pass does not require d= to match the From address (see why is my DMARC failing).
Key size is often misread from the p= value. A key starting MIGfMA0 is 1024-bit, not 2048-bit; a 2048-bit RSA key starts MIIBIjAN, worth checking before assuming a record meets the 2048-bit size RFC 8301 recommends. Tags are separated by semicolons, not commas, despite some published examples showing v=DKIM1, k=rsa, with a comma (RFC 6376 s3.2).
Finally, rotating a key means publishing a new selector, not overwriting the DNS record behind the existing one (RFC 6376 s3.1). Overwriting risks a window during DNS propagation where signatures fail verification for mail already in transit.
Where ShieldMarc fits
ShieldMarc's free DKIM checker confirms selector presence across the probed names plus any custom entries you add, useful for a quick health check before or after a rotation. It tells you a selector publishes a key; it does not tell you the key is strong or still in active use.
The DKIM generator builds RSA 2048-bit or Ed25519 keys in the browser and outputs the TXT record and private key. Its Ed25519 output is SPKI-wrapped rather than the raw key RFC 8463 specifies, so use the RSA output for production records until that changes. For provider-specific setup steps, see the DKIM by provider guide rather than guessing at panel labels.
Starter includes DMARC aggregate reports; Trial, Professional and MSP exports include DKIM alignment, but do not tell you whether a particular selector is working. ShieldMarc does not validate key strength, revocation or the t= testing flag on any selector today, and the Security Grade excludes DKIM entirely from its scoring. Rotation discipline stays a manual practice; the platform supports it with visibility, it does not automate it.
In my view, that split is honest: a checker confirming presence and a report confirming alignment cover most of what a busy admin needs day to day, but nothing replaces reading the actual key material yourself before you trust it.
Start today
Pull a recent sent message and note its s= and d= values, then confirm the matching TXT record resolves. Run your domain through the free DKIM checker to see which of the probed selectors publish a key.
If a key is more than 12 months old or you cannot confirm its size, generate a fresh 2048-bit RSA key under a new selector, using the DKIM generator where you supply your own signing key, and schedule the old selector's removal for a few days after cutover. Start a 30-day trial with no card to track DKIM alignment pass rates alongside SPF and DMARC as you roll rotation out across domains.
Frequently asked questions
What happens if I delete a DKIM selector that is still in use?
Mail already signed with that selector's key can fail DKIM verification once receivers can no longer fetch its public key. If DMARC is at enforcement (p=quarantine or p=reject) and aligned SPF also fails, the message fails DMARC and may be quarantined or rejected.
Keep the old selector's record live for a few days after switching signing to a new one, as NCSC advises, so mail still in transit or delayed queues verifies correctly.
Can two DKIM selectors coexist safely?
Yes. RFC 6376 places no limit on how many selectors a domain publishes, and each is an independent DNS record. This is exactly how rotation and multi-provider signing both work, one selector per key or per sending service. Telling two senders with different keys to use the same selector can make verification fail for one of them.
Does the DKIM selector need to match anything in the From address?
No. The selector is a name chosen by whoever configures signing, made of letters, digits and hyphens with dots between parts (RFC 6376 s3.1), and it has no required relationship to the domain in the From header. For DKIM to satisfy DMARC, the d= domain must align with the From domain under relaxed or strict alignment; aligned SPF can satisfy DMARC instead (RFC 9989). The selector itself only builds the DNS query for the key; it carries no authentication meaning on its own.
Why does my DKIM checker show a selector but Google or Microsoft still fails the signature?
Finding a v=DKIM1 record does not prove it contains a usable public key, that the signing service uses the matching private key, or that the record's syntax is correct. Check for a mismatched key, a malformed tag list, or a record split incorrectly across TXT strings. Also check whether anything changes the message after it is signed: NCSC warns that modifying a message after signing, such as a disclaimer added by an outbound scanning service, breaks the DKIM signature.
ShieldMarc's free DKIM checker only confirms a v=DKIM1 key is present at a selector; paste a real message's headers into the email header analyser to see the receiving server's reported DKIM result, which ShieldMarc does not verify.
Sources
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- NCSC: Create and manage a DKIM record
- Microsoft: How to use DKIM for email in your custom domain