How to Find Your DKIM Selector (and Check That It Works)

Every email you send carries a hidden signature that proves it came from your domain, and your DKIM selector is the short name that tells receiving mail servers where to find the key that checks this signature. The selector travels with every message, so you can find it in four places: the headers of a message from your domain that arrived in an inbox, your sending platform’s settings, your DNS records, or your DMARC reports.

This guide walks through all four ways, from the fastest check to the one that shows every selector your domain uses. It ends with the two checks that tell you whether the selector you found works.

What’s in This Guide

• What Is a DKIM Selector?
• How Do You Find Your DKIM Selector in an Email Header?
• Where Do Sending Platforms Show Their DKIM Selector?
• How Do You Look Up a DKIM Selector in DNS?
• How Do You See Every Selector Signing for Your Domain?
• Why Is DKIM Failing When the Selector Exists?
• How to Verify That Your DKIM Selector Works
• FAQ
• The Takeaway

What Is a DKIM Selector?

DKIM (DomainKeys Identified Mail) is the standard behind hidden email signatures. A service that sends email as your domain signs each message with a private key, and receiving servers check the signature against a public key published in your DNS. The DKIM selector is the label that names which key to check, because one domain can publish several keys.

The selector sits in the s= tag of the DKIM-Signature header. Here is a shortened example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2025; ...

In this example, the selector is mail2025. The receiving server combines it with the domain and looks up the DNS record at mail2025._domainkey.example.com to get the public key.

Selector names are plain labels of letters and digits, chosen by whoever set up the signing. Real selectors look like mail, k1, s1, selector1, google, or a dated label like mail2025. The name appears in two places that must match exactly: the s= tag of the signature and the name of the DNS record.

How Do You Find Your DKIM Selector in an Email Header?

The fastest way to find your selector is to read it out of a message from your domain that has already been delivered. Open it from the inbox that received it, not from your Sent folder: the copy in Sent is usually saved before your outgoing mail server adds the DKIM signature, so it has no DKIM-Signature header to read. If you have no received copy at hand, send a message from your domain to a mailbox on another service (a personal Gmail account works) and open it there. Then view the raw message:

1. In Gmail, open the message, select the three-dot menu, and choose Show original.
2. In Outlook, open the message and choose View > Message source (or View message details, depending on the version).
3. In Apple Mail, choose View > Message > All Headers.
4. Search the text for DKIM-Signature and read the value after s=.

A message often carries more than one DKIM-Signature header, because the sending platform signs with its own domain next to yours. Read the one whose d= tag names your domain; its s= is the selector your DMARC alignment depends on.

Where Do Sending Platforms Show Their DKIM Selector?

The platform that sends your email also shows the selector in its authentication settings:

• Google Workspace generates its DKIM key under Apps > Google Workspace > Gmail > Authenticate email in the Admin console, with google as the default selector.
• Microsoft 365 has you publish two CNAME records named selector1 and selector2, and alternates between them when it rotates keys.
• Marketing and e-commerce platforms (Mailchimp, Klaviyo, Shopify, and the rest) each have a domain-authentication page that lists the exact DNS records to publish. The selector is the label before ._domainkey in the host name of each record.

An online store commonly runs two or three selectors at once (e.g., the ecommerce platform signs order confirmations and the newsletter sending platform signs campaigns, each under its own selector).

How Do You Look Up a DKIM Selector in DNS?

DMARCeye’s free DKIM checker runs the lookup for you: enter your domain and it scans the selectors that major platforms commonly use.

How Do You See Every Selector Signing for Your Domain?

The three checks above share a blind spot: each shows one message or one platform. The place where every selector shows up together is your DMARC aggregate reports, the daily summaries that receiving mail servers send about mail claiming to come from your domain. Each report lists the sending services it saw and how their authentication checks went, selector included.

DMARCeye reads these reports for you and shows which keys are active, which services use them, and where alignment issues occur. A selector you don’t recognize in your reports is worth investigating, as it's either a service someone connected without telling you or a sender pretending to be you.

DMARCeye’s free plan covers DMARC aggregate report monitoring for one domain.

Why Is DKIM Failing When the Selector Exists?

DKIM failures have four causes:

• The names don’t match. The service signs with one selector and the key sits in DNS under another, often after a platform migration.
• The record is gone or mistyped. A DNS cleanup removed it, or the name was entered with the domain duplicated.
• The key value is truncated. Long keys get split or cut when pasted into some DNS control panels, and a partial key verifies nothing.
• The signing domain is not yours. The platform signs with its own d= domain, so the signature passes but doesn’t align with your domain for DMARC.

Configuration problems like these are common with even the biggest providers. In DMARCeye’s Q1 2026 dataset, DKIM fail rates among the top 10 ESPs include Google LLC at 11.1%, Microsoft Corporation at 19.6%, Mailgun at 22.9%, and Proofpoint at 26.3%, the highest among the top 10 ESPs we measured.

As the Q1 report itself notes, low compliance on a major ESP is almost always a configuration problem on the sender side, not a flaw with the provider itself. Customers haven’t added the right DKIM keys to their DNS, a forgotten tool is signing with the wrong selector, or a key was rotated on one side only.

Compliance numbers also reflect the customer mix DMARCeye monitors and may differ from each platform’s overall customer base.

How to Verify That Your DKIM Selector Works

After you find the selector and confirm the DNS record answers, verify the whole chain with one test:

1. Send a fresh email from your domain to a mailbox you control.
2. Open the raw message the same way as in the header check above.
3. Find the Authentication-Results header and look for dkim=pass. Gmail’s version of the header also names the selector it checked, as header.s=.

One passing test proves the selector works for one service on one day. Whether every service keeps signing correctly is what your DMARC reports answer, every day, for all of them at once.

FAQ

Can a domain have more than one DKIM selector?

Yes, and most domains that send through more than one service do. Each sending service signs with its own key under its own selector, so an online store might have one selector for receipts, one for newsletters, and one for its help desk. The selectors live side by side in DNS and never conflict.

Does the selector name matter?

No. A selector is a label, and any short name of letters and digits works. What matters is that the name in the s= tag of the signature matches the name of the DNS record that holds the public key. If the two names differ, verification fails even when the key itself is correct.

What are selector1 and selector2?

They are the two selectors Microsoft 365 uses for each domain it signs for. You publish both as CNAME records when you set up DKIM, and Microsoft alternates between them when it rotates its keys, so mail keeps passing during a rotation.

The Takeaway

Finding a DKIM selector is a lookup: read the s= tag in a delivered message, check your platform’s authentication settings, or query DNS directly. Keeping every selector working is the ongoing part, because services get added, keys get rotated, and DNS records get cleaned up by someone who didn’t know what _domainkey meant. Your DMARC reports record all of it, and DMARCeye turns them into a live list of which selectors sign for your domain and which have stopped passing.