Why does DKIM s= selector case sensitivity matter in Exim?

You spent hours hardening your mail server. SPF, DKIM, DMARC—all set. But your emails still vanish into spam folders. You check the logs, the DNS records, the headers—everything looks correct. Then you notice: a single capital letter in the DKIM selector is breaking everything.

DKIM uses a selector—the value after s= in a DKIM signature—to locate the matching public key in DNS. In Exim, unlike some modern MTAs, that selector is case-sensitive. So s=alpha and s=Alpha are not the same. A mismatch between the signature and the DNS record means verification fails, and ISPs treat that as a red flag. This is why DKIM s= selector case sensitivity in open-source MTAs like Exim matters—when it’s wrong, your deliverability pays the price.

Key takeaways

  • Exim treats DKIM selectors as case-sensitive, meaning 's=alpha' and 's=Alpha' are distinct records.
  • A mismatch between the DKIM signature selector and the DNS record leads to verification failure, triggering spam filters.
  • This issue commonly arises during migrations or when managing legacy mail infrastructure with older Exim configurations.

How do open-source MTAs like Exim handle DKIM selectors?

Exim processes DKIM selectors exactly as defined in RFC 6376: it uses the full, unaltered case of the selector from the DKIM-Signature header to look up the corresponding DNS record. Unlike some commercial MTAs, Exim does not normalize case—uppercase, lowercase, or mixed case selectors are treated as distinct and preserved during DNS lookup. This behavior follows DNS standards, where label names are case-insensitive, but the selector string itself is a literal match in the signature.

Case sensitivity is preserved—no normalization

When Exim receives a DKIM-signed message, it extracts the selector field exactly as written in the DKIM-Signature header, including its case. For example, a selector like mail-tester is not converted to MAIL-TESTER or Mail-Tester before DNS lookup. This means if your DNS record is published under mail-tester, a signature using Mails-Tester will fail validation.

This strict adherence to case is intentional. RFC 6376 specifies that the selector is a string literal, and the DNS lookup must match it exactly. While DNS labels are technically case-insensitive, the selector is part of a header value, not a domain name. Exim treats it as a string, not a label, so case differences are meaningful.

Why this matters for deliverability

Misconfigured case in DKIM selectors is a common source of delivery failures, especially in open-source setups where administrators may not realize the importance of exact matching. If your MTA uses a selector with mixed case but your DNS record uses lowercase, the signature will fail verification—regardless of proper DNS publishing.

Tools like MailTester can help catch these issues early. Its bulk verification service checks not only email syntax but also checks for common issues like DKIM misconfiguration during domain-level validation. This ensures that your email campaigns avoid unnecessary bounces or spam filtering due to signature errors.

For system administrators, understanding that Exim doesn’t normalize case is critical when setting up DKIM records. Double-check the exact selector name in your DKIM-Signature header and ensure your DNS TXT record reflects it perfectly—no shortcuts, no automatic corrections.

For more reference, the canonical source is RFC 6376, Section 3.5, which defines the DKIM-Signature header format and explicitly states that the selector component is used as-is. This behavior is consistent across compliant MTAs, but Exim’s transparent, no-normalization approach makes it especially important to verify exact match.

What happens when a DKIM selector case doesn’t match?

You’ll get a DKIM signature verification failure if the selector case in your DKIM header doesn’t exactly match the TXT record in DNS. Receiving servers look up the public key using the selector as-is, including uppercase and lowercase letters. If no DNS record exists with that exact case, the server can’t validate the signature, and your email may be treated as untrusted—leading to rejection, spam marking, or delivery failure, especially with strict receivers like Gmail or Yahoo.

Case sensitivity isn’t a suggestion—it’s enforced by design

DKIM uses DNS to store public keys, and DNS lookup behavior is exact. A selector like mail1 is not the same as Mail1 or MAIL1. The receiving server queries the TXT record under mail1._domainkey.example.com—not MAIL1._domainkey.example.com. If the record doesn’t exist with that precise case, the signature check fails immediately. This is defined in RFC 6376, Section 4.5, which states that the selector is an exact string match.

Let’s say you generated a DKIM key with a selector in lowercase, but your mail server or MTA (like Exim) accidentally used uppercase when signing. The receiving server will look for a TXT record with that uppercase form—and find nothing. No match, no verification. The result? A failed DKIM check, which can severely hurt sender reputation, especially if it happens often across a mailing list.

