How to find the DKIM selector your provider uses

Your DKIM selector is the value after s= in the DKIM-Signature header of any message your domain sends. Nothing in DNS lists it, your provider’s setup page may never have shown it, and the one reliable way to read it is off a real message that has left your outbound server. Send one to a mailbox you do not host, open the raw source, and the selector is in the first screen of headers.

If you cannot send from the system in question, there is a second route further down this page: the names each provider hands out, which you can query one by one.

Why DNS will not tell you

A DKIM public key is a TXT record at a name built from the selector: <selector>._domainkey.<yourdomain>. The key for selector s1 on example.com lives at s1._domainkey.example.com. DNS answers questions about exact names. It has no query for “everything under _domainkey”, and a zone transfer, the one request that would list the names, is refused by any nameserver configured this decade.

Ask for the parent label and you get an empty answer:

$ dig +short TXT _domainkey.example.com
$

That silence says nothing about whether keys exist one label deeper. The selector is the missing piece, and a message your domain has sent is the only thing that carries it.

The census runs into the same wall, which is why its DKIM figures read the way they do. When the scan cannot tell which provider handles a domain’s mail, it asks for a fixed list of common names: selector1, selector2, google, default, k1, s1, dkim and mail.

In the September 2026 edition the DKIM check ran on 75,823,110 domains, and a key answered at one of the names it tried on 37,999,462 (50.1%) of them. That count is a floor. A domain signing under a name outside the list looks the same as one that never set DKIM up, and the same blindness applies to anyone guessing at your zone from outside.

Step 1: send a message from the system that matters

The signature is added by the outbound server at the moment a message leaves, so the copy in your Sent folder may not carry it. You need a message that has completed the trip. Send one to a mailbox you can open raw headers in, on a different provider from the one doing the sending. Mail that stays inside one provider is sometimes delivered without ever passing through the signing or verifying steps, and you would be reading a message that tells you nothing.

Send from the thing you are trying to check. Your mail suite, your CRM, your invoicing tool and your website’s contact form each have their own sending path, and each path signs with its own selector. A domain with a hosted mailbox and two SaaS tools sending on its behalf can have three or four different selectors live at once, each of them valid. Checking the mail suite’s selector tells you nothing about the invoice run.

Step 2: read s= out of the raw headers

Open the message and find the option that shows the full source. Gmail calls it “Show original”, Outlook on the web calls it “View message source”, Apple Mail has “Raw Source” under the View menu, and Thunderbird has “View Source” under More. Scroll to the header block and look for DKIM-Signature:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1;
    h=From:Date:Subject:Message-ID:To:MIME-Version:Content-Type;
    bh=2jmj7l5rSw0yVb/vlWAYkK/YBwk=;
    b=dGhpcyBpcyBub3QgYSByZWFsIHNpZ25hdHVyZQ==

d= is the signing domain and s= is the selector. In this message the selector is selector1, and the verifier will have fetched the key from selector1._domainkey.example.com. What the other tags mean, and how each of them fails, is covered on the DKIM page.

A message can carry more than one DKIM-Signature header. A hosted sending service often signs once with your domain and once with its own, and a mailing list may add a third on the way through. Find the one where d= is your domain, and read s= from that header only. If no signature carries your domain in d=, your mail is signed on a borrowed identity, and for Google Workspace tenants the gappssmtp signing page explains what that identity is and how to replace it.

The receiver repeats the selector in its own verdict line, which is a useful cross-check when a message has several signatures:

Authentication-Results: mx.example.net;
    dkim=pass [email protected] header.s=selector1 header.b=dGhpcyBp

header.s= is the selector the receiver used and header.b= is the start of the signature it matched, so you can pair the verdict with the right DKIM-Signature header above it. Gmail’s “Show original” also prints a summary at the top of the page, DKIM: 'PASS' with domain example.com, which confirms the signing domain and leaves the selector to the header block below.

Step 3: query the name and read what comes back

Put the selector in front of ._domainkey. and your domain, then look it up:

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

On Windows without dig, nslookup -type=TXT selector1._domainkey.example.com gives the same answer, as does Resolve-DnsName -Name selector1._domainkey.example.com -Type TXT in PowerShell.

