Can I Have Multiple DKIM Records on the Same Domain?

Modern organizations rarely send all email from one place. Marketing platforms, help desk systems, productivity suites, and transactional tools may all send mail from the same domain. 

That raises a common question: can you publish multiple DKIM records on one domain? Yes, you can, and in many cases, you should. The key is understanding how selectors work and how to manage them cleanly at scale.

What is DKIM?

DKIM, or DomainKeys Identified Mail, is an email authentication method that helps verify that a message was sent by an authorized domain and was not altered in transit.

It works by adding a digital signature to outgoing email. The sending service signs the message with a private key, and the receiving server verifies it using a matching public key published in DNS.

For organizations, DKIM helps protect message integrity, strengthen domain trust, and support broader email security efforts. It also works alongside SPF and DMARC to improve authentication outcomes.

A DKIM record is the DNS entry that publishes the public key used to verify a message’s DKIM signature. It is typically published as a TXT record under a selector-based subdomain, such as:

In that example, selector1 is the DKIM selector, which tells the receiver which key to look up. Selectors make it possible to publish multiple DKIM records on the same domain, which helps organizations separate sending services, rotate keys, and manage authentication more cleanly.

Can I Have Multiple DKIM Records on the Same Domain?

Yes. You can safely publish multiple DKIM records on the same domain, and this is a normal setup for many organizations.

The reason it works is simple: DKIM records do not all sit in one flat namespace. Each one is tied to a different selector, so each record lives at its own DNS location. That separation avoids direct conflict.

For example, a domain might have:

• mktg._domainkey.example.com
• support._domainkey.example.com
• workspace._domainkey.example.com

Each of those is a separate DKIM record, even though all belong to the same domain.

What counts as a valid configuration?

A valid DKIM setup uses:

• One unique selector per sending service or use case
• One public key per selector
• A clear mapping between the selector and the sending platform that uses it

What causes problems is not having multiple records in general. The problem usually starts when two different systems try to use the same selector, or when duplicate DNS entries exist for the same selector. That can create verification failures, ambiguous DNS lookup results, or broken DKIM authentication.

So the safe rule is: Multiple DKIM records are fine when each one uses a unique selector.

When Can Organizations Use Multiple DKIM Records

Many organizations need more than one DKIM record because modern email infrastructure is distributed across many tools and teams.

Common examples include:

• Microsoft 365 for employee mail
• Google Workspace  for business communication
• Marketing automation platforms
• CRM systems
• Support or ticketing tools
• Billing or transactional mail systems

These services often send different types of email from the same domain, or from related multiple domains, and each one may require its own DKIM key.

Organizations also separate selectors by mail stream, such as transactional emails, marketing email messages, regional sending infrastructure, or executive or high-trust email communication. This has real operational value as separating selectors makes it easier to:

• Assign ownership by platform or team
• Isolate issues when a message fails authentication
• Rotate one key without disrupting another service
• Keep better control in decentralized IT environments

In other words, multiple DKIM keys are often a reflection of how email actually works in enterprise environments today.

How to Add Multiple DKIM Records

Adding multiple DKIM records is usually straightforward, but it should be done in a controlled sequence.

1. Inventory every authorized sender

Start by identifying every system allowed to send email from the domain. This includes core email platforms, marketing tools, support systems, and third-party applications. If you skip this step, you risk enabling DKIM for one sender while leaving others unauthenticated.

2. Generate or obtain the DKIM key for each sender

Each sending platform will either generate its own key pair or ask you to create one. The sender uses the private key for DKIM signing, while the matching public key is published in DNS.

3. Assign a different selector to each service

Each sender should use a different selector. This is what allows multiple selectors to coexist on the same domain safely. Selector names should be clear and consistent. For example:

• m365
• google
• crm
• marketing-us

4. Publish the DNS records

For each sender, add the corresponding DNS TXT record to your domain’s DNS configuration. Each selector should point to its own public key.

5. Activate DKIM in the sending platform

Once DNS is published, enable DKIM inside the sending application or mail server settings so it begins signing messages with that selector.

6. Validate the configuration

Use a DKIM record checker  or inspect the email header of a test message to confirm the selector is being used and the signature validates correctly.

7. Document ownership and changes

In enterprise environments, governance matters as much as technical setup. Keep records of:

• Selector naming conventions
• Business owner or technical owner for each selector
• Change history
• Key rotation dates

Coordination across DNS, email, and security teams reduces the chance of silent failures.

Best Practices for Managing Multiple DKIM Records at Scale

As the number of senders grows, DKIM becomes less about simple setup and more about lifecycle management. A few best practices make a big difference.

Use strong keys and rotate them regularly

Old or weak keys create unnecessary risk. Regular key rotation helps maintain trust and limits exposure if a key is ever compromised.

Use per-service selectors

Avoid using one selector across many systems. Per-service selectors make troubleshooting easier and reduce the blast radius of configuration mistakes.

Keep selector naming consistent

A naming convention helps teams quickly understand what each selector is for. This matters more as the number of multiple records grows.

Maintain a centralized sender inventory

You should know which service sends from which domain, which selector it uses, whether it signs with DKIM, and whether it also aligns with your SPF record and DMARC record

Clean up unused records

Old selectors from retired systems should not stay in DNS forever. Removing stale entries reduces clutter and makes monitoring more accurate.

Monitor authentication performance

DKIM management should be part of broader monitoring, not a set-it-and-forget-it task. Regular audits help you catch:

• Failed signatures
• Expired or rotated keys not updated in DNS
• Unauthorized senders
• Alignment issues affecting deliverability

This is where DKIM becomes part of a broader authentication and human risk reduction strategy, rather than just a technical checkbox.

Multiple DKIM Records Can Strengthen Authentication When Managed Well

You can have multiple DKIM records on the same domain, and in many organizations that is the right approach. The key requirement is simple: each record must use a unique selector.

When selectors are well managed, DKIM supports message integrity, stronger domain trust, and more reliable email authentication across modern cloud-based sending environments.