Check for DKIM Record Conflicts with Different

Why are DKIM selector conflicts a delivery risk?

You send emails that pass SPF and DMARC, yet some still land in spam or vanish silently. You’ve checked the basics — DNS, domain, authentication — but no clear culprit. What if the issue isn’t with your setup, but with how DKIM records are configured?

Different selectors in DKIM records can collide when multiple signing keys are published for the same domain. When receiving servers check DKIM, they look for a single, exact DNS record to validate the signature. An inconsistent or conflicting selector can lead to a missing or invalid match — meaning authentication fails, even if everything else is correct.

That failure isn't just a technical hiccup. It directly impacts inbox placement. Every failed DKIM check erodes sender reputation. The receiver sees it as signal of poor management or potential spoofing. The result? Lower deliverability, higher bounce rates, and harder recovery.

Key takeaways

Multiple DKIM selectors with overlapping or conflicting configurations can cause receiving servers to fail SPF/DKIM alignment.
Even a single misconfigured selector can trigger authentication failures, especially when keys are rotated or managed across multiple platforms.
Verifying DKIM record integrity with real email traffic patterns — not just static DNS checks — is essential to catch conflicts before they impact deliverability.

How do different DKIM selectors work, and why do they coexist?

You can have multiple DKIM selectors—like default or selector1—each pointing to a different public key in DNS. Organizations use them to rotate keys, test configurations, or track deliverability by campaign. Only one selector is active per message, but having multiple lets you manage key lifecycles and monitor signing behavior without disrupting outbound mail.

Selectors: Labels for Different Keys, Not Conflicts

Each DKIM selector is just a label attached to a public key record in DNS. It's not a separate signing mechanism—it’s a way to organize keys. When an email is signed, the sender's server uses a specific selector, which DNS then uses to fetch the matching public key for verification.

Think of selectors like versions of a signature. You might use default for production mail, test for internal trials, and campaign-2024 for a specific campaign. They don’t conflict—each one serves a specific purpose, and only one is used per message, based on how the sending system is configured.

Why Do Multiple Selectors Coexist?

Organizations keep multiple selectors active for practical reasons. Key rotation is common—when a key expires, you can roll out a new one under a different selector while letting the old one still verify old messages. This prevents delivery failures during transitions.

Some senders use different selectors to diagnose deliverability issues. If one campaign’s mail keeps failing DKIM checks, you can isolate whether the problem is in the key, the signing process, or the domain policy, thanks to granular tracking.

According to the DKIM standard (RFC 6376), there’s no limit to how many selectors a domain can publish—as long as each one maps to a valid, properly formatted public key. A domain can have ten selectors and still function, as long as the outgoing mail uses the correct one.

Conflicts only arise if two selectors point to conflicting keys that both claim to sign the same message—this shouldn’t happen if your email system is configured correctly. But misconfiguration is common, especially when using third-party tools or migrating between platforms.

Let’s say you’re sending a batch and get a DKIM failure. It could be that the wrong selector was used, or the public key isn’t properly published. A tool like MailTester’s bulk verification can help check the DNS records behind your sending domain, including selectors, to spot issues before they hurt your sender reputation.

What happens when two DKIM records exist for the same selector?

If two DKIM TXT records exist for the same selector, DNS combines them into one response containing multiple keys. Receiving servers expect a single, unambiguous key for a given selector. When they find multiple keys in a single record, they cannot reliably validate any of them, leading to DKIM verification failure — even if one key is correct. This ambiguity breaks trust in the authentication chain.

DNS limits selectors to one record per name

DNS does not support multiple TXT records with the same name and selector. If you define more than one DKIM record for the same selector (e.g., default._domainkey.example.com), the DNS server merges them into a single TXT record with concatenated values. This is a technical constraint of the DNS specification, not a design flaw.

According to RFC 1035, which defines the DNS protocol, a DNS name can have multiple records, but each record type must be unique per name unless explicitly combined. TXT records are designed to allow multiple strings, but the expectation in email authentication is one key per selector — not multiple keys in one response.

Why receiving servers can’t pick the right key

DKIM verification relies on knowing exactly which public key to use for a given selector. If the response contains two or more keys under the same selector, the receiving server has no way to determine which one the sender intended. It cannot assume the first one, the most recent one, or any specific order.

