DIY DKIM Selector Uniqueness Validation for Domains Using Same Selector

Why does DKIM selector uniqueness matter for email deliverability?

You’re sending emails with DKIM. The signature checks out. The domain is authenticated. Yet some messages still land in spam or fail altogether. Why?

One often overlooked reason: using the same DKIM selector across multiple domains. It seems harmless—just a label in DNS—but it creates ambiguity. Receiving servers can’t tell which domain a valid signature belongs to if multiple records share the same selector. The result? A valid signature gets rejected. Not because it’s forged, but because the system can’t resolve ownership.

It’s like having the same lock code for multiple buildings. Even if the code works, the door won’t open because the system can’t decide which building you mean. For senders, this leads to failed authentication, degraded reputation, and lower inbox placement—especially when sending at scale.

Key takeaways

• DNS queries for DKIM public keys can return conflicting records when the same selector is used across domains, causing validation ambiguity.
• Even valid DKIM signatures may be rejected if receiving servers cannot determine which domain the signature was meant for due to selector overlap.
• Enforcing per-domain, unique DKIM selectors prevents authentication failures that hurt deliverability and sender reputation.

Can two domains legally use the same DKIM selector?

Yes, two domains can legally use the same DKIM selector. There is no RFC that prohibits it. However, doing so creates a real risk: if both domains publish different public keys under the same selector, receiving servers may cache the first response they get. This can prevent proper signature verification later, breaking email authentication for one or both domains.

Why the same selector can cause real issues

DKIM selectors are meant to identify a specific public key in DNS. They're not unique across domains by design. Let’s say you run two unrelated businesses—you could both use selector1 for your DKIM records. That’s technically acceptable. But here’s the catch: if a mail server queries the DNS for selector1._domainkey.yourcompany.com and gets a response, it may cache it for hours. If the second domain updates its key later, the cached version can stay in place, and incoming messages from that domain will fail authentication.

This isn’t hypothetical. The DKIM specification (RFC 6376) doesn’t mandate selector uniqueness across domains. It only requires that each domain’s selector must be unique for its own key set. So while it’s allowed, it's not safe if you're managing multiple domains with different public keys.

When you should avoid reusing selectors

Reusing selectors across domains becomes risky when those domains send messages through shared infrastructure—or are managed by different teams. You’re essentially gambling that one domain’s DNS response won’t overwrite or delay the other’s. In practice, this leads to inconsistent authentication results and can degrade sender reputation.

MailTester’s email checker can help you validate DKIM records as part of deliverability checks. It doesn’t fix selector collisions—those must be avoided at setup—but it will flag misconfigured or missing DKIM settings before you send to users. For bulk campaigns across multiple domains, use bulk verification to ensure your lists are clean and your authentication setup is solid.

How to check if your DKIM selector is unique across domains?

You can check if your DKIM selector is unique by querying DNS for the TXT record using the selector and domain (e.g. selector._domainkey.example.com), then comparing the public key value against those from other domains you manage. If multiple domains return the same selector with different keys, the selector isn't unique—and that could cause authentication issues during email delivery.

Step-by-step validation process

1. Identify your DKIM selector and domain. The selector is the first part of the DKIM DNS record (e.g., dkim in dkim._domainkey.example.com). It’s defined in your email provider’s configuration.
2. Query DNS using dig or nslookup. Run a command like dig TXT dkim._domainkey.example.com to retrieve the public key from the DKIM TXT record. This returns the key in a base64-encoded format.
3. Extract the public key. The TXT record content will start with v=DKIM1; k=rsa; p=, followed by the public key. Copy this full value for comparison.
4. Check other domains using the same selector. Repeat steps 1–3 for every domain you manage that uses the same DKIM selector. Use a script or manual query to gather all values.
5. Compare public key values. If multiple domains return a record with the same selector (e.g., dkim._domainkey.company-a.com and dkim._domainkey.company-b.com) but different p= values, the selector is shared—and not unique across domains. This can confuse receiving mail servers and harm deliverability.

Why uniqueness matters

DKIM selectors must be unique per domain to prevent key conflicts. If two domains share the same selector but have different public keys, receiving servers may reject messages because they can’t securely validate the signature. RFC 6376 (the DKIM standard) doesn’t mandate selector uniqueness, but practical implementations rely on it to avoid ambiguity.

