A DKIM selector is the label in the s= tag of a DKIM-Signature header that tells a receiving mail server which DNS TXT record holds the public key needed to verify that signature. Combined with the signing domain from the d= tag, it forms the DNS query name: selector._domainkey.domain.com. RFC 6376 subdivides the key namespace this way specifically so one domain can publish more than one public key at a time, one per sending source.
You’ll run into a selector in two situations: reading the raw headers of a DKIM-signed message, or setting up DKIM with a new provider and needing to know what to publish in DNS. Both come down to the same short string.
Where the Selector Sits in a DKIM-Signature Header
Every DKIM-signed message carries a DKIM-Signature header made of tag=value pairs. The selector is one of them:
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; ...RFC 6376, Section 3.5 defines the tag directly: “The selector subdividing the namespace for the d= (domain) tag (plain-text; REQUIRED).” The tag is mandatory, not optional. A signature without one is not valid DKIM.
The two tags work as a pair. d= names the signing domain; s= names the specific key within that domain’s keyspace. Neither is enough on its own to locate the public key, a verifier needs both. What Is DKIM? covers the rest of the DKIM-Signature tags (a=, bh=, h=, b=) in detail.
How to Find Your Selector in an Email You Received
If you need the selector for one specific message rather than a whole domain, it’s sitting in that message’s headers.
- Open the message and view its full headers: Show original in Gmail, View source in most desktop mail clients, or View > Message Source in Thunderbird.
- Search the raw text for
DKIM-Signature:. - Read the
s=value. Ins=brisbane; d=example.com, the selector isbrisbane.
This works for any message you can open, regardless of who sent it, because the selector always travels with the signature. It won’t help for a domain you don’t have a sample email from; for that, use the DNS lookup in the next section.
If you send through Coldletter, you can skip this step entirely: the selector is generated for you and shown directly in the DNS instructions when you verify a sending domain.
Worked Example: From Selector to DNS Record
RFC 6376’s own appendix walks through this end to end. In its example, example.com‘s outbound server signs a message with the selector brisbane:
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
h=Received:From:To:Subject:Date:Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB...The receiving server extracts d=example.com and s=brisbane and, per RFC 6376, forms “the DNS DKIM query for: brisbane._domainkey.example.com.” You can run the same lookup yourself with dig:
$ dig TXT brisbane._domainkey.example.com +short
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."The returned TXT record holds the public key (p=) the verifier checks the signature against. What Is DKIM? breaks down what each field in that record means and why long keys get split across quoted strings.
Why a Single Domain Ends Up With Multiple Selectors
RFC 6376 subdivides the key namespace by selector specifically so a domain can run more than one public key at a time. In practice, that happens for two reasons.
Multiple sending sources. If you send transactional mail through Coldletter, marketing mail through a second ESP, and internal mail through Google Workspace, each source needs its own key pair and its own selector, because each is a different signer with a different private key. dmarcian’s guide to selectors puts the reasoning plainly: a selector “is particularly useful for organizations that send emails from multiple servers or services, allowing each to have its own unique DKIM signature,” as explained in dmarcian’s DKIM selector guide.
Key rotation. A domain publishes a new selector alongside the old one, switches signing over to the new key, and only removes the old selector’s record once the transition window has passed. The next section covers this in order.
It’s the same problem an SPF record solves for multiple senders, just solved differently. SPF authorizes several senders inside one record using include: mechanisms (see SPF Record Syntax Explained), while DKIM gives each sender its own selector and its own key pair entirely.
Default Selectors by Provider
You rarely choose a selector name yourself unless you run your own mail server. Most ESPs assign one, or a pair, automatically:
| Provider | Selector(s) | DNS record type |
|---|---|---|
| Google Workspace | google (default; renameable) | TXT |
| SendGrid | s1, s2 (default; customizable to 1-3 characters) | CNAME |
| Mailchimp Transactional (Mandrill) | mte1, mte2 | CNAME |
Google Workspace’s DKIM setup guide states plainly that “the default prefix selector is google.” SendGrid’s documentation confirms its defaults are “S1 and S2,” producing records at s1._domainkey.YourDomain.com and s2._domainkey.YourDomain.com. Mailchimp’s transactional email docs list mte1._domainkey.example.com and mte2._domainkey.example.com as the CNAME names, pointing to Mandrill’s signing infrastructure.
These are documented defaults, not universal constants. Your own provider dashboard is the source of truth for what to publish.
Rotating a Selector Without Breaking Signatures
RFC 6376 frames rotation as an overlap, not a swap. Moving from a selector like january2005 to february2005 means, in the RFC’s own words, making sure “that both public keys are advertised in the public-key repository concurrently for the transition period during which email may be in transit prior to verification.” Only after that window closes does the old key get removed.
In practice:
- Generate a new key pair and publish it under a new selector, leaving the old selector’s record live.
- Point outbound signing at the new selector.
- Wait out a transition period long enough for anything signed with the old key to be delivered and verified.
- Remove, or revoke by emptying
p=, the old selector’s record.
RFC 6376 also warns against reusing a selector name for a new key, noting that doing so “makes it impossible to tell the difference between a message that didn’t verify because the key is no longer valid and a message that is actually forged.” Always rotate to a new selector name; never recycle an old one.
If you’re also running DMARC, aggregate reports will show which selector is passing for which sending source, useful for confirming a new key verifies correctly before you retire the old one. For how selectors fit into the full picture, see What Is Email Authentication?
Frequently Asked Questions
How do I find my DKIM selector without opening an email?
Query DNS directly if you already suspect the selector, since many ESPs use predictable defaults like Google Workspace’s google or SendGrid’s s1/s2. If you don’t know it, check your provider’s DKIM setup documentation or domain verification page. There’s no wildcard lookup for _domainkey records, so you can’t discover an unknown selector by scanning DNS blindly.
What happens if two providers accidentally use the same selector?
Whichever key gets published last in that selector’s DNS record wins. The other provider’s signatures start failing verification because the wrong public key is now being checked against them. This is exactly why each sending source needs its own selector: reusing one across providers isn’t a formatting slip, it silently breaks DKIM for whichever provider loses the DNS record.
Is it safe to delete an old selector’s DNS record right after rotating?
No. RFC 6376’s rotation guidance keeps the old selector’s record live through a transition period, because messages signed before the switch may still be in transit when they reach the recipient’s server. Deleting the record immediately breaks verification for any message signed with the old key that hasn’t been delivered yet.
Do DKIM selector names need to follow a specific format?
RFC 6376 defines a selector as plain text and allows periods as component separators, similar to a DNS label, but it doesn’t require the name to be descriptive or human-readable. That’s why some providers use short, opaque values like s1 or mte1 instead of a name that describes what the key is for.
Can a domain have more than one active DKIM selector at the same time?
Yes, and most domains sending through more than one provider already do. RFC 6376 subdivides the key namespace by selector for exactly this reason: it lets a domain publish and use several public keys concurrently, one per sending source or one per rotation cycle, without any of them interfering with each other.
What happens if the selector in a signature doesn’t match any DNS record?
Verification fails outright. If the receiving server queries selector._domainkey.domain.com and gets no TXT record, or an NXDOMAIN, it has no public key to check the signature against, so the signature is treated as invalid. This typically happens when a selector’s record was removed too early during rotation, or when a sending system was misconfigured to sign with a selector nothing was ever published for.
I’ve spent my career building software at scale with a soft spot for email: deliverability, lifecycle campaigns, and getting messages to actually land. I started Coldletter to fix what bugged me about transactional and marketing email tools. I’m based in Vancouver.