A DKIM selector is the label a sending service uses to find the right public key in DNS when it signs an email. It is a small part of an email header, but it matters because a domain can publish more than one DKIM key at the same time. Understanding the selector helps you diagnose a missing key, confirm a provider setup, and avoid editing the wrong record.
How a selector fits into DKIM
DKIM works with a private key held by the sending service and a matching public key in DNS. When the service sends a message, it adds a DKIM-Signature header. The signature contains a signing domain, shown as d=, and a selector, shown as s=. Together they identify the public key record the receiving system should query.
Build the DNS host name
If the selector is selector1 and the signing domain is example.com, the public key is normally published at selector1._domainkey.example.com. The provider chooses the selector; it is not a generic word you can guess. Check a fresh message header or the provider’s setup instructions to get the exact value.
Why one domain may have several selectors
A business can use different selectors for Microsoft 365, Google Workspace, a marketing platform, a CRM, and a transactional-email service. A provider may also rotate keys by publishing a new selector while older mail still references the old one. Several selector records can be normal. The question is whether each active sender has the record it needs and signs mail successfully.
Find the selector in a message header
Open the complete original message, find the DKIM-Signature line, and look for s=. On the same line, find d=. Do not confuse the selector with the visible From address or the return-path. Use those two values to construct the DNS host name and query the public record. The email-headers guide explains where to find these fields.
What a selector record contains
The DNS record is generally a TXT value beginning with v=DKIM1 and containing a public key after p=. DNS dashboards may split a long key into quoted fragments; this can be normal. Do not publish a private key in DNS, edit the public key manually, or copy a selector value from another company. Follow the sending provider’s current instructions.
Common selector problems
Failures often come from publishing the record at the root domain instead of under _domainkey, using the wrong selector, omitting part of the host name, or enabling a sender before its DNS record has propagated. A key rotation can also leave a platform signing with a selector that no longer exists. Compare the live header, DNS host, provider settings, and timing of recent changes.
Test the complete result
A visible selector record is not proof that messages pass DKIM. Send a fresh message from the relevant platform and inspect the receiving mailbox’s authentication result. Look for dkim=pass, then check whether the signing domain aligns with the visible From address for DMARC. See how to check DKIM and the DKIM record example.
Keep a selector inventory
Document the provider, selector, signing domain, owner, date enabled, and last successful test. Review it whenever you add a new sender, migrate platforms, or retire a vendor. This prevents an old record from being removed while a critical but infrequent mail stream still relies on it.
Run Beacon’s free domain check to review the public DKIM, SPF, and DMARC foundation before troubleshooting a specific selector.