Tools like RFC 6376 outline the expected format, but enforceability depends on your email infrastructure. Even if your DNS is correctly configured, overlapping selectors can cause delivery failures—especially in high-volume or cross-domain campaigns.

Let’s be clear: sharing a selector across domains isn’t inherently broken—but it's operationally risky. If you use multiple domains for email campaigns, always verify selector distinctness. For large lists, automate verification using a service that checks multiple domains at scale.

“A common mistake is using the same selector across multiple domains. While technically allowed, it often leads to misidentification and increased bounce rates.”

If you're managing dozens of domains or testing deliverability across brands, consider using a tool that validates the full DKIM configuration—including selector uniqueness. MailTester’s bulk verification helps identify issues in large email lists, including misconfigured or duplicate DKIM setups across domains.

What happens when two domains share the same DKIM selector with different keys?

If two domains use the same DKIM selector but different private keys, receiving servers may accept email from one domain and reject the other—depending on which key they encounter first during DNS lookup. This inconsistency breaks authentication consistency, causes unpredictable delivery failures, and can lead to false DMARC failures when the recipient’s SPF/DKIM alignment fails. Spammers sometimes exploit this by spoofing valid selectors with fake keys, increasing the risk of false positives in DMARC reports.

How shared selectors create delivery ambiguity

DKIM uses a selector (a subdomain in the DNS record) to identify which public key should validate a message. If Domain A and Domain B both use selector1 but with different keys, a receiving server that resolves the DNS record for selector1.domain-a.com first may trust the key from Domain A—and ignore the one from Domain B, even if it’s valid. The server’s choice depends on DNS response order, retry timing, or cache behavior, not on sender identity.

This is especially dangerous when one domain is trusted (e.g., a marketing platform) and the other is not—it can result in legitimate mail from the second domain being rejected even if technically correct. It may appear as a DMARC failure, even when both domains are correctly configured, because the receiving server lacks a consistent validation path.

Why attackers target this weakness

Attackers can abuse this setup by creating fake DKIM records with common selectors like default or dkim, hoping to trigger a false validation path. If a receiving server picks the attacker’s key first due to DNS caching or ordering quirks, it may accept a forged message as authentic. This increases the volume of false positives in DMARC reports and makes it harder for legitimate senders to troubleshoot delivery issues.

While there’s no official standard mandating unique selectors across domains, the practice is widely recommended. RFC 6376 (the core DKIM specification) treats the selector as part of the identifier, but does not enforce uniqueness across domains—leaving enforcement up to implementers. That lack of constraint is why shared selectors remain a known risk in email authentication design.

Proper configuration ensures each domain uses a unique selector, even if that means generating separate key pairs. For teams managing multiple domains, validating DKIM configurations at scale is critical. Tools like MailTester’s email checker can help confirm that selectors and keys are correctly set and not shared across domains, reducing delivery risk before messages go out.

Real-world case: Shared selector, divergent keys, failed delivery

You can break email delivery even with technically correct DKIM setup if multiple domains use the same selector—like mail._domainkey—with different keys. Recipient servers cache DNS lookups, so when they see a valid key from one domain, they reuse it for another, even if the key doesn't match. This causes signature failures, false negatives, and inconsistent delivery, even when each domain’s individual configuration is valid.

The flaw in shared selector design

Let’s say two departments under the same company—business1.com and business2.com—use the same selector: mail._domainkey. Each domain has a distinct DKIM key published in DNS. On the surface, everything looks right. But here’s where things go wrong: mail servers don’t always re-resolve DNS every time. They cache DNS records, including DKIM public keys, for performance.

When a server first receives an email from business1.com and validates the DKIM signature, it stores the key from mail._domainkey.business1.com. Later, when it receives a message from business2.com with a different key at mail._domainkey.business2.com, the server still pulls the cached key from the first domain. Since the key doesn’t match the signature, the validation fails—even though business2.com is properly configured.

Why this causes real delivery problems

This isn’t theoretical. It’s a known edge case in email infrastructure. Because caching behavior varies across receivers (including large providers like Gmail, Outlook, and Yahoo), the failure may happen inconsistently. Sometimes one domain works, sometimes both fail—making troubleshooting hard.

The issue stems from a fundamental design choice: the selector is meant to be unique per domain or sending entity. Using the same one across domains breaks the assumption that key lookups are isolated. While RFC 6376 (the DKIM standard) doesn’t prohibit shared selectors, it doesn’t define cache behavior either—leaving room for unpredictable results.

