What Is a DKIM Selector and How Do You Find Yours?

This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.

You paste a DKIM key into your DNS, run a checker, and it replies that no DKIM record was found. The key is fine and the record is live. The checker is simply looking under a name you never created, because it guessed your selector and guessed wrong.

This guide explains what a selector is, shows how to read yours from an email you already have, and lists real selectors I looked up in DNS on 5 October 2026. They come from mail that reached my own inboxes, including the mail for veravix.com and repairpicks.com. If you set up SPF first, SPF Records and Subdomains: How to Stay Under the 10-Lookup Limit covers that half, and DKIM is the other one.

A selector is the first part of the DNS name that holds your key

Whoever sends the mail picks a short label and calls it the selector. When a message is signed, the signature records two things: the signing domain in the d= tag and the selector in the s= tag. The receiving server then asks DNS for a TXT record at selector._domainkey.domain and uses the public key it finds there to check the signature.

RFC 6376, section 3.6.2.1, gives the rule with an example: a signature with d=example.com and s=foo.bar leads to a query for foo.bar._domainkey.example.com. So if your Google Workspace domain uses Google’s default selector, which is google, your key sits at google._domainkey.yourdomain.com. The selector is not a password, and it appears in every message the system signs. It is just the first label of the name.

Why a domain can have more than one

Selectors exist so one domain can publish several keys at the same time. Section 3.1 of the same RFC lists the uses: handing signing rights to a partner for a while, or changing keys without breaking mail that is still in transit. It suggests labels like office locations or dates, and its own rotation example moves from a selector named january2005 to february2005 with both keys published during the changeover. The RFC also says many domain owners will be satisfied with just one selector, which is the usual case for a small site.

Microsoft 365 builds this idea in from the start. When you turn on DKIM for a custom domain, it generates two key pairs, publishes them as selector1 and selector2, signs with one, and keeps the other idle until the next key rotation.

Read your selector from an email you already have

You do not have to guess. Every signed message carries its own selector, so the quickest route is to read it from a message that was sent by the system you are checking.

1. Send a message from that system to a Gmail address you control. A newsletter tool, your shop’s order email and your mailbox each count as a separate system.
2. Open the message in Gmail, use the three-dot menu and choose Show original.
3. Find the line that starts with DKIM-Signature and read the d= and s= values. Gmail also repeats them in the Authentication-Results line as header.i=@domain and header.s=selector.
4. Join them as s._domainkey.d and look the name up. On Windows or Linux, nslookup -type=TXT selector._domainkey.yourdomain.com works, and so does dig +short TXT selector._domainkey.yourdomain.com.

If the provider set you up with a CNAME, the answer you see is the TXT record at the end of that CNAME, which is what a receiving server sees too. A message can also carry more than one signature. A marketing email from Pinterest that I received carried two: selector 200608 on marketing.pinterest.com, and a second one, fbldkim11, on the domain of the email platform that sent it. A Gmail message carried two as well, one for gmail.com and one for Google’s own 1e100.net. Read every DKIM-Signature line, because the one you care about may be the second.

Selectors I looked up on 5 October 2026

I took the d= and s= values from real messages and queried each name at Google’s public resolver. I judged key size from the length of the p= value: about 216 characters is a 1024-bit key and about 392 is a 2048-bit key.

Sender and signing domain	Selector	What DNS returned	Key size
Gmail, gmail.com	20251104	TXT record	2048-bit
Yahoo, yahoo.com	s2048	TXT record	2048-bit
A Mailchimp newsletter, sourceofsources.com	k3	CNAME to dkim3.mcsv.net	2048-bit
Pinterest marketing mail, marketing.pinterest.com	200608	TXT record	1024-bit
Pinterest notifications, notifications.pinterest.com	scph1017	TXT record	1024-bit
A Dutch insurer on Microsoft 365	selector1	CNAME to an onmicrosoft.com name	2048-bit
The same insurer’s secure-mail vendor	zivver	TXT record on the insurer’s own domain	1024-bit
Hostinger email, veravix.com and repairpicks.com	hostingermail-a and hostingermail-b	CNAMEs to dkim.mail.hostinger.com	2048-bit