Most DMARC-compliant receivers will reject the message when the DKIM signature fails due to key ambiguity. That’s because even one failed authentication can trigger a DMARC reject. It doesn’t matter if one key would have worked — the result is still a failure.

Let’s say you have outdated DKIM keys left behind from a previous key rotation. If both old and new keys appear in the same selector’s TXT record, the receiving server can’t tell which one is valid. The verification fails — and your email might end up in spam or be blocked altogether.

If you’re managing DKIM records, always verify that no selector is duplicated. Use tools like MXToolbox or DNSCheck to inspect your DNS records. You can also validate your DKIM setup with MailTester’s inbox placement testing, which checks how your emails are received by real providers.

How to check for DKIM record conflicts using DNS tools

You can check for DKIM record conflicts by querying your domain’s DNS for all TXT records, filtering them to those with v=DKIM1, then verifying no selector appears more than once. Multiple records with the same selector break DKIM validation and harm email authentication. Use standard DNS tools like dig or nslookup, and validate results against RFC 6376, the standard defining DKIM.

Step-by-step: detect conflicting DKIM selectors

Run dig TXT yourdomain.com or nslookup -type=txt yourdomain.com from your command line. This retrieves all TXT records associated with your domain.
Filter the output to show only records containing v=DKIM1. These are the DKIM signing records. Ignore other TXT entries like SPF or DMARC unless they’re mixed in.
Examine each v=DKIM1 record and extract its selector (the part before .domain.com in the DNS name, e.g., selector1._domainkey.yourdomain.com).
Look for duplicate selectors. If you see two or more records with the same selector (e.g., two selector1 entries), they conflict. The receiving server may reject the DKIM signature due to ambiguity.
If duplicates exist, remove all but one instance. Keep only the most recent or active key. Conflicting selectors prevent proper authentication and can trigger spam filters.

Why this matters for deliverability

Multiple DKIM records with identical selectors aren’t just redundant — they’re invalid. According to RFC 6376, a selector must be unique within a domain. DNS systems don’t handle duplicate selectors gracefully, and mail receivers often reject messages where DKIM checks fail. This leads to hard bounces, poor deliverability, and damage to sender reputation.

The 5 steps described in “Step-by-step: detect conflicting DKIM selectors”, in order.

Even if your system allows multiple DKIM records, receiving mail servers treat duplicate selectors as misconfiguration. This can result in automatic rejection or tagging as spam, especially with stricter filters used by Gmail, Yahoo, or Microsoft. Cleaning up duplicate selectors is a low-cost, high-impact fix to improve inbox placement.

Use tools like dnschecker.org to verify records across multiple global DNS resolvers without running commands yourself. Cross-check the output manually or use a script to parse and group records by selector.

Once cleaned, test your setup with real email deliverability checks. Use MailTester’s inbox placement tester to see how your messages perform in real inboxes across different providers. This ensures not only correct DKIM but full message authenticity.

Why manual DNS checks are error-prone and incomplete

Manual DNS checks often miss subtle DKIM record conflicts, especially when multiple selectors are spread across subdomains or merged into malformed TXT records. You might see a valid record at mail.domain.com but overlook a conflicting selector at domain.com, resulting in deliverability issues even when both records appear "correct" in isolation.

Overlapping selectors and malformed TXT records

Many administrators assume that as long as no two records have the same selector, there's no conflict. In reality, some mail systems treat multiple selectors as a single record if the TXT data is merged improperly. Malformed TXT records—such as those with unquoted or broken strings—can silently fail parsing, leading to undetected misconfigurations. Tools that don’t validate record syntax may return truncated or incomplete data, making detection unreliable.

Even widely used DNS lookup services sometimes fail to expose issues. A record may return with no errors, but subtle problems like selector duplication across different subdomains or malformed syntax remain invisible. This is especially common when DKIM keys are managed by multiple teams or third-party senders, each adding records without coordination.

Subdomain sprawl makes detection harder

DKIM selectors can be spread across multiple subdomains—like mail.domain.com, postmaster.domain.com, or even smtp.domain.com. You might check one and think, "All good," while missing a conflicting selector on another. This fragmented setup is hard to track manually, especially when documentation is outdated or absent.

