What Is a DKIM Selector? How to Find Yours

What a DKIM selector is

A DKIM selector is the short name in a DKIM signature that tells a receiving mail server where to look up the public key.

DKIM signs outbound mail with a private key controlled by your mail provider, email platform, or sending server. The matching public key is published in DNS under selector._domainkey.signing-domain. When Gmail, Outlook, or another receiver sees a DKIM-Signature header, it reads the s= tag for the selector and the d= tag for the signing domain, then uses those two values to fetch the key and verify the signature.

For example, if a message has d=example.com and s=google, the DKIM key lookup is google._domainkey.example.com. That host may contain the DKIM TXT record directly, or it may be a CNAME that points to a key record managed by your provider. The selector lets one domain use different keys for Google Workspace, Microsoft 365, a billing app, a CRM, and a marketing platform without making every sender share one key.

The selector is not a secret. It is a DNS label and lookup hint. The private key is the secret part. The DKIM lookup pattern and signature tags are defined in RFC 6376.

How to find your DKIM selector

The most reliable way is to inspect a real message from the exact sender you care about. DNS alone is not enough unless you already know the selector.

• Send a fresh email from the mailbox, app, or platform you want to check to a Gmail, Outlook, or test inbox.
• Open the raw message headers and find the DKIM-Signature header.
• Read s= for the selector and d= for the signing domain.
• Combine them as s-value._domainkey.d-value, then query that host in DNS.
• Confirm the lookup returns a valid DKIM key record, usually a TXT record with v=DKIM1 and p=, or a provider-specified CNAME that resolves to that key.

If the header says s=selector1; d=example.com, check selector1._domainkey.example.com. If it says s=mailo; d=news.example.com, check mailo._domainkey.news.example.com. Use the signing domain in d=, not automatically your root domain.

You can also find selectors in your provider admin panel. Google Workspace shows the selector during DKIM setup. Microsoft 365 commonly uses selector records for each custom domain. Many email service providers use names such as k1, k2, selector1, s1, or provider-specific CNAME hosts. Do not rely on guessing. Check a live message header.

What to check after you find it

Finding the selector only helps if the DNS record matches the mail that is actually being sent.

• Make sure the exact selector host exists in DNS as the provider instructed, either as TXT or CNAME.
• Make sure DKIM signing is enabled for your sending domain, not only for the provider's default domain.
• Check that the DKIM signing domain aligns with the visible From domain, either exactly or at the organizational-domain level allowed by DMARC.
• Rotate keys by publishing the new selector first, enabling signing with it, then removing the old selector only after old mail no longer needs to verify.
• Check every sender separately. Your mailbox, CRM, help desk, billing system, and newsletter tool can each use different selectors.

A missing selector record usually causes DKIM verification to fail. A stale record can fail after a provider rotates keys. A valid DKIM signature can still fail DMARC if it signs with a domain that does not align with the From domain. DMARC policy, alignment, and aggregate reports are defined in RFC 7489.

How selectors fit with SPF, DMARC, MX, and blocklists

DKIM is one part of deliverability. Mailbox providers look at authentication, DNS, reputation, complaints, and message quality together.

SPF is a DNS TXT record that lists which servers may send for your envelope domain. Publish one SPF record per owner name, include only services that really send for you, and stay within the SPF limit of 10 DNS-lookup terms from RFC 7208. ~all is a soft fail and is useful while you are still finding legitimate senders. -all is a hard fail and is better after the record is complete.

DMARC tells receivers what policy to apply when neither SPF nor DKIM passes in alignment with the visible From domain. Start with p=none and rua=mailto:... reports so you can see legitimate senders and spoofing attempts. Move to p=quarantine or p=reject only after every real sender passes aligned SPF or aligned DKIM. Gmail's sender guidelines require SPF or DKIM for all senders to Gmail personal accounts, and SPF, DKIM, and DMARC for bulk senders. Microsoft's authentication guidance treats SPF, DKIM, and DMARC as related controls for checking inbound mail and reducing spoofing.

MX records do not control DKIM. They tell the world where inbound mail for a domain should be delivered. Still, missing or messy mail DNS can be a reliability signal. Public blocklists matter when a sending IP or domain has been abused. Authentication will not guarantee inbox placement, but unauthenticated or misaligned mail is more likely to be spammed, rate limited, or rejected by Gmail, Outlook, and other receivers.

To check all of this in one pass, run a free InboxRadar domain scorecard. It reads SPF, DKIM, DMARC, MX, and common blocklist signals, then watches for drift.