Why does your domain TXT record have multiple DKIM entries?

You send emails from your domain, and they’re getting rejected or marked as spam — even though you’ve set up DKIM. The issue might be hiding in your DNS: a TXT record with multiple DKIM entries, each using the same or conflicting selectors.

DKIM signatures rely on precise identifiers. If your domain’s TXT record contains multiple DKIM entries with identical or overlapping s= selectors, the receiving server doesn’t know which one to use. This confusion leads to validation failures, even if your actual keys are correct.

Here’s what you’ll find: how selector conflicts happen, why having multiple DKIM entries is not a feature, and how to fix it cleanly to avoid delivery issues.

Key takeaways

  • DKIM uses unique s= selectors to identify signing keys; only one valid selector should be used per sending domain.
  • Multiple DKIM entries with the same selector or overlapping configurations cause validation ambiguity and reduce deliverability.
  • Correcting redundant or conflicting DKIM records in DNS ensures that receiving mail servers can authenticate your emails reliably.

What happens when the s= selector is not found?

If your domain’s TXT record contains multiple DKIM entries but lacks the specific s= selector that matches the signing key, receiving mail servers can’t locate the correct public key to validate the DKIM signature. This causes authentication to fail, resulting in emails being rejected, marked as spam, or silently dropped—no matter how otherwise correct your SPF or DMARC records are.

Why the s= selector matters

DKIM uses a selector (defined by the s= tag) to identify which public key to use when verifying a message. If the receiving server looks for s=mail but the TXT record doesn’t include that selector, the validation process halts. Even a single missing or mismatched selector breaks the chain.

Receiving servers rely on DNS lookups to find DKIM public keys. They query the DNS at selector._domainkey.yourdomain.com. If that record doesn’t exist—or if the s= value in the DNS record doesn’t match the one used to sign the email—the signature is marked as invalid. The email may still be delivered, but with low credibility, triggering filters or spam scores.

Real-world impact on deliverability

Without a valid DKIM match, your sender reputation suffers. ISPs and email providers track authentication performance across domains. Repeated failures—even if isolated—can lead to reduced inbox placement, increased filtering, or long-term blacklisting.

Even if SPF and DMARC are correctly configured, DKIM remains a critical layer. A 2022 study by Return Path (now Validity) found that emails with failed DKIM checks were 2.3 times more likely to land in spam than those with successful validation, even when other authentication steps passed. It’s not an optional step—it’s a core control.

Check your DKIM records regularly. Avoid duplicate or conflicting entries. Use tools that validate DNS configurations for completeness. You can test your domain’s alignment before sending by checking the full DNS record via public tools like MXToolbox or DNSWatch.

If you’re managing a sending list, ensure every address is clean and properly authenticated. You can verify email addresses before sending using MailTester’s email checker, or validate entire lists with our bulk verification tool. It helps spot issues like incorrect DKIM selectors early—before they hurt deliverability.

How to diagnose 's= selector not found' in your DKIM setup

When your email service says "s= selector not found," it means your domain’s TXT record for DKIM has a missing or duplicate s= tag. You must check your DNS records for multiple DKIM entries under _domainkey.yourdomain.com, ensure each has a valid, unique selector, and verify the selector matches what your email provider uses. Use a real-time DNS lookup tool to confirm this.

Step-by-step diagnosis

  1. Run a real-time DNS lookup using MxToolbox or the command dig TXT _domainkey.yourdomain.com to pull up your domain's TXT records. This shows exactly what DNS servers are serving for DKIM.
  2. Look specifically at records under _domainkey.yourdomain.com. If you see multiple entries, especially with the same s= value, that’s a red flag. The s= selector must be unique per DKIM key.
  3. Check each record for a valid s= tag. It should be present and contain a string like default or 202405. Missing or malformed selectors will trigger the "not found" error.
  4. Compare the selector in DNS to the one your email service (SendGrid, Mailchimp, etc.) is using. If the service expects s=sendgrid but your DNS has s=default, delivery will fail. The selector must match exactly.
  5. If you find duplicates or malformed entries, remove the invalid ones. Only one DKIM record per selector should exist. You can verify changes using MxToolbox’s DNS lookup again after updating.