According to the DKIM specification (RFC 6376), selectors are used to identify different key sets, but they must not conflict across records for a single domain. When selectors overlap—even across subdomains—the receiving server may reject mail or mark it as suspicious.

Let’s say your marketing team added a DKIM record for mail.domain.com with selector selector1, while your IT team used selector1 on domain.com. Both appear to work in isolation, but the email server sees conflicting keys and may reject messages. That’s a conflict you won’t catch with a single dig TXT selector1._domainkey.domain.com query.

Automated verification tools like MailTester’s email checker can surface these issues by analyzing full domain configurations, detecting selector overlaps, and flagging malformed records—even when they’re distributed across subdomains. It doesn’t rely on isolated queries; it evaluates the full picture.

Can MailTester check for DKIM selector conflicts?

Yes — MailTester’s real-time verification API checks for DKIM selector conflicts by validating DNS records for DKIM, SPF, and DMARC during domain verification. It detects duplicate or conflicting selectors, identifies failing DKIM record resolutions, and returns specific errors when a selector has multiple keys or fails to resolve. This ensures your email authentication is clean and enforceable.

DNS-level validation catches real-world problems

DKIM selectors are defined in DNS TXT records under a specific subdomain (like default._domainkey.yourdomain.com). If multiple DKIM records exist for the same selector, or if a record fails to resolve correctly, email providers may reject or distrust messages. MailTester checks these records in real time using standard DNS lookup behavior — just as receiving servers do.

Let’s say you’ve configured multiple DKIM keys with the same selector for different sending systems. That’s not allowed. MailTester detects this and returns an explicit error, like “Multiple DKIM records found for selector ‘default’” or “DKIM record fails DNS lookup.” These aren't guesses — they’re direct outcomes of real DNS queries using standard protocols.

According to RFC 6376 (the DKIM standard), a selector must uniquely identify a public key. When multiple keys are associated with one selector, it breaks the specification. Major providers like Gmail and Outlook enforce this. Tools that skip DNS validation miss these conflicts entirely. MailTester doesn’t skip — it validates each record as it would be seen by a receiving server.

What you get: actionable, precise feedback

Instead of vague “invalid” flags, MailTester returns clear, structured results. If a DKIM record is missing, malformed, or conflicts with another record, it says so in plain language. This lets you fix issues before they impact deliverability.

If you're integrating with a platform like SendGrid, Mailchimp, or HubSpot, and suspect credential clashes or misconfigurations, use the real-time verification API to test domains and addresses at scale. It includes DKIM validation as a core step, so you don’t have to rely on guesswork or third-party tools with less comprehensive checks.

For a full list of checks — including DMARC policy enforcement, SPF alignment, and role account detection — see the full suite of bulk verification capabilities. All of this runs without requiring you to run tests through your own infrastructure. MailTester handles the DNS lookups, resolves them safely, and gives you the facts, not the hype.

What does a DKIM conflict look like in practice?

You send an email using a DKIM selector like selector1, but it fails validation because your DNS has two conflicting DKIM records for that same selector. Receiving servers see this inconsistency as a red flag—maybe even a sign of forgery. The result? Your message gets rejected or marked as suspicious, even if your mail is legitimate. This directly harms deliverability and increases your bounce rate over time.

Common symptoms of a DKIM selector conflict

Let’s say your domain’s TXT record for selector1._domainkey.example.com contains two separate DKIM public keys. That’s a conflict. Modern mail servers don’t guess which one to use—most will reject the message outright. You might not see a clear bounce message at first; instead, you’ll notice delivery delays or sudden drops in inbox placement.

This isn't just theory. The IETF’s RFC 6376, which defines DKIM, states that multiple signatures with the same selector for a single key are invalid and must be processed as such. If a server encounters this, it’s meant to reject the message. This behavior is well-documented in industry practices and is common across major providers like Google and Microsoft.

Why this hurts your sender reputation

Even if the message gets through, inconsistent DKIM checks can still trigger filtering engines. Some providers treat DKIM failures as a signal of weak security hygiene, which slowly erodes your sender reputation. Over time, this reduces your chances of landing in the inbox, especially for time-sensitive or high-volume campaigns.

Let’s say you’re running a campaign and suddenly notice a 10–15% spike in bounces across a small group of domains. Digging in reveals these domains have overlapping DKIM records with the same selector. That’s a classic sign. Without verification tools, spotting this pattern is nearly impossible—especially at scale.