Why this matters in practice

Open-source MTAs like Exim don’t automatically normalize selector cases. They use the selector exactly as configured. So if your DKIM signing process is inconsistent—or if you’re using multiple MTAs with different config styles—you may accidentally introduce case mismatches. This isn’t a rare issue. It’s one of the top pitfalls in DKIM implementation, especially when managing bulk email systems with automated key rotation.

Even one malformed DKIM signature can trigger filters at major providers. Gmail and Microsoft’s spam engines treat missing or failed DKIM as a red flag, particularly when combined with other weak signals like poor engagement or poor list hygiene. Without verification, you’re sending blind.

That’s where tools like MailTester’s bulk verification help—you can identify invalid or poorly structured email addresses before sending, reducing the risk of DKIM-related delivery failure across your list. It checks both syntax and real-world deliverability, including how likely a recipient is to accept your message, even if the DKIM setup is technically correct.

How to verify if your Exim DKIM selector is case-sensitive and correct?

You must check the case of your DKIM selector exactly as it appears in the DKIM-Signature header of a signed message and verify that the TXT record at <selector>.<domain>.txt matches it letter-for-letter. Even small case mismatches break DKIM validation. Use the raw message and DNS tools to confirm alignment.

Step-by-step verification process

  1. Retrieve a signed message from your Exim MTA. Enable full header logging or export the raw message from the recipient's inbox. This gives you the complete DKIM-Signature header, which is essential for verification.
  2. Locate the DKIM-Signature: header in the message and copy the exact value of the s= tag, including all capital and lowercase letters. For example, if the header says s=mail, it must be queried as mail.example.com.txt—not Mail.example.com.txt.
  3. Use a DNS lookup tool like dig or nslookup to query the TXT record at <selector>.<domain>.txt, exactly matching the case from the header. A mismatch in case will return no record or a different one, causing DKIM failures.
  4. Confirm the DNS record exists and contains the correct public key. If the selector is case-sensitive and your DNS record uses a different case, DKIM fails during validation—even if the key is correct otherwise. This is confirmed by RFC 6376, which specifies case sensitivity in domain identifiers.
  5. Test the result with a third-party DKIM validator or check tools like MXToolbox or DMARC Analyzer, both trusted resources for domain authentication checks.

Why Exim behavior matters

Exim, like most open-source MTAs, doesn't enforce case standardization on DKIM selectors by default. The selector name is treated as a literal string, so mail and Mail are different TXT records. This means a typo in capitalization during DNS setup can silently break authentication.

Many administrators assume selectors are case-insensitive. They’re not—especially in systems where mail is routed through multiple MTAs or intermediaries. Always treat the selector as case-sensitive until proven otherwise. Use a mail log or a delivered message to verify the exact spelling in use.

If your DKIM check fails and the key is present, this is one of the most common causes. Double-check the selector case in the DNS TXT record against the one in the DKIM-Signature header. It’s a simple fix with a major impact.

How to prevent DKIM selector mismatches in Exim environments?

You can prevent DKIM selector mismatches in Exim by always using lowercase selectors (like s=mail) consistently across all signing configurations. A single uppercase letter—such as s=Mail—can break validation, even if your DNS record is correct. This issue is well-documented in RFC 6376, which specifies that selectors are case-sensitive, but many implementations, especially in open-source MTAs, expect consistent casing. Let’s walk through how to avoid this common misconfiguration.

Enforce lowercase selectors by design

  • Standardize on lowercase selectors across all your signing configurations—use s=mail, s=auth, or another consistently lowercase value.
  • Check all Exim configuration files, especially the dkim_sign and dkim_domains sections, for hard-coded or script-generated uppercase values.
  • Use a shared config template or configuration management tool to ensure uniformity across servers and domains.

Validate DNS records and monitor changes

  • After updating DKIM keys or changing selectors, verify the DNS TXT record using a tool like MxToolbox to confirm the exact selector and key value are present and correctly formatted.
  • Document each DKIM key pair, domain, and selector in your internal system—especially during migrations or MTA upgrades.
  • Automate real-time validation of DNS records using an email verification API like MailTester’s Email Verification API, which can test domain-level DKIM configuration as part of a broader deliverability check.
Even a single mismatched capital letter in a DKIM selector can result in failed authentication, leading to messages marked as spam or rejected outright.

Consider that DKIM failure rates in email streams often spike after infrastructure changes. A well-documented and consistently applied selector policy reduces the risk of undetected misconfigurations. You’re not just protecting your authentication—your sender reputation.

How does MailTester help verify DKIM-affected deliverability issues?

You can catch DKIM-related deliverability risks early by using MailTester’s email-verification API, which checks not just syntax and validity but also whether an address’s domain has a properly configured DKIM record. It flags missing, mismatched, or weak DKIM configurations during bulk list checks, identifying domains where sender reputation may already be compromised. This lets you avoid sending to addresses tied to domains with authentication flaws before they harm your deliverability.

Why DKIM configuration matters before sending

DKIM is not optional. It’s a core part of email authentication. When a domain doesn’t publish a valid DKIM record, or when the selector (like s=) is incorrectly formatted — especially in open-source MTAs like Exim where the s= selector is case-sensitive — the signature fails validation, and emails are more likely to be marked as spam or rejected entirely.

MailTester doesn’t just check the format of an email address. It performs a real-time validation that includes checking DNS records for common misconfigurations, including the case sensitivity of the s= selector. This is critical because while RFC 6376 allows for case-sensitive selectors, some older or poorly configured mail servers treat them as insensitive, leading to inconsistent validation outcomes.

Spotting risks before you send

When you run a bulk list verification via the MailTester bulk verification tool, the system analyzes the target domain’s DNS records. It flags domains with no DKIM record, a poorly formed one, or one that doesn’t match the header signature — which can happen due to case mismatches in the s= selector or incorrect key placement.

These flags help you identify risky senders before you hit send. For example, if your list includes addresses from a domain with a weak or misconfigured DKIM setup, you’re not just risking bounces — you’re risking your own sender reputation. According to an analysis by the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), improperly configured DKIM is one of the top reasons for email rejection by major ISPs.

By integrating MailTester’s API or using the real-time verification API, you can automate these checks in your onboarding, signup, or campaign workflows. This reduces the number of failed deliveries and protects your domain reputation by preventing sends to addresses tied to domains with weak authentication — including those with case-sensitive selector issues in Exim or similar MTAs.

DKIM is not a feature you can ignore. MailTester makes it easier to verify that your senders and your recipients are on authenticated domains — before the first email hits an inbox.

What role does inbox placement testing play in DKIM validation?

DKIM validation isn’t just about signing a message correctly—it’s about ensuring that signature passes real-world delivery checks across major email providers. Even with a technically valid DKIM signature, inbox placement can fail if authentication policies are inconsistent across your infrastructure. MailTester’s inbox placement testing simulates delivery to Gmail, Outlook, and Apple Mail to catch these real-world misfires, including issues like case-sensitive s= selectors in open-source MTAs like Exim that break alignment.

How real-world delivery reveals hidden DKIM issues

Many MTAs, including Exim, treat the s= selector in DKIM signatures as case-sensitive. A mismatch—like sending s=mail when the DNS TXT record uses s=Mail—can cause rejection even if the rest of the signature is correct. This is rare in theory but common in practice, especially in legacy or misconfigured systems.

Testing in isolation, such as with SPF or DNS checks, doesn’t catch this. You need to simulate actual delivery to see if your DKIM setup holds under real filtering rules. Inbox placement testing with MailTester runs your email through a network of live providers, revealing whether subtle errors—in case, alignment, or policy—lead to delivery failure or being moved to spam.

Why consistency matters across your stack

Email delivery is a chain of checks. SPF and DMARC rely on domain consistency; DKIM depends on both DNS record accuracy and MTA implementation. When your MTA uses a case-sensitive selector, and your DNS record doesn’t match exactly, the signature fails—even after a clean send. Tools that only check DNS or syntactic correctness won’t catch this unless they simulate real inbox behavior.

MailTester’s inbox placement tester validates your full setup against actual provider algorithms. It doesn’t just test if DKIM signs—it checks if that signature survives in Gmail, Outlook, or Apple Mail’s inbox. This includes alignment checks, policy compliance, and edge cases like case sensitivity in s= selectors.