Common pitfalls and fixes

Many users add multiple DKIM keys by accident—either during setup or when rotating keys. This leads to conflicting or missing s= values. If you're using a bulk email tool like SendGrid, double-check its recommended DNS configuration in the settings pane.

s= selectors are not arbitrary. They must be unique and consistent across your sending infrastructure. A duplicate selector, even if valid, can confuse mail servers that expect one specific key per selector. For a more thorough check, use a bulk verification service like MailTester’s email list verification to test how your domain handles inbound and outbound email delivery in real-world environments.

Common causes of multiple DKIM entries in a single domain

If your domain’s TXT record has multiple DKIM entries, the most likely reason is that several sending platforms or services were configured independently without audit. This can happen when marketing, transactional, and automation systems each add their own DKIM selector (like s=) without checking existing records. When selectors conflict or overlap, mail servers can’t find the right one, causing delivery failures.

Independent platform configurations

  • You’re using multiple email tools—like SendGrid for campaign emails, Amazon SES for transactional messages, and Mailchimp for newsletters—each adding its own DKIM record without coordination.
  • Let’s say you added a new sender role via a marketing platform, but forgot to check if the domain already had a DKIM entry for another system. That’s how duplicates creep in.
  • Many systems now support DKIM’s selector abstraction, but poor coordination means selectors like s=marketing and s=transactional can co-exist, creating confusion for receivers unless properly mapped.

Legacy or unclean migration

  • After switching from an old email service, the old DKIM record wasn’t removed, leaving behind a stale s=old entry that no longer corresponds to a real sending system.
  • During domain migration or consolidation, DNS changes were applied piecemeal. A new sender was added without reviewing existing records, leading to multiple s= entries.
  • Manual edits during DNS updates—especially on shared infrastructure—can result in accidental duplication. One typo or copy-paste error adds a second or third selector with the same name.

If you're unsure whether your domain's DKIM setup is clean, verify it using a reliable tool before sending. You can test individual email addresses or entire lists with MailTester’s email checker to catch invalid or misconfigured entries early. For larger campaigns, bulk verification ensures your list is both deliverable and DNS-compliant, reducing bounce rates and protecting sender reputation.

The difference between one DKIM selector and multiple ones

Having multiple DKIM records with conflicting or duplicated selectors can cause validation to fail because receiving servers use the s= tag to find the correct public key. If the selector doesn’t match exactly, even one mismatched value breaks DKIM verification. The best practice is to use one selector per domain unless multiple senders require separate keys, and even then, each must be correctly mapped.

One selector ensures consistent validation

When a domain has only one DKIM selector, validating servers know exactly which key to use. There’s no ambiguity. The s= tag in the DKIM-Signature header points directly to the matching DNS record. This consistency is why most email providers and security tools expect a single, well-defined selector per domain.

Using multiple selectors without clear separation between sending sources creates confusion. Even if a server accepts multiple records, it must still find the one that matches the s= value in the email header. A mismatched or missing selector means DKIM fails, which can hurt deliverability—even if everything else is correct.

Multisender setups require clarity, not duplication

Multiple selectors are valid only when each serves a distinct sending entity—like marketing (s=marketing) and transactional (s=transactional)—and each record is properly published in DNS with the correct selector name. But you must ensure each selector is used consistently across the sending infrastructure.

If you accidentally duplicate a selector or mislabel it—say, using s=main in the header but s=master in DNS—the receiving server can't find the key. This triggers a validation failure, even if the cryptographic signature is correct. According to RFC 6376, the s= tag is mandatory and must match exactly. A single typo ruins the entire check.

Even if you have separate sending systems, use different subdomains (like mail.yourcompany.com) to isolate DKIM keys. That keeps your DNS clean and avoids selector overlap. Some tools, like MailTester's email checker, can validate syntax and delivery readiness—including DKIM alignment—before you send.

How to fix multiple DKIM entries safely

