What s= and d= actually do
Every DKIM-signed message carries a DKIM-Signature header. Two of its tags decide where the receiver looks for the public key. d= is the signing domain, the domain that takes responsibility for the message. s= is the selector, which picks one key among the several a domain can publish. [1]
The receiver builds the lookup name from the two: selector, then _domainkey, then the d= domain. RFC 6376's own example is d=example.com with s=foo.bar, which is looked up at foo.bar._domainkey.example.com. [1] If nothing is published there, or the key does not verify the signature, DKIM fails.
For DMARC, d= matters more than s=. A DKIM pass only counts toward DMARC if the d= domain aligns with the domain in the visible From address. [8] A platform that signs with its own domain will pass DKIM and still fail DMARC alignment for you.
Find the selector in a message header
- Send yourself a message from the platform you want to check.
- Open the full headers. In Gmail, open the message, click More next to Reply and choose Show original. In Outlook, use File then Properties; in Apple Mail, View, Message, All Headers. [6]
- Search for DKIM-Signature. There may be more than one: a platform can add its own signature as well as yours.
- Read s= and d=. Microsoft's documentation shows a value such as s=selector1-contoso-com. [3]
- Check the Authentication-Results line added by the receiving server; DKIM results there can include header.d and header.s, the same two values. [7]
- Confirm the key exists by looking up the TXT or CNAME record at selector._domainkey.yourdomain in your DNS panel.
The selector each platform documents
Selectors are set by the sending platform, not by you, except where the platform lets you choose a prefix. These are the names each vendor's documentation gives.
| Platform | Selector host you publish | Record type | Key length | Source |
|---|---|---|---|---|
| Google Workspace | google._domainkey (default prefix google, changeable) | TXT with the public key | 2048 recommended if your DNS host supports it; otherwise 1024 | [2] |
| Microsoft 365 | selector1._domainkey and selector2._domainkey | CNAME to a Microsoft-hosted key | 1024 default or 2048 when created in PowerShell | [3] |
| MailerLite | litesrv._domainkey | CNAME to litesrv._domainkey.mlsend.com | Managed by MailerLite | [4] |
| Kit | cka._domainkey (Kit's documented example) | CNAME | Managed by Kit | [5] |
Running two providers at once
This is where DKIM is easier than SPF. SPF allows one record per name, so every sender must be merged into it. DKIM keys live at separate names, so each provider just adds its own. RFC 6376 describes selectors precisely for this: one domain can publish several concurrent keys, for example by office, by date or for a third party it delegates signing to. [1]
Worked example: a business uses Google Workspace for staff mail and MailerLite for its newsletter. DNS holds a TXT record at google._domainkey and a CNAME at litesrv._domainkey. [2] [4] Staff mail is signed with s=google, newsletters with s=litesrv, both with d= the business domain. Neither record touches the other.
The only conflict is a duplicate name. Google's documentation covers it: if your domain already uses a DKIM key with the google prefix, enter a different prefix when generating the new one. [2] At Namecheap, enter only the part before your domain in the Host field, such as google._domainkey; Namecheap adds the domain itself. [9]
Rotating keys without downtime
RFC 6376 describes the safe sequence: publish the new public key alongside the old one, switch signing to the new private key, and remove the old key record after a transition period. It also advises against reusing a selector name for a new key, because a failure on a retired key would then be indistinguishable from forgery. [1] An empty p= tag in a key record means the key has been revoked. [1]
Platforms that use CNAME selectors handle much of this for you. Microsoft 365 publishes two selectors: one is active, the other is used only after a future rotation. Microsoft says a rotation takes four days (96 hours) and that you cannot start another until it finishes. [3] For MailerLite and Kit, your CNAME points at a record the platform controls; their documentation cited here does not describe a rotation schedule, so there is nothing for you to change unless they ask.
| Step | TXT-key platform such as Google Workspace | Why |
|---|---|---|
| 1 | Generate a new key with a new prefix, for example google2026 | New selector, so both keys can exist [1] [2] |
| 2 | Publish it at google2026._domainkey and wait | Google says DKIM can take up to 48 hours to start working [2] |
| 3 | Start signing with the new key | Old key still published, so in-flight mail verifies |
| 4 | After a transition period, remove the old record or publish it with an empty p= | Empty p= marks the key revoked [1] |
| 5 | Check a fresh message header for the new s= value | Confirms the switch actually happened |
Key length and the 1024-bit question
RFC 6376 says signers must use RSA keys of at least 1024 bits for long-lived keys, and verifiers must handle keys from 512 to 2048 bits. [1] Google recommends selecting 2048 if your domain provider supports 2048-bit keys, and 1024 if it does not. [2]
In practice the limit is your DNS host's handling of long TXT values. If a 2048-bit key will not save, Google's fallback is 1024. Platforms that use CNAME selectors, such as Microsoft 365, MailerLite and Kit, host the key themselves, so the length is their choice rather than a DNS problem for you. [3] [4] [5]
Questions before you decide
Where do I find my DKIM selector?
Open a message you sent, view its full headers (in Gmail: More, then Show original), and find the DKIM-Signature line. The s= tag is the selector and d= is the signing domain. Microsoft's documentation gives s=selector1-contoso-com as an example value.
Can two email providers use DKIM on the same domain?
Yes. RFC 6376 designed selectors so one domain can publish several keys at once. Each provider's key lives at a different name under _domainkey, so Google Workspace and MailerLite, for example, do not conflict. Only a duplicate selector name causes a clash.
Should I use a 1024-bit or 2048-bit DKIM key?
RFC 6376 requires at least 1024 bits for long-lived keys. Google Workspace says to choose 2048 if your DNS host supports it, and 1024 only if it does not. Microsoft 365 offers both sizes when you create a signing configuration in PowerShell.
How long does a Microsoft 365 DKIM key rotation take?
Microsoft says key rotation is not immediate and takes four days, or 96 hours, and that you cannot start another rotation while one is in progress.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures Accessed 30 Oct 2026
- Google Workspace Admin Help: Set up DKIM Accessed 30 Oct 2026
- Microsoft Learn: How to use DKIM for email in your custom domain Accessed 30 Oct 2026
- MailerLite Help: How to authenticate a domain in Namecheap Accessed 30 Oct 2026
- Kit Help: Verify your domain to optimize your deliverability Accessed 30 Oct 2026
- Gmail Help: Trace an email with its full headers Accessed 30 Oct 2026
- RFC 8601: Message Header Field for Indicating Message Authentication Status Accessed 30 Oct 2026
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Accessed 30 Oct 2026
- Namecheap Knowledgebase: How do I set up host records for a domain? Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.