InboxRatio
Check your domain

Glossary term

DKIM selector: the label that says which key signed your mail

What a DKIM selector is

A DKIM selector is the label that tells a receiving server which public key to fetch when verifying a DKIM signature. Defined in RFC 6376, it appears as the s= tag inside every DKIM-Signature: header, and it forms the first component of the DNS name where the matching public key is published:

{selector}._domainkey.{domain}

A signature carrying d=yourbrand.com; s=s1 sends the verifier to a TXT record at s1._domainkey.yourbrand.com. The selector string itself is arbitrary (s1, mail2026, google, k3, a provider's brand name) and carries no meaning beyond naming a key slot.

The reason selectors exist at all: a domain signs with more than one key. Your ESP holds one private key, your ticketing system another, your corporate mail a third, and each rotation cycle mints replacements. Without a namespace to tell the keys apart, one domain could publish exactly one key and every sending system would have to share it. The selector turns _domainkey into a directory rather than a single slot, which is what makes multi-platform sending and routine key rotation possible.

How a selector differs from the signing domain

The DKIM-Signature: header names two identities, and they do different work.

The signing domain (d=) is the accountable party — the domain claiming responsibility for the message, the domain DMARC compares against your From: header for DKIM alignment, and the domain receivers attach reputation to.

The selector (s=) is a routing detail inside that domain's namespace. It locates the key; it confers nothing. Receivers do not score selectors, alignment ignores them, and no selector choice is more "trusted" than another. A signature from s=news and one from s=transactional under the same d= are, to reputation systems, the same identity.

The practical asymmetry follows: choosing the signing domain is a strategic decision about whose reputation your mail builds, while choosing selectors is housekeeping. But housekeeping with teeth — every published selector is a live entry point into your domain's signing authority, which is why the failure modes below are mostly selector stories.

How a DKIM selector works

On the sending side, the platform holds a private key and stamps its chosen selector into each signature. On the receiving side, the verifier reads d= and s=, constructs the DNS name, and fetches the TXT record:

s1._domainkey.yourbrand.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

If the record exists and the key verifies the signature, DKIM passes. If the selector resolves to nothing (deleted record, typo, wrong zone), the signature fails as surely as a broken key would.

Finding your selectors takes one of two routes. Per message: open a delivered email and read the s= tag in its DKIM-Signature: header, or run it through the email header analyzer. Per platform: every provider's setup page lists the selectors it uses for your account, since those are the records it asked you to publish. There is no way to enumerate a domain's selectors from outside by DNS query alone, because a verifier must know the name to ask for — which is exactly why an internal inventory matters: DNS will not volunteer the list for you.

Publishing happens in one of two shapes. Direct TXT: you paste the key material into your zone, and rotations require you to update it. CNAME delegation, the pattern most ESPs prefer: you publish s1._domainkey.yourbrand.com as a CNAME to a record the provider hosts, and they rotate the underlying key without touching your DNS again.

Rotation is the selector's day job. Publish a new key under a new selector, switch signing to it, let mail signed under the old one age out, then remove the old record. No coordination with receivers is ever required, because each message announces which key verifies it. RFC 6376 was designed for exactly this choreography. Verify any selector's published key from the outside with the DKIM checker, or see the whole authentication picture in one pass with the email authentication checker.

DKIM selectors and your deliverability

Selectors never appear in a filtering decision directly, but they sit under three things that do.

First, verification itself. The Gmail and Yahoo bulk-sender requirements both demand DKIM signing, and a signature whose selector record is missing or mangled is a failed signature. The selector record is a single DNS entry standing between "signed" and "unsigned" in the eyes of every receiver.

Second, key hygiene. Rotation exists because a leaked private key lets its holder sign as your domain until the record comes down; selectors are what make rotation cheap enough to do on a schedule. RFC 8301 sets the key-strength floor (1024-bit minimum, 2048-bit recommended), and the selector mechanism is how you migrate to stronger keys without a flag day.

Third, vendor surface area. Every selector you have ever published for a platform is a grant of signing authority. The active ones are your infrastructure; the forgotten ones are someone else's opportunity. An inventory of _domainkey records, reviewed when vendors leave, is a security control that costs a spreadsheet.

Limitations and failure modes

Forgotten selectors. The classic: a vendor dropped in 2022 whose selector still resolves. The record keeps working for whoever controls that key, and nothing alerts you, because verification succeeding looks identical whether you meant it or not. Selector removal belongs in vendor offboarding, next to revoking API keys.

The truncated 2048-bit record. Keys above 255 characters must be published as multiple quoted strings in one TXT record, and some DNS panels truncate instead of splitting. The result verifies never and looks fine at a glance. Check published keys from the outside after every change.

Copy-paste drift. Publishing the record at s1.domainkey instead of s1._domainkey, dropping the underscore, or pasting into the wrong zone. The signature then points at a name that does not exist, and every verification fails while the provider dashboard insists setup is complete. Resolution is one DNS lookup away.

Deleting a selector too early. Mail already sent carries its s= permanently. Remove the record while queued or slow-path messages are still in flight and they arrive unverifiable. Retire selectors after signing has moved and the tail of old-signed mail has cleared — days, not minutes.

Testing-selector leftovers. Keys published during an integration test, with weak lengths or default names, left live for years. RFC 6376 also defines t=y (testing mode) for the record's flags; receivers mostly ignore it, so a "test" key is a real key.

Selector reuse across providers. Pointing one selector at a new platform while the old platform still signs with the same name produces intermittent failures that depend on which system sent the message. Selectors are cheap; give each platform its own.

Related terms

DKIM, DKIM alignment, DMARC, SPF record, domain reputation, bounce domain, return-path, MX record.

Frequently asked questions

How do I find my DKIM selector? Read the s= tag in the DKIM-Signature: header of any message you sent — the header analyzer parses it out for you. Your sending platform's authentication settings list the same selectors, since it asked you to publish records for them.

Can I have multiple DKIM selectors on one domain? Yes, and you almost certainly should: one per sending platform, plus overlap during rotations. Each lives at its own {selector}._domainkey name, and they coexist without limit or conflict.

Does the selector name matter for deliverability? No. Receivers treat the selector purely as a key locator; reputation and alignment ride on the d= domain. Pick names that tell you which platform and which generation a key belongs to.

How often should I rotate DKIM selectors? Common guidance lands at every 6 to 12 months, and immediately on any suspicion of key exposure. CNAME-delegated selectors often rotate automatically on the provider's schedule, which is a point in that pattern's favor.

Why does my DKIM fail with "selector not found"? The verifier queried {s=}._domainkey.{d=} and got nothing. Usual suspects: the record was never published, the underscore or zone is wrong, propagation has not finished, or someone cleaned up a record still in use. The lookup that fails is public — run it yourself and the cause is usually obvious.

Should I publish my selector as TXT or CNAME? Whichever your platform offers, prefer CNAME: the provider then rotates keys without you touching DNS. Direct TXT puts rotation on your calendar, where it tends to stop happening.

Five minutes settles your current state: pull one delivered message per sending platform, note each s= and d=, and check every selector resolves with the DKIM checker. Any selector in DNS that did not appear on that list is your first cleanup candidate.

Sources