If your domain’s TXT record has multiple DKIM entries and you’re seeing an s= selector not found error, you’re likely sending with a selector that doesn’t exist in DNS. You must keep only one valid DKIM record per sending service, ensure the s= selector matches what your email service provider (ESP) uses, and verify it resolves properly across multiple public DNS resolvers. Keeping extra or outdated records can break authentication and hurt deliverability.

Step-by-step: resolve multiple DKIM issues safely

  1. Check all existing DKIM records using a public DNS tool. Use a reliable service like MXToolbox or Google Public DNS to query your domain’s TXT records. List every s= selector and the corresponding value. This shows which DKIM records are active and which may be stale.
  2. Verify which selector your sending platform actually uses. Refer to your ESP’s official documentation (e.g., SendGrid, Mailchimp, Amazon SES) to find the active s= value. Some providers update selectors over time—using the old one triggers a selector not found error. If unsure, check your DNS history or contact support.
  3. Remove all but one valid DKIM record. Delete all other DKIM TXT entries that don’t match your current sending setup. Keep only the record that includes the s= selector used by your active email platform. Multiple valid selectors are technically allowed by RFC 6376, but only if they are all in use—the rest cause ambiguity and increase the risk of validation failure.
  4. Keep only the selectors actively used—label them clearly. If your domain sends through multiple services (e.g., marketing via Klaviyo, transactional via SendGrid), maintain separate DKIM records *only* if each uses a unique, active s= tag. Otherwise, consolidate to a single, valid record per service. Use clear naming in your internal documentation to avoid confusion.
  5. Verify the final record resolves correctly. After changes, test across multiple public DNS resolvers (like Cloudflare or OpenDNS). Use Google’s DNS checker or MXToolbox to confirm the remaining record appears and resolves as expected. Wait 5–10 minutes for propagation.

Why this matters

Having multiple DKIM records with conflicting or unused s= selectors confuses receiving mail servers. They expect a single valid selector for a given domain and sending service. When the s= value is missing or mismatched, authentication fails—even if the signature itself is correct—leading to bounces, spam filtering, or rejection. Keeping only active, correctly labeled records reduces risk and improves alignment with industry standards.

Fixing this issue is fast and prevents long-term deliverability harm. If you're unsure about your current setup, use MailTester's inbox placement testing to verify the impact of your DNS changes before going live with campaigns.

Why you need real-time verification after correcting DKIM

Fixing a domain TXT record with multiple DKIM entries is just step one. Even with a correct s= selector and valid DKIM signatures, your emails may still fail to land in inboxes. Sender reputation, list quality, and real-world deliverability factors matter just as much. A DNS fix doesn’t guarantee inbox placement—only real testing does.

Authentication isn’t enough

Just because your DKIM and SPF are technically correct doesn’t mean your messages will reach the inbox. ISPs like Gmail and Outlook use a wide range of signals beyond syntax checks—including historical engagement, complaint rates, and sender reputation. A clean DNS config is necessary, but not sufficient.

Even if your domain signs emails properly, poor list hygiene can sink delivery. Lists with disposable email addresses, role accounts (like postmaster@ or support@), or invalid formats are often blocked or marked as spam, regardless of authentication. These patterns signal low-quality outreach, even if the technical setup is perfect.

Test with real inboxes

Let’s be clear: no configuration checker or DNS validator can tell you if your email actually lands in a real Gmail, Outlook, or Apple inbox. That only comes from sending real test messages to known, live accounts.

MailTester’s inbox-placement test sends messages through actual provider inboxes—Gmail, Outlook, Apple, and others—to reveal delivery gaps. It shows whether your message lands in the inbox, spam folder, or is blocked entirely. This reveals if a corrected DKIM setup actually improved deliverability, or if other issues (like a bad sender reputation or a low-quality list) are still holding things back.

Most DNS tools stop at “valid syntax.” Real deliverability testing goes further. Use MailTester’s inbox placement test to send verified emails to real inboxes and see exactly where they land. It’s the only way to confirm your fixes worked in the real world.

How MailTester helps prevent DKIM and delivery issues

When your domain’s TXT record contains multiple DKIM entries with conflicting or missing selectors (like s=), email providers can fail to verify your messages, leading to delivery failures. MailTester catches these issues early by validating DNS, inbox status, and domain health before you send. You avoid bounces and sender reputation damage by ensuring only valid emails are delivered.

Prevent delivery fails with intelligent list cleansing

  • Use bulk email verification to scan entire lists for invalid, disposable, or role-based addresses before sending. This reduces bounce rates and protects your sender reputation.
  • Our real-time API checks individual addresses instantly, verifying not just syntax but also active MX records, domain existence, and whether the inbox is accepting mail — no false positives from passive DNS checks.
  • With 98.9% accuracy — validated against known deliverability benchmarks — you can rely on results to clean your list without guesswork or over-filtering.
  • Don’t just check DNS. Test inbox placement across Gmail, Outlook, Apple Mail, and other top providers. This confirms your message actually lands in the inbox, not spam or quarantine, even if the domain looks clean.

Go beyond DNS to catch hidden delivery risks

DNS-only checks miss real-world issues. For example, a domain may have multiple DKIM records with mismatched selectors (like s=selector1 and s=selector2), which is a common cause of SPF/DKIM alignment failures. The sender’s identity gets lost, and providers reject the message. This isn't a "valid" domain — it’s a misconfigured one.

MailTester detects such flaws early by testing the full delivery path, not just DNS records. We simulate actual inbound delivery and evaluate how mail is treated based on real provider policies, as documented in RFC 7671 and industry standards from organizations like Spamhaus and RFC Editor.

Let’s say you send to a domain with multiple DKIM records but no s= selector. Even if the domain exists and the MX is open, the message may be rejected. MailTester flags this before you send — so you avoid the risk of a delivery outage caused by poor selector alignment.

Use the real-time API to verify addresses programmatically in your workflow. Or check single addresses with our email checker to test a suspected bounce. The goal is simple: send only to confirmed, deliverable addresses — and avoid ever sending to a domain with a broken or conflicting DKIM setup.

Common pitfalls when fixing DKIM records

If your domain's TXT record has multiple DKIM entries, the s= selector might not be found because DNS queries look for a single, correctly formatted record matching the selector. Having outdated, conflicting, or improperly formatted entries—especially when they all appear under the same domain—can cause email providers to reject messages even if the DKIM key is technically valid. This breaks authentication and hurts inbox placement.

Leftover records from old setups

You might update your DKIM record but forget to remove the old one. DNS doesn’t automatically replace entries; it stores all TXT records. If an old selector like s=2021 remains alongside a new one like s=2024, some email systems may not know which to use—or fail to find the one your sending system expects. This can cause silent failures in authentication.

Assuming multiple selectors are safe

Multiple DKIM selectors aren't inherently redundant. They only work if each is explicitly managed and correctly published. If you add a new selector without removing the old one, or if the new one is misformatted, mail servers may fail to verify messages. The DMARC specification says that each selector must resolve to a valid public key—any failure breaks alignment. RFC 6376 outlines how domain owners must handle selector resolution and authentication chain requirements.

Using tools that don’t audit all selectors is a common blind spot. Some DNS checkers only verify the most recent record or skip parsing of the s= parameter entirely. This means you might think your DKIM is set up right when it's actually flawed for some senders. Always use a tool that checks all selector values and validates the full record structure.

And yes, you can test this in production. But skipping testing in real environments—especially during a transition—means you’ll only find out when emails fail to deliver. Use inbox placement test tools to validate actual delivery behavior before going live. For example, MailTester’s inbox placement tool lets you send test messages from real domains and see how well they land in inboxes across major providers.

When to re-check your DKIM setup after other changes

If you’ve switched ESPs, migrated your email system, or updated SSL certificates, your DKIM records may now be inconsistent or misconfigured—especially if multiple s= selectors exist. A single DKIM entry should match the selector in your outbound headers. Misalignment leads to “s= selector not found” errors, which block email delivery. Test your setup before sending large volumes.