Three things stand out. No two senders name their selectors alike: dates, short codes, vendor labels and numbers all appear. Pinterest and the insurer’s secure-mail vendor still publish 1024-bit keys. That is allowed, since RFC 8301 says signers must use at least 1024 bits, but the same document says they should use at least 2048. And the zivver row is a good picture of what a selector is for: the insurer lets an outside vendor sign mail for its domain under a separate key, and removing that key later does not touch the rest.

Why guessing your selector fails

I tested thirteen common guesses against both of my own domains: default, google, selector1, selector2, k1, k2, k3, s1, s2, mail, dkim, smtp and mandrill. Not one resolved on veravix.com or repairpicks.com. The real selectors are hostingermail-a and hostingermail-b, set up by Hostinger, whose email runs the mailboxes for both sites. A checker that tries a fixed list of popular names would report “no record” for a domain that signs perfectly well. One tool I looked at advertises a list of 128 selectors, and it still cannot find a name nobody put on the list.

The reason is how DNS works. An ordinary query asks for one exact name and cannot ask for everything under _domainkey, so an outside checker can only test names it already knows. Only you, or your provider’s setup page, can tell it the right one.

Where each provider tells you the selector

• Google Workspace. In the Admin console, go to Apps, then Google Workspace, then Gmail, then Authenticate email, and pick your domain. The page shows a DNS host name field and a default selector prefix of google. Google offers a 2048-bit or a 1024-bit key and says to pick 2048 if your domain provider supports it.
• Microsoft 365. You create two CNAME records, selector1._domainkey and selector2._domainkey, each pointing at a name Microsoft shows you in the Defender portal or in PowerShell. Microsoft’s current documentation shows a newer target format ending in dkim.mail.microsoft, while the insurer above still points at an older onmicrosoft.com name, so copy your own values and do not reuse an example.
• Your host’s email. Hosting providers usually publish the records for you or hand you the exact names. On my own domains the pair is hostingermail-a and hostingermail-b.
• Newsletter and shop tools. Each shows its records on its own domain-authentication page. The Mailchimp example above used k3, and other senders use their own pattern.

When the record exists but the check still fails

• Record type mismatch. If the provider asks for a CNAME, create a CNAME. A name that has a CNAME cannot hold a TXT record next to it, so a leftover TXT at the same name has to go first.
• A long key that was not split. A 2048-bit key does not fit in a single DNS text string, which is limited to 255 characters. Gmail’s and Mailchimp’s keys above are stored as two strings, and Yahoo’s as four. Most DNS panels split a long value for you, but if yours does not, break it into several quoted strings and leave no spaces between them.
• The wrong name. Create the host name your provider shows, exactly. Compare it with the s= and d= of a message you received, since a typo in the selector gives the same “not found” result as a missing record.
• The wrong half of the key. Only the public key goes in DNS, in the p= tag. A private key never leaves your provider.
• Testing too early. After you add a record, resolvers can hold on to an earlier “not found” answer for a while. Wait, then query again, and send a fresh test message rather than re-reading an old one.

Changing keys without breaking mail

RFC 6376 advises against reusing a selector for a new key, because a receiver then cannot tell a stale key from a forged message. The safe order is to publish the new key under a new selector, switch your sender to sign with it, leave the old record in place while mail already in transit gets delivered, and remove the old one afterwards. That is why the dated selectors in the table, such as Gmail’s 20251104, look the way they do.

A five-minute check for this week

Send one message from each system that sends mail for your domain to a Gmail address, open Show original, and write down the d= and s= from every signature. Look each name up, and confirm that a TXT record comes back and its p= value is not empty. Where the key is 1024-bit, ask the provider whether a 2048-bit option exists. If a system sends mail but never shows a DKIM signature at all, that is the one to fix first. Once DKIM and SPF both pass for every sender, the next step is a DMARC record, which tells receivers what to do when either one fails.