Even if you’re not violating any standard, you’re still risking delivery. This is why tools like MailTester’s inbox placement tester can simulate how your messages land across major providers—catching these delivery quirks before they impact your list.

Let’s be clear: you can’t fix this without changing how you set up DKIM. Each sending domain should use a unique selector. If you’re using mail._domainkey across your organization, consider using business1.mail._domainkey and business2.mail._domainkey. This ensures each domain’s key is looked up independently and avoids cache confusion.

How to verify DKIM selector uniqueness in bulk across domains?

You can verify DKIM selector uniqueness across multiple domains by querying DNS for each domain’s DKIM TXT records, extracting the selector and public key, storing the pair as a key-value set, and checking for duplicate public keys—indicating selector reuse. This prevents alignment failures and improves email authentication integrity, especially before rolling out DMARC policies or scaling outbound email volume.

Step-by-step process to validate DKIM selector uniqueness

1. Retrieve DKIM DNS records for each domain
   Use a script or tool to query DNS for TXT records matching the DKIM selector pattern (e.g., selector._domainkey.example.com). This is standard practice in email authentication and aligns with RFC 6376, which defines how DKIM keys are published.
2. Parse the selector and public key
   Extract the selector (the first part before _domainkey) and the full base64-encoded public key from each record. The key is typically found within the p= tag. Ensure all parsing preserves formatting—any change invalidates the comparison.
3. Store each domain-selector-key triplet
   Use a database or structured log where the primary key is the combination of [domain, selector], with the public key as the value. This allows rapid lookup and comparison across domains.
4. Identify duplicates using the public key
   Search for any public key string that appears more than once across different domains. If the same key is used on multiple domains with the same selector, it’s a conflict. This is a common misconfiguration in shared or consolidated email environments.
5. Review and resolve conflicts
   Any duplicate keys should be investigated. The same selector used across different domains, especially with shared infrastructure, breaks SPF/DKIM alignment and can lead to DMARC failures. Correct by changing the selector on one or more domains.

When to run this validation

Run this process before implementing or tightening DMARC policies, especially when using a single email service provider across multiple domains. It’s also critical when scaling outbound campaigns or migrating domains to a new email platform. A single misconfigured selector can cause a 100% authentication failure across all domains.

Consider using automated tools like MailTester’s real-time verification API to help validate domain and email address health at scale, though it doesn't replace direct DKIM record checks. The focus here is on integrity at the DNS layer—ensuring your infrastructure is aligned before relying on reputation systems.

Can email verification tools like MailTester help validate DKIM selector uniqueness?

MailTester doesn’t verify DKIM selector uniqueness across domains. It focuses on validating email addresses, testing deliverability, and checking inbox placement — not auditing DNS configurations. However, it can flag delivery issues that may stem from authentication problems like conflicting or misconfigured DKIM records when processing large lists.

What MailTester actually checks

You’re using MailTester to confirm whether an address is valid, active, and likely to reach the inbox. It performs real-time checks using SMTP and MX lookups, detects role accounts and disposable domains, and identifies hard bounces and risky addresses. This helps reduce bounce rates and wasted sends.

It doesn’t examine DNS records directly, so it won’t tell you if two domains share the same DKIM selector. That task requires a DNS audit tool designed for configuration validation. For example, if you’re managing multiple domains and suspect selector collisions, you’d need to inspect your DKIM records via tools like RFC 6376 or DNS lookup services.

How MailTester can still help with authentication-related delivery failures

Let’s say you’ve sent a campaign and are seeing inconsistent inbox placement. MailTester’s inbox placement test can confirm whether messages land in inboxes or spam folders across major providers like Gmail, Outlook, and Apple Mail. If a batch of addresses consistently fails, it may indicate a broader issue — possibly linked to misconfigured authentication.

When you run a bulk verification, MailTester returns detailed results for each address, including delivery status and common bounce reasons. If many addresses return “authentication failed” or “policy rejection” bounces, that could signal a problem with your DKIM or SPF setup. While it won’t pinpoint selector collisions, it helps you correlate delivery failures with configuration issues. You can use the bulk verification tool to test your list and spot high-risk patterns early.

For deeper DNS-level validation of DKIM selectors, you’ll need to work with your DNS provider or a dedicated configuration auditor. But MailTester remains useful when you need to isolate whether deliverability problems stem from bad addresses or larger infrastructure flaws. It doesn’t replace a DNS audit — but it helps you know when one might be necessary.