When to double-check your DKIM after system changes

  • After switching to a new ESP (like moving from SendGrid to Mailchimp), verify that the new platform’s DKIM selector matches your DNS record—and only one valid s= entry exists.
  • When migrating email systems (e.g. from on-premise to cloud), ensure old DKIM keys are removed and new ones are properly published in DNS without overlap.
  • Following a domain migration or SSL certificate renewal, confirm DKIM records haven’t been lost, altered, or duplicated during DNS transfer.
  • If you've added a new sender (e.g. a CRM or newsletter tool), validate that its DKIM selector is correct and that no conflicting entries exist in your TXT records.
  • After noticing a sudden spike in hard bounces or delivery rate drops, inspect DNS records using tools like MxToolbox or RFC-compliant DNS checks to rule out DKIM failures.

Proactive verification before high-volume sends

Let’s face it—launching a campaign without checking DNS alignment is like flying blind. Even with proper SPF and DMARC, a mismatched or duplicated DKIM selector breaks authentication. Use inbox placement testing to simulate real-world delivery and catch issues before your list goes live.

When troubleshooting, remember: a valid DKIM signature requires both the correct selector in the header (e.g., s=2024) and a corresponding DNS TXT record with that exact s= tag. The same selector can’t appear twice with different values—only one valid DKIM key per selector should exist.

“Proper DKIM alignment reduces email rejection rates by ensuring cryptographic proof of legitimacy.” — RFC 6376

Before a major send, run a full list through MailTester’s bulk verification. It checks DKIM, MX, syntax, and deliverability in under 10 seconds per address. It won’t fix your DNS, but it will tell you when you *must* fix it.

You’re not done after fixing DNS: ensure full deliverability

Fixing a domain TXT record with multiple DKIM entries is essential, but it’s only one part of email deliverability. SPF, DKIM, and DMARC must all be correctly configured and aligned to avoid authentication failures.

Align your authentication stack

Even with correct DKIM selectors, misconfigured DMARC policies can still block legitimate messages. Overly strict policies without a reasonable quarantine or monitoring phase risk losing valid mail. Monitor DMARC reports to adjust policies safely.

  • Use MailTester’s list hygiene tools to filter out role addresses (e.g. admin@, sales@) and disposable domains that harm sender reputation.
  • Bulk verification helps remove invalid or risky recipients before sending.
  • Consistently maintaining a clean send list improves inbox placement and reduces the risk of being flagged or blocklisted.

Real-time verification and inbox placement testing help you validate the entire email journey — from DNS alignment to final delivery.

Sources

Keep reading

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

Frequently asked questions

Can multiple DKIM records be valid?

Yes, but only if each uses a unique selector (s=) and is tied to a specific sending service. Mismanaged duplicates cause validation failures.

What does 's= selector not found' mean?

The receiving server cannot locate a DKIM record with the selector specified in the email’s signature, failing authentication.

How do I know which DKIM selector my sending service uses?

Check your ESP’s documentation or dashboard. The selector is typically displayed in the DKIM settings section.

Should I remove old DKIM records?

Yes — keep only active, correct selectors. Unused records cause ambiguity and increase the risk of failure.

Does a single failed DKIM test block all emails?

No — but it weakens sender reputation and increases the chance of messages being marked as spam or rejected.

How often should I audit my DKIM setup?

At least quarterly, and always before major campaigns or infrastructure changes.

Can a catch-all email cause DKIM issues?

Only indirectly. Catch-alls are not related to DKIM configuration, but they often signal poor list hygiene, which harms deliverability.

Do I need to verify DKIM with every email provider?

No — but you should test deliverability across leading providers like Gmail, Outlook, and Apple Mail using inbox placement tools.

What happens if I edit my DNS record incorrectly?

DNS changes can take up to 48 hours to propagate, and errors may cause emails to stop delivering entirely until corrected.

Can MailTester help with DKIM verification?

Not directly, but it helps by testing deliverability after your DNS is fixed. Use its inbox-placement tests to confirm email success.

Are disposable domains harmful to DKIM?

Disposables don’t affect DKIM directly, but they harm deliverability and sender reputation when included in lists.

Does SPF conflict with multiple DKIM entries?

SPF doesn’t use selectors, but a misconfigured SPF record can cause authentication overlap. Ensure SPF, DKIM, and DMARC are all properly aligned.