How to find your DKIM selector

What a selector is, and why you need its name

A DKIM public key does not sit at your domain itself. It sits one level down, under a name that combines a selector with the fixed label _domainkey. RFC 6376 introduced selectors so that one domain can publish several keys at once: one per sending service, one per office, or an old and a new key during a rotation. A signature names its selector in the s= tag, which the standard makes required, and its domain in the d= tag. A receiver verifying the message joins the two and looks up a TXT record at <selector>._domainkey.<domain>; for s=s1 and d=example.com that is s1._domainkey.example.com.

The catch is that DNS has no way to list the names under _domainkey. You cannot ask for "all DKIM keys of example.com"; you can only ask for one specific name and get an answer or nothing. So whenever a tool asks for your selector, it is not being lazy. Without that one word it cannot find your key at all. The RFC adds that selectors may be chosen freely, from location names to dates, and that some domain owners deliberately use random values so outsiders cannot harvest information from them.

There are three dependable places to find the selector: a message the service has actually sent, the service's own DKIM settings, and your DMARC reports. The first is the most reliable because it shows what is really in use, not what was configured once.

Method 1: read it from a message

Send a message through the service to an address you can read, then open its full headers.

• Gmail in a browser: open the message, click the three-dot More menu next to Reply and choose Show original. Gmail Help describes the same steps.
• Classic Outlook for Windows: double-click the message to open it in its own window, then choose File and Properties; the headers are in the Internet headers box.
• New Outlook and Outlook on the web: select More actions at the top of the message, then View and View message details. Both Outlook paths come from Microsoft's own instructions.

Search the headers for DKIM-Signature. Header lines wrap, so the tags you need may sit a line or two below the field name:

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

Here d=example.com and s=s1, so the key lives at s1._domainkey.example.com. Many messages carry more than one signature. A sending platform often adds its own, signed with its own domain, next to yours. Pick the signature whose d= is your domain or one of your subdomains; that is the one DMARC can use. If every signature has the platform's domain in d=, the service is not signing with your domain yet, and you have found a different problem: DKIM passes, but it does not align, which is a common reason DMARC fails even when SPF and DKIM pass.

The Authentication-Results header nearby tells you whether the receiver could verify the signature. A dkim=pass next to your domain means the key at that selector is published and matches. A failure with a note about a missing key usually means the DNS record is not published yet, or was published under a slightly different name.

Method 2: look in the provider's DKIM settings

Every service that signs with your domain shows the DNS record it wants you to publish, and the selector is the first part of that record's name. Three widely used services document theirs:

• Google Workspace. The key is generated in the Admin console under Apps, Google Workspace, Gmail, Authenticate email. Google's setup guide states that the default prefix selector is google, which gives a TXT record at google._domainkey. An administrator can choose a different prefix, and Google advises doing so if the domain already has a key under google, so check the console rather than assuming the default.
• Microsoft 365. For a custom domain Microsoft generates two key pairs and asks for two CNAME records, selector1._domainkey and selector2._domainkey. According to Microsoft's DKIM guide these host names are the same for every Microsoft 365 organization, while the targets they point to differ. Only one selector is active at a time; the other takes over after a key rotation, which is why you publish both. The values are shown on the DKIM tab of the Email authentication settings page in the Microsoft Defender portal.
• Twilio SendGrid. SendGrid's documentation says it uses the selectors s1 and s2 by default, interchangeably, and rotates them when necessary. The records are CNAMEs such as s1._domainkey.example.com that point into SendGrid's own domain.

Other services follow one of two patterns. Some use a fixed selector that is the same for every customer, much like the examples above. Others generate a unique token per domain, a long string of letters and digits that you would never guess. In both cases the record name in the service's domain settings is the answer. Our email service setup guides cover the DNS side for common services, and when a service documents a fixed selector, the guide's Check it box sends it straight to the DKIM checker for you.

A CNAME record counts. When the provider asks for a CNAME at s1._domainkey, the key itself lives at the target, and receivers follow the CNAME automatically. The selector is still s1.

Method 3: let your DMARC reports tell you

If your DMARC record has an rua address, mailbox providers send you aggregate reports, and these show selectors for every service sending as you, including ones you forgot about. Under RFC 9990, the current report format, each DKIM result inside auth_results lists the signing domain, the selector and the result, and the selector is now required. Reports written to the older RFC 7489 schema treated it as optional, so some receivers leave it out. Read the selector from rows where the domain is yours and the result is pass; a selector that only ever appears with fail may belong to a key that was removed.

Patchkit uses this automatically for domains you monitor. Every selector it sees in your reports is stored with the sender, and when Patchkit measures your domain's health it adds the most recently seen of them to its own list of selectors to try. A service with a random per-domain selector is therefore found once its first report has arrived, without you typing anything. If you have never looked at a report, how to read DMARC aggregate reports explains the structure.

Test the selector you found

Enter your domain and the selector in the DKIM record checker, or open it with both in the address, for example /tools/dkim-checker?domain=example.com&selector=s1. The checker looks up your selector first, then a list of selectors common providers use, and shows each key it finds with its full name, such as s1._domainkey.example.com. For every key it reports the type and length, and it flags keys shorter than 2048 bits, keys published in test mode and revoked keys, which RFC 6376 marks with an empty p= value. The list of selectors it tried is printed under the result, so you can see whether yours was among them.

Why guessing common selectors can miss yours

Every DKIM tool that works without your selector, ours included, is guessing. It tries a list of names that big providers are known to use and reports what answers. That catches Google Workspace on its default prefix or Microsoft 365, and it misses everything else: an administrator who changed the prefix, a platform with a random token, or a self-hosted server whose selector is a date. A result of "no key found" from a guess therefore means only that no key sits under the names tried. That is why the domain health check marks DKIM as a warning, not a failure, when it finds nothing.

A guess can also mislead in the opposite direction. Finding a key at selector1 proves that the record exists, not that your mail is signed with it; it may be left over from a service you stopped using years ago. Only a real message's DKIM-Signature, or a report row with pass, shows the selector that is actually signing today. Use the guess to get started, and confirm with one of the three methods above. What is DKIM? covers signing and key length in more depth.