How to find my DKIM selector?

Your DKIM selector is the value of the s= tag in the DKIM-Signature header of a message sent from your domain. Together with the d= tag it gives the DNS name of the public key: s=google and d=example.com mean the key is published at google._domainkey.example.com. If you have no message at hand, the selector is shown in your mail provider's DKIM settings, and the large providers use fixed defaults (Google Workspace: google; Microsoft 365: selector1 and selector2). Probing DNS for likely names is the last resort, because DNS offers no way to list selectors.

Work through the methods in this order. The first one that gives an answer is authoritative.

Method 1: read the s= tag from a sent message

Send a message from the address or platform you want to check to a mailbox you can read, then open its raw source:

• Gmail: open the message, ⋮ menu → Show original.
• Outlook (classic desktop): File → Properties → Internet headers. Outlook on the web: ⋯ → View → View message source.
• Apple Mail: View → Message → All Headers (or Raw Source).
• Thunderbird: View → Message Source.

Find the DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=google; t=1761818400;
        h=from:to:subject:date:message-id;
        bh=...; b=...

Here the selector is google and the signing domain is example.com. Two details decide whether you are looking at the right one:

• A message can carry several DKIM signatures. A newsletter platform often signs once with its own domain (d=sendgrid.net, for example) and once with yours. The selector you need belongs to the signature whose d= is your domain. If no signature has your domain, the platform is not signing for you at all, and DMARC cannot pass on DKIM for that mail.
• The receiver's verdict names the selector too. Gmail's Authentication-Results header records it as header.s=:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=google header.b=Ab12Cd34;
       spf=pass (google.com: domain of jane@​example.com designates 192.0.2.25 as permitted sender) smtp.mailfrom=jane@​example.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Method 2: look it up in your provider's DKIM settings

Every platform that signs with your domain shows the selector, usually as the DNS name it asked you to publish. Defaults for common platforms:

• Google Workspace: google, a TXT record. Admin console → Apps → Google Workspace → Gmail → Authenticate email. A different prefix can be chosen when generating the key.
• Microsoft 365: selector1 and selector2, both CNAME records that point to keys Microsoft hosts and rotates. Copy the exact CNAME targets from the DKIM page in the Microsoft Defender portal.
• Amazon SES (Easy DKIM): three CNAMEs with random-looking selectors, <token>._domainkey, each pointing to <token>.dkim.amazonses.com.
• SendGrid: s1 and s2 CNAMEs (Settings → Sender Authentication → Domain Authentication); a custom selector can be set there.
• Proton Mail: protonmail, protonmail2 and protonmail3 CNAMEs.
• Fastmail: fm1, fm2 and fm3 CNAMEs.
• Self-hosted (OpenDKIM, Rspamd, Postfix and similar): whatever was configured. default, mail and dkim are common, as are date-based names such as 2026a.

For any other platform, look for "domain authentication" or "custom DKIM" in its settings. If the platform has no such option, it signs with its own domain.

Method 3: probe likely selectors in DNS

When neither of the above is available, query candidate names. Any answer means that selector exists:

$ dig +short TXT google._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

$ dig +short TXT selector1._domainkey.example.com
selector1-example-com._domainkey.example.onmicrosoft.com.
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

In the second answer the first line is the CNAME target and the second is the key it leads to, the normal pattern for providers that host your key. On Windows, run nslookup -type=TXT google._domainkey.example.com or Resolve-DnsName -Type TXT google._domainkey.example.com.

To try several names in one go:

for sel in google selector1 selector2 s1 s2 k1 default dkim mail; do
  ans=$(dig +short TXT "${sel}._domainkey.example.com")
  [ -n "$ans" ] && echo "$sel: found"
done

How to read the result:

• A TXT answer starting with v=DKIM1 and a long p= value: the selector is published and holds a key.
• p= with nothing after it: the key has been revoked. Mail still signed with this selector fails DKIM.
• No output: that name has no TXT record. Repeat the query without +short: status: NXDOMAIN means the name does not exist, while NOERROR with an empty answer section means the name exists but holds no TXT record.

A probe only finds names on your list. "Nothing found" does not prove that the domain has no DKIM; the s= tag of a real message is the definitive answer.

Why there is no list of selectors

DKIM has no index record. The bare _domainkey.example.com TXT record that some domains still carry is a leftover from DomainKeys, DKIM's predecessor, and says nothing about which selectors exist. Zone transfers are almost always refused, so apart from reading signed mail you can only discover selectors you guess. Why selectors exist at all, and how they make key rotation possible, is explained in What is a DKIM selector?.

Once you have the selector

1. Check the key. The DKIM checker looks up the exact selector you enter, shows the key type, and flags a missing or invalid public key, an RSA key that looks shorter than 1024 bits, and test mode (t=y). Without a selector it probes a list of about 50 common ones.
2. Check the key length. 2048-bit RSA is the norm; replace 1024-bit keys.
3. Check alignment. The d= of that signature must be your From domain, or its parent domain, for DMARC to pass on DKIM.
4. Rotate with a new selector. Publish the new key under a new selector next to the old one, switch signing, and remove the old key later. The DKIM guide and the DKIM generator cover generating and publishing a key.

Mistakes when looking up or publishing a selector

• Querying _domainkey.example.com without a selector. Keys never live at that name.
• The domain added twice. Many DNS panels append the domain automatically, so entering google._domainkey.example.com as the host name creates google._domainkey.example.com.example.com. Query the record with dig after saving.
• Two TXT records at one selector name. Resolvers return both, and which one a verifier uses is unpredictable. Keep exactly one.
• A CNAME and a TXT record at the same name. DNS does not allow a CNAME next to other records; publish one or the other.
• A mangled long key. A 2048-bit key is longer than the 255-character limit of a single TXT string, so it is stored as two strings. dig shows them as "first part" "second part" and verifiers join them, but a DNS panel that inserted spaces or extra quotes inside the key breaks it.