The short answer is no, you should not use a single DKIM private key for multiple selectors. While it might be technically possible to configure, it goes against the fundamental principles and security benefits that selectors provide. Each selector is intended to correspond to a unique private and public key pair.
The entire purpose of a selector is to allow a domain to have multiple, distinct DKIM keys active at the same time. Using the same key for different selectors defeats this purpose and can cause significant management and security headaches down the line.
What is a DKIM selector?
To understand why sharing a private key is a bad idea, we first need to understand what a selector does. DKIM (DomainKeys Identified Mail) uses public-key cryptography to sign emails, proving that they came from an authorized server and were not altered in transit. The selector is a crucial piece of this puzzle.
When an email is sent, its header includes a DKIM-Signature which contains several tags, including the s= tag for the selector. The receiving mail server uses this selector to look up the correct public key in your domain's DNS records. The record is located at selector._domainkey.yourdomain.com. Once found, the server uses that public key to verify the email's signature.
Why use multiple selectors?
Domains use multiple selectors for several important reasons, all of which rely on each selector having a unique key.
- Key rotation. This is a critical security practice. You can introduce a new key with a new selector while the old one is still active. This allows for a seamless transition without interrupting mail flow. Once all your sending systems are using the new key, you can safely retire the old one.
- Multiple sending services. Most organizations send email from various platforms: Google Workspace for corporate email, Mailchimp for marketing, and Zendesk for support tickets. Each of these services should have its own DKIM key and a unique selector. This isolates the reputation of each service and simplifies management.
- Organizational separation. A large company might create separate selectors for different departments or geographical locations, allowing for more granular control and reporting.
The relationship between a private key, a public key, and a selector
The relationship is designed to be a clear chain: one private key corresponds to one public key, and that key pair is identified by one selector. This creates a simple, auditable trail.
So, could you technically create two DNS records, say s1._domainkey and s2._domainkey, and put the exact same public key data in both? Yes. Your mail server could then sign emails with the single corresponding private key but use either selector in the header. Verification would succeed because both selectors would lead to the correct public key.
However, this completely undermines the benefits. If that single private key is ever compromised, you can't just rotate the key for one service; you have to revoke it for every service and selector that uses it. This configuration is confusing, non-standard, and makes your email security more brittle, not more robust.
The verdict
Always stick to the best practice: one unique private key for each selector. This is how DKIM was designed to work, and it ensures your email authentication is secure, manageable, and aligned with industry standards.
Having multiple DKIM records, each with its own key and selector, is not only allowed but is considered a best practice in many scenarios. Resisting the temptation to share keys across selectors will save you from potential security risks and operational complexity in the future.
Can multiple 'rua' URIs be specified in a DMARC record?
Can a DMARC record have multiple 'p' tags?
What DNS record type is used for DKIM?
Is 'relaxed' or 'simple' canonicalization more strict in DKIM?
What is the maximum recommended key length for DKIM?
What DKIM tag specifies the domain signing the email?