A CNAME in the answer is normal. Many providers have you publish a CNAME at the selector name pointing at a host they control, so they can rotate the key without asking you to touch DNS again. dig +short follows the chain and prints both the target and the record found there:

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

Two quoted strings in one answer are also normal. A 2048-bit key produces a value longer than the 255-character limit on a single TXT string, so whoever publishes the record splits it into two strings that the verifier joins:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxq3zrq5v" "9kLm2pQe4Rt6YuIoPaSdFgHjKlZxCvBnM1234567890abcdefIDAQAB"

A record that reads "v=DKIM1; p=" with nothing after the p= is a revoked key. The DKIM specification defines an empty p= as “this key has been withdrawn”, and every verifier treats a signature under it as unverifiable. That record usually means someone rotated away from the selector and left the tombstone behind, and it is your cue to find the newer selector in a fresher message.

The trick when you cannot send a message

Perhaps you inherited the domain, or the tool that sends sits with another department and nobody can log in to it any more. You still have the inbound side. Every message that domain has already sent to a mailbox you control was signed on the way out, so search your own inbox for the most recent one from that sender and read its headers the same way. A support ticket, an invoice, a password reset, a shipping notice: each carries the selector its sending path uses.

If you receive the domain’s DMARC aggregate reports, they name the selector too. Each <record> in the XML has an <auth_results> block, and inside it the DKIM entry lists the signing domain, the selector and the result for that sending source:

<dkim>
  <domain>example.com</domain>
  <selector>selector1</selector>
  <result>pass</result>
</dkim>

One day of reports shows every selector in use across every source that sent as your domain, including the SaaS tools nobody documented. How to set the reporting address that makes those reports arrive is on the DMARC page.

With neither a message nor a report to hand, work from the provider. Every hosted service has a naming habit, and a query against each candidate name takes seconds.

The names providers hand out

Microsoft 365 publishes two selectors and signs with one at a time, switching between them when it rotates the key. Both CNAMEs must exist for rotation to work, and the admin centre shows which one is active. The CNAME target starts with selector1-, then your domain with its dots swapped for hyphens, then ._domainkey. and the hostname of your tenant, so selector1-example-com is what you should expect to see at the front of it.

Google Workspace uses google by default and publishes a TXT record rather than a CNAME. An admin can pick any other prefix when generating the key, and the record does nothing until the admin also presses “Start authentication” in the console. A tenant that generated a key years ago and never pressed that button has a valid record in DNS and a signature on a borrowed identity in every message, which is the case the gappssmtp page above describes.

Once you have the name, the scan reads the record your DNS publishes for it and shows it beside your SPF and DMARC state.

When the name returns nothing

You read s=selector2 from a header and the query for selector2._domainkey.example.com comes back empty. The message verified when it arrived, so the record existed then.

Microsoft 365, for one, alternates between its two selectors, and if only one CNAME was ever published the messages signed with the other have no key. Publish the missing CNAME and the next rotation passes.

Some DNS panels append the domain to whatever you type in the host field, so the record lands in the wrong place: entering google._domainkey.example.com produces google._domainkey.example.com.example.com. Query that doubled name; if it answers, delete it and re-enter the host as google._domainkey alone.

If the mail goes out from a subdomain, a signature with d=mail.example.com needs its key at selector1._domainkey.mail.example.com, and a key published at the apex does nothing for it.

It may also be that your resolver hasn’t caught up. Ask the authoritative nameserver directly with dig +short TXT selector1._domainkey.example.com @ns1.example.com, and if that answers while your resolver stays empty, wait out the TTL of the negative answer you cached earlier.

Whatever your query shows, the scan will show the same. When no key answers at the selector your provider is known to use, or at any of the names on its fixed list, it records that no key was observed there, which is a narrower statement than saying the domain does not sign. If you know your provider signs and the scan finds nothing, the selector in a real message and the record in your DNS disagree, and the four causes above cover almost every case of that.

Once the record answers, run the scan again. A key at your provider’s selector closes this step, and the SPF and DMARC lines on the same result tell you what is left before your domain is hard to forge.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.