That’s why running a bulk email list verification before sending is critical. With MailTester’s bulk verification, you can spot invalid, catch-all, or misconfigured domains—including problematic DKIM setups—before they hit your outbound pipeline. The tool checks DNS records, including DKIM, in real time. You’d catch selector conflicts before they ruin your deliverability.

The bottom line: DKIM conflicts aren't always obvious. But they’re fatal to deliverability when left unchecked. A single misconfigured record can cause cascading failures. Always validate your domain records when setting up or auditing email sending. And yes—this includes checking for duplicate selectors, even if you think you’re doing it right.

How to fix DKIM record conflicts: a step-by-step approach

You fix DKIM record conflicts by reviewing your DNS TXT records for duplicates, removing any extra entries with the same selector name, and confirming the change sticks. Keeping only one DKIM record per selector prevents email servers from rejecting messages due to validation ambiguity. This maintains sender reputation and improves inbox placement.

Step-by-step: resolve selector conflicts

Log into your DNS provider dashboard. Access your domain’s DNS management interface—this could be Cloudflare, AWS Route 53, GoDaddy, or another service. You need administrative access to edit records.
Locate all TXT records containing v=DKIM1. Use the search function if available. DKIM records start with this tag and include selector names, like selector1._domainkey.example.com. These records are critical for email authentication.
Check for duplicate selector names. Scan the list of records. If you see multiple entries with the same selector (e.g., default._domainkey twice), you have a conflict. The same selector should only appear once.
Delete duplicate records—keep only one per selector. Remove all but one copy of any duplicated selector. Retain the record you want to use (usually the most recent or active one). Leaving duplicates confuses mail servers trying to authenticate your messages.
Save changes and wait for DNS propagation. After saving, wait 5 to 30 minutes for the change to update globally. During this time, some emails may still fail to authenticate. Use real-time tools to check the status.
Verify the fix with a DNS lookup tool or MailTester’s API. Use a third-party service like MXToolbox or MailTester’s Real-Time Verification API to confirm only one valid DKIM record remains. This ensures your domain’s authentication is clean and reliable.

Why this matters

Duplicate DKIM records can cause authentication failures even if your keys are correct. Receiving servers often reject mail when they encounter ambiguity. A clean, single DKIM record per selector aligns with industry standards—this is outlined in RFC 6376, which specifies how DKIM signatures are structured and validated.

Once fixed, your email deliverability improves. You’ll see fewer bounces, better inbox placement, and fewer false positives on blocklists. Test your results live using MailTester’s inbox placement tester to validate whether mail actually lands in inboxes across major providers.

Best practices to prevent future DKIM conflicts

Prevent DKIM record conflicts by using unique selectors for each key rotation, keeping TXT records separate for each key, testing changes in staging first, and validating records with tools like MailTester’s real-time verification API. This reduces errors, maintains authentication consistency, and avoids delivery issues caused by overlapping or malformed records.

Use unique selectors for key rotation

Always assign a new, unique selector (like default, 2024q2, or mailchimp) when rotating DKIM keys.
Reusing selectors — especially across different domains or sending systems — creates ambiguity and leads to conflicting authentication results.
Use a clear naming convention (e.g., selector-name-date) to track key versions and avoid overlap.

Keep DKIM records separate and properly structured

Never combine multiple DKIM keys into a single TXT record. Each key should have its own record.
Multiple keys in one record increase the risk of misalignment, especially if one fails validation and the server tries to use it anyway.
Use a DNS audit tool to verify your records are correctly formatted and not inadvertently merged. The DKIM spec requires each key to be independently discoverable.

Test changes in staging before going live

Deploy new DKIM records in a staging environment first to verify they're correctly parsed and validated by receiving mail servers.
Test with tools like MxToolbox or internal staging mailers to check if the record resolves as expected.
Only promote changes to production after confirming successful lookup and parsing.

Verify records post-deployment with automated tools

Use real-time verification services — such as MailTester’s verification API — to validate DNS records and test for conflicts at scale.
Run periodic audits on your DNS zone to catch misconfigurations before they impact deliverability.
Integrate checks into your deployment pipeline to catch errors early, especially when managing multiple email systems (e.g. marketing, transactional, CRM).