For teams using open-source MTAs like Exim or Dovecot, this layer of testing is critical. It exposes configuration drift before it causes mass bounces or reputation damage. Run these tests before sending to live lists—use MailTester’s inbox placement tester to validate your authentication setup across real infrastructure.

Common pitfalls when managing DKIM in Exim with case sensitivity

You’re checking DKIM records in DNS and assuming case doesn’t matter—except it does, specifically in the s= selector within the DKIM-Signature header. While DNS labels are case-insensitive per RFC 4343, the selector itself is treated as case-sensitive by mail servers. Misconfigurations here lead to failed authentication, even if your DNS looks correct. Let’s break down what goes wrong and how to fix it.

Why the selector case matters in practice

  • Even small inconsistencies like s=mail vs s=Mail in the header versus DNS can cause DKIM validation to fail.
  • Many open-source MTAs like Exim rely on exact case matching—there’s no automatic normalization.
  • Check the raw headers of incoming mail: if the s= value doesn’t match your DNS TXT record exactly, DKIM fails—no exceptions.

How to avoid common missteps

  • Don’t assume DNS lookup results are case-insensitive—verify the exact formatting in your email headers and DNS records.
  • If you’re migrating from another system, don’t assume a reused selector (e.g., s=legacy) is still valid: confirm its case and value in both your configuration and DNS.
  • After updating Exim’s DKIM settings, verify that the DNS TXT record reflects the new selector case—old records persist and can override the new one.
  • Use tools like MXToolbox’s DKIM Lookup to validate real-world behavior and catch case mismatches early.
  • Test with actual email delivery or use inbox placement testing to simulate real-world validation, since some servers reject mail with DKIM signature issues even if the DNS is otherwise correct.

It’s not enough to know your DNS record exists—its exact case must be mirrored in the message header. A single mismatch breaks authentication. Before sending to real users, verify your DKIM setup with tools that show exactly what gets delivered. For example, use MailTester’s inbox placement test to see how your authenticated email is received across real inboxes and check for authentication failures.

How do real-world senders handle DKIM selector issues?

High-volume senders handle DKIM selector case sensitivity in open-source MTAs like Exim by automating DNS and authentication checks, validating DKIM alignment before every send, and testing inbox placement in real time. They don’t rely on memory or guesswork—they build verification into their workflows.

Automated validation catches misconfigurations early

You don’t need to guess whether a DKIM selector’s case matters. Real-world teams using MTAs like Exim run automated checks across their domains, scanning DNS records for consistency in selector names and alignment. Case sensitivity can break DKIM, especially when tools or libraries default to lowercase, but automated validation stops issues before they cause bounces or deliverability drop-offs.

For example, a selector like s=mail must match exactly in DNS—s=Mail or s=MAIL will fail. Tools that scan for this sort of mismatch help teams spot and fix broken configurations across large domains, often before they send anything at all.

Integrate verification to prevent bad sends

Many senders now integrate email verification APIs into their workflows. This isn’t just about syntax—it’s about catching domains with broken DKIM, invalid MX records, or unauthenticated setups before data leaves the system.

With tools like the MailTester API, teams verify individual addresses in real time during list uploads or API calls, checking for active, deliverable, and properly authenticated inboxes. This catches issues like malformed DKIM setups that would otherwise result in failed authentication and dropped messages.

Let’s be clear: no amount of manual review beats an integrated check. Every sender pushing thousands of messages per minute depends on this automation. As per the DKIM specification (RFC 6376), the selector must match exactly—case sensitivity is intentional. Real-world systems don’t ignore that; they validate it relentlessly.

Why is consistency in DKIM selectors critical for sender reputation?

DNS-based Authentication of Mail (DKIM) must be applied consistently across all domains and messages, including strict case sensitivity in selectors like s=. A mismatch—like using s=main in one message and s=MAIN in another—breaks verification, leading to failed authentication. Email providers treat such inconsistencies as signs of poor configuration, reducing trust and harming sender reputation over time.

Authentication signals shape inbox placement

Email providers like Gmail, Outlook, and Apple Mail rely on multiple signals to decide whether to deliver your message to the inbox or the spam folder. Consistent authentication—especially DKIM, SPF, and DMARC—acts as a baseline indicator of legitimacy. When you use different case variants of the same DKIM selector across messages, you create a pattern of failure, even if the underlying key is correct.

Let’s say your MTA (like Exim) generates a DKIM signature with s=main but later sends another with s=Main. Even though both point to the same DNS record, the uppercase/lowercase difference means the provider can’t find a matching selector. This isn’t a technical flaw in the key—it’s a configuration error rooted in mismanagement. Repeated failures like this signal to providers that your sending infrastructure isn’t reliable, even if only one byte differs.

Open-source MTAs such as Exim handle DKIM signing based on precise string matching. The s= selector is case-sensitive by design, per RFC 6376. That means even a single capitalization difference breaks the chain. It’s not about encryption strength. It’s about predictable, repeatable behavior. When you send 1,000 emails and five fail due to case mismatches, that’s five points lost on your sender reputation score.

Consistency starts with process, not just code

DKIM selector mismatches often stem from inconsistent configuration practices—like hardcoding selectors in scripts without standardizing names, or using templates that mutate case during variable substitution. These aren’t edge cases. They’re common in poorly monitored environments.

Tools like MailTester’s real-time email checker help you catch these problems early by validating the full DKIM header before sending. You can test individual addresses and verify that your headers align with expected values across domains. For bulk lists, use bulk verification to check your mailing list for addresses with malformed or inconsistent authentication headers.

Ultimately, inbox placement isn’t just about content or frequency. It’s about reliability. A consistent, predictable DKIM setup signals that you manage your infrastructure responsibly. That trust is earned through technical precision—starting with proper case handling in s= selectors.

Check your DKIM configuration today—before your emails get blocked

Even minor errors like case sensitivity in the DKIM s= selector can trigger authentication failures. Each failure impacts your sender reputation, even if only temporarily.

Open-source MTAs like Exim are sensitive to these details. Without real-world verification, misconfigurations go unnoticed until delivery drops or emails are blocked.

Verify and test before sending

Use MailTester to catch DKIM mismatches early. Its real-time API checks domains and validates configurations at scale.

Testing across real inboxes reveals issues invisible to basic tools. With 98.9% accuracy, MailTester helps avoid bounces, blocklists, and long-term reputation damage.

Sources

Keep reading

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

Frequently asked questions

Is the DKIM s= selector case-sensitive in Exim?

Yes, Exim treats the DKIM selector in the signature header as case-sensitive. The DNS TXT record must match the exact case used in the signature.

What happens if the DKIM selector case doesn’t match DNS?

The signature verification fails, which can lead to email rejection or spam filtering, especially with strict providers like Gmail.

How can I test if my DKIM selector is correct in Exim?

Extract the DKIM-Signature header from a sent message and query the DNS TXT record using the exact selector, including case, with tools like dig or nslookup.

What is a good strategy for managing DKIM selectors in Exim?

Use lowercase selectors consistently and validate every update against DNS to ensure the record matches the signature exactly.

Does MailTester detect DKIM selector mismatches?

Yes, MailTester identifies domains with missing or incorrect DKIM configurations during bulk verification and inbox placement testing.

Can a case-sensitive DKIM issue lead to blocklist placement?

Directly, no—but repeated authentication failures from misconfigurations can contribute to a poor sender reputation, increasing blocklist risk.

How can I use MailTester to test DKIM settings?

Submit a list of domains via the Email Verification API or run inbox placement tests to assess how mail performs with real providers.

Do other MTAs handle DKIM selectors differently than Exim?

Most modern MTAs follow RFC 6376 strictly, treating selector case as significant. However, some platforms normalize or cache values, leading to inconsistent behavior.

Are there tools to automatically detect DKIM selector issues?

Yes—tools like MailTester, MxToolbox, and Spamhaus offer checks for DNS records and DKIM alignment, with MailTester providing API access for automation.

Can I fix DKIM issues without changing Exim config?

Only if you adjust the DNS record to match the selector case in the DKIM-Signature header. You cannot bypass case sensitivity through configuration alone.

What’s the best practice for DKIM in open-source MTAs?

Use consistent lowercase selectors, verify DNS records match the header exactly, and audit configurations regularly using automated email verification tools.

Is DNS case-insensitive a reason to ignore selector case?

No—while DNS labels are case-insensitive, the DKIM-Signature header is not. The case of the selector matters in the header and must match DNS exactly.