Best practices to avoid DKIM selector conflicts

You must assign unique DKIM selectors to each domain or business unit—like mail1._domainkey or sales._domainkey—to prevent conflicts when multiple domains share the same selector. Common defaults like default._domainkey or dkim._domainkey risk overlap, especially in multi-domain setups. Even if you believe you're the only one using mail, DNS records can be misconfigured, and shared selectors increase the risk of signature mismatches. Regular audits and validation are essential.

Use domain-specific selectors to prevent ambiguity

• Assign a unique selector for each domain or business unit—use mail1._domainkey for one, mail2._domainkey for another.
• Avoid generic selectors like default, mail, or dkim unless you are absolutely certain no other domain uses it.
• When managing multiple brands or subsidiaries, treat each as a separate signing entity—this reduces the chance of a recipient's mail server receiving a valid but misattributed DKIM signature.

Audit DNS records regularly for conflicts

• Run automated scripts or use third-party tools to check DNS records across all your domains for duplicate selectors—this is especially important if you inherited or centralized infrastructure.
• If you must reuse a selector across domains, be aware that this practice is effectively incompatible with reliable DKIM verification and can cause delivery failures.
• Validate DNS records with tools that check multiple domains at once, and verify that only one domain signs emails using a given selector at any time.
• Consider using a service like MailTester’s email checker to test if a domain’s DKIM setup is correctly resolving and not conflicting with others.

The RFC 6376 specification outlines DKIM’s requirement for uniqueness in selector names—to ensure that a receiving server can correctly identify the key used to verify a message. Failure to maintain this uniqueness undermines the integrity of the authentication system.

While shared selectors seem efficient, the technical reality makes it near-impossible to guarantee one domain signs at a time when multiple are configured with the same selector. This can result in rejected messages or inconsistent authentication results. The best solution remains strict separation. Tools like MailTester’s integrations with platforms like SendGrid or HubSpot can help automate validation during onboarding, reducing manual errors.

How DMARC and DKIM together expose selector conflicts

You can detect DKIM selector conflicts across domains using the same selector by monitoring DMARC reports. When multiple domains use the same DKIM selector, they may share a public key, causing signature mismatches. DMARC fails messages with invalid DKIM signatures, making these conflicts visible through aggregated reports—helping you catch and fix them before they damage sender reputation.

Detection through DMARC reporting

DMARC only passes messages that have valid SPF and DKIM authentication. If a message fails DKIM—because the selector points to a key not matching the domain’s public record—DMARC marks it as failed. This failure is reported back to the sender via DMARC aggregate reports, which detail each failed authentication attempt.

When multiple domains share a selector, each domain may attempt to sign messages with the same selector, but only one can have the correct matching private key. The others will fail DKIM verification. Because DMARC enforces strict signature validation, these failures show up consistently in reports, revealing the collision.

Why this damages sender reputation

Repeated DMARC failures from misconfigured DKIM can trigger reputation systems to flag your domain as unreliable. ISPs and email providers use these failure rates to assess sender trustworthiness. A pattern of failed DKIM checks—especially when tied to shared selectors—can lead to higher filtering rates or even blocklisting over time.

Tools like Postmark’s DMARC reporting dashboard or Agari’s email security platform show failure trends over time. By reviewing these reports, you can identify domains with mismatched signatures and correct the selector configuration—ensuring each domain uses a unique selector tied to its own key pair.

Regular monitoring is essential. A single shared selector across multiple domains creates a systemic flaw. Fixing it early prevents long-term damage. You can use tools like MailTester’s bulk verification to test your domain’s email infrastructure for vulnerabilities before they impact deliverability.

As outlined in RFC 6376 (the DKIM specification), using unique selectors per domain is a best practice to ensure proper authentication and avoid key collisions. You can reference the full standard at IETF RFC 6376.

What if you can't change the selector? Can you still deliver reliably?

You can’t reliably deliver if multiple domains share the same DKIM selector, even if you control the sending schedule. DNS caching means a single lookup for one domain can expose the key to the other, breaking validation. The safest approach is to avoid shared selectors entirely.

Why shared selectors break deliverability

If you’re stuck using the same selector across domains, you’re relying on operational discipline to prevent both domains from sending simultaneously. In practice, this is fragile and unsustainable at scale. Even with strict timing, the moment a single email from one domain is checked, the DNS lookup caches that result—potentially exposing the private key used for another domain’s signing.

Many MTAs (Mail Transfer Agents) and receiving systems check DKIM signatures using cached DNS records. A cached match from one domain can mislead the verifier into accepting a signature from a second domain, even if it was signed with a different key. This undermines the security DKIM was designed to provide and increases the risk of spoofing.

Real-world consequences and limitations

There’s no reliable way to enforce one sender at a time when multiple domains rely on a shared selector. Even with internal queues and monitoring, configuration mistakes or delayed mail processing can still cause collisions. Once a bad signature is cached, it can affect deliverability for hours, especially on networks with aggressive caching policies.

Industry standards, like those laid out in RFC 6376, make clear that DKIM selectors must be unique per domain to ensure cryptographic isolation. Shared selectors violate this design principle. While some systems may tolerate it briefly, it’s a known risk that increases the likelihood of being flagged by filtering engines.

For organizations running multiple domains, especially those with outbound email volume, the overhead of managing shared selectors is not worth the risk. If you're using a service that forces this setup, evaluate whether you can refactor your DKIM setup to use unique selectors. Better yet, double-check your current configuration with a verification tool like MailTester’s email checker to see if your addresses are being flagged as risky or invalid due to misconfigured or overlapping signatures.

Ultimately, the architecture is the problem—not the tool. A reliable email program needs a solid foundation. If you’re trying to manage multiple domains with shared selectors, the path to stability lies in correcting the root cause, not in workarounds that trade reliability for short-term convenience.

The bottom line: uniqueness is not optional in email authentication

Using the same DKIM selector across multiple domains, even with different keys, creates ambiguity. Receiving servers cannot determine which key to trust, leading to predictable DKIM failures and inconsistent authentication results.

Why shared selectors break deliverability

• DKIM requires a unique selector per domain to map correctly to the public key in DNS.
• Even if both domains pass individual checks, a shared selector prevents receivers from resolving the correct key, breaking validation.
• When DKIM fails, DMARC enforcement becomes unreliable, increasing the risk of messages being marked as spam or rejected.

Unique DKIM selectors per domain eliminate ambiguity, ensure correct key resolution, and maintain trust across email infrastructure. This consistency is essential for reliable inbox placement and sender reputation.

Sources

• DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
• Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• How to Fix DMARC Report URI DNS Timeout for Faster Feedback
• Impact of Multiple TXT Records on DKIM Selector Routing and Email Validation
• SPF Mechanism Processing Delay in Multi-Homed Domains with Multiple IP Addresses
• DKIM DNS Lookup Failure Due to High Load on Email Verification Servers

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can two domains use the same DKIM selector and still pass DMARC?

Only if both domains publish identical DKIM keys. If keys differ, the receiving server will fail signature validation. DMARC will then fail, even if SPF passes.

Is a shared DKIM selector a common mistake?

Yes — especially in organizations with multiple domains or acquired businesses. It’s a silent cause of intermittent delivery issues.

How do I check if my DKIM selector is shared?

Use a DNS lookup tool to query the TXT record for your selector across all domains. Compare the public key values. If multiple domains return different keys, the selector is not unique.

Can DNS caching cause DKIM failures?

Yes. Receiving servers often cache DNS TXT records for up to 24 hours. If a different key is published later under the same selector, cache hit will cause signature rejection.

Does MailTester verify DKIM or DNS configuration?

No. MailTester does not verify DNS records, DKIM setup, or SPF alignment. It focuses on email address validity and inbox placement.

What’s the easiest way to prevent DKIM selector conflicts?

Use a unique selector for each domain. Avoid generic names like `default` or `mail`. Use meaningful prefixes like `mail1`, `postmaster`, or `b2b`.

What happens to emails if DKIM fails?

They may be rejected, marked as spam, or delayed. If DMARC is enforced, they will fail authentication entirely and likely land in spam or not be delivered.

Can a shared selector cause spoofing issues?

Yes. If one domain’s key is compromised, a malicious actor with control over another domain using the same selector could exploit the cached key to forge messages.

Do major email providers detect shared selectors?

They don’t flag shared selectors directly, but they do detect inconsistent DKIM validation, which triggers DMARC failures and spam filtering.

How often should I audit DKIM selectors across domains?

At least once per major change to your email infrastructure — during onboarding new domains, after security audits, or before expanding outbound campaigns.