DKIM conflicts aren’t always detected in real-time. A single malformed record can degrade sender reputation over time — catching them early matters.

How to integrate DKIM validation into your workflow

You can catch DKIM record conflicts early by verifying domains before sending, checking them regularly, and testing deliverability after fixes. Use MailTester’s API to validate sender domains and lists ahead of campaigns. Schedule recurring bulk checks to maintain compliance. Integrate with your email platform during setup or list import, and run inbox-placement tests to confirm your fixes actually land in inboxes.

Build validation into your pre-send process

Use the MailTester API to verify every sender domain in your campaign setup — this checks for missing, conflicting, or malformed DKIM records using real DNS lookups.
Run a bulk verification on your list before every send to detect domains with invalid or conflicting DKIM configurations.
Check for selector mismatches by testing whether a domain has multiple DKIM records with different selectors but no clear configuration path — a common source of delivery failures.
Use inbox placement testing to validate that fixes actually improve delivery — some domains pass technical checks but still hit spam filters.

Automate and sustain compliance

Integrate MailTester with your ESP (like SendGrid, Mailchimp, or HubSpot) so DKIM is validated during list import or onboarding.
Schedule weekly or monthly bulk scans of your domain list to catch drift — like when a third-party sender changes their DKIM selector without notification.
Monitor for overlapping DKIM records: a domain with multiple selectors but no clear alignment in SPF or DMARC is a high-risk setup.
Correlate DKIM results with broader deliverability metrics — tools like RFC 6376 define DKIM’s role in authentication, but real-world success depends on consistent alignment across SPF, DKIM, and DMARC.

Final thought: DKIM integrity is part of sender reputation

A single malformed DKIM record, especially one with conflicting selectors, can cause consistent authentication failures across legitimate outbound messages.

Receiving servers interpret these failures as a sign of poor governance, leading to filtering or rejection—even when content is clean and sender reputation is otherwise strong.

Proactive verification prevents reputation damage

Automated tools detect selector conflicts and syntax issues before they impact deliverability.
Fixing errors early avoids cascading delivery problems and maintains trust with inbox providers.
Regular verification of DKIM records is a low-effort, high-impact practice.

Sources

52.1% of the world's top 1.8 million domains (937,931 domains) now publish a valid DMARC record, up from 29.1% in 2023. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
Google reported 265 billion fewer unauthenticated messages sent to Gmail users in 2024 — a 65% reduction — after its bulk-sender rules took effect, with 500,000+ top domains publishing DMARC records in response. — Google (via MailOver bulk-sender requirements guide) (2024)

Keep reading

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

Frequently asked questions

What is a DKIM selector conflict?

A DKIM selector conflict occurs when the same selector appears in multiple DNS TXT records, causing ambiguity during email authentication.

Can multiple DKIM records coexist safely?

Yes, if each has a different selector. But having more than one record with the same selector is invalid and breaks DKIM validation.

How do I know if my DKIM records are conflicting?

Check your domain’s TXT records for multiple entries with identical selector names. Use a DNS lookup tool or MailTester’s API to validate.

Does MailTester detect DKIM record issues?

Yes — MailTester’s real-time verification API checks for DKIM record conflicts, including duplicate selectors and malformed DNS entries.

What happens if DKIM authentication fails?

Emails may be rejected, marked as spam, or not delivered, depending on the receiving server’s policy. This harms deliverability.

Can I have multiple DKIM keys on the same domain?

Yes — but each key must use a different selector. Multiple keys with the same selector cause conflicts and fail verification.

How often should I check my DKIM records?

At least before major sends, after changes to email infrastructure, or monthly as part of routine list hygiene.

Is DNS propagation required after fixing DKIM records?

Yes — changes to DNS take 5–30 minutes to propagate. Wait before testing validation.

Do all email providers check DKIM?

Most major providers (Gmail, Yahoo, Outlook) validate DKIM. Failures reduce inbox placement and can trigger filtering.

What other records should I verify alongside DKIM?

SPF and DMARC records are equally important. Use MailTester to validate all three as part of sender reputation hygiene.

Can I test DKIM before sending emails?

Yes — use MailTester’s inbox-placement testing or real-time verification API to test delivery conditions before sending.

Are DKIM selectors case-sensitive?

No — selector names are case-insensitive. Use lowercase consistently to avoid confusion.