Case-Sensitive TXT Records & DKIM

Why does case sensitivity in TXT records matter for DKIM verification?

You’re running a bulk email verification check. The tool says "valid" — but the email fails delivery. No bounce, no error message. Just silence. The culprit might be something invisible: a capital letter in a DNS record.

DKIM uses TXT records to verify email integrity. These records are case-sensitive by design. A selector named 'selector1' won’t match 'Selector1' — even if the content is correct. This small mismatch breaks the chain of trust. Email verification software that doesn’t respect case sensitivity returns false negatives, wasting time and damaging sender reputation.

Key takeaways

DNS TXT records for DKIM are case-sensitive, meaning 'selector' and 'Selector' are treated as different entries.
Even a single capitalization mismatch between the expected selector and the DNS record can prevent a valid DKIM signature from being found.
Email verification software must perform case-sensitive DNS lookups to accurately assess DKIM validity and avoid false negatives.

How do mail servers interpret DKIM TXT records in practice?

DKIM validation fails if the TXT record name isn’t matched exactly—case matters even though DNS domain names are technically case-insensitive. A single capitalization mismatch between the expected selector and the actual DNS record breaks the lookup, leaving no way for the receiving server to verify the signature. This exact match requirement means even minor typos in the selector name render the entire verification process useless.

Case sensitivity in DNS TXT record lookups

While RFC 1035 states that domain names are case-insensitive, the same doesn’t apply to the content of TXT records, especially when they contain selectors. The DNS query for a DKIM TXT record follows the exact label format, including upper and lowercase letters. For instance, a selector named default won’t be found if an email system looks for Default. This exact-match lookup is how mail servers validate DKIM signatures in practice.

Let’s say your email software generates a DKIM signature using selector mailtester. If your DNS record is named mailtester._domainkey.example.com, but the actual record published is Mailtester._domainkey.example.com, the lookup fails. The receiving server sees no record with that exact label. This isn’t a configuration error—it’s an inherent quirk of how DNS resolves TXT records in the context of DKIM.

This means that case-sensitive issues aren’t just theoretical—they directly impact deliverability. If a sender’s DKIM selector isn’t published with exact case matching, the message will appear unsigned or invalid, regardless of whether the private key was correct. This is commonly seen in systems that auto-generate selectors from user inputs without preserving case.

Publisher tools like RFC 6376 (DKIM specification) and RFC 1035 confirm that DNS label matching is literal, and systems must handle case precisely. Many email platforms—especially those used in marketing automation—rely on accurate selector resolution to validate sending sources. A single mismatch can cause messages to be rejected or marked as spam.

If you’re debugging why DKIM checks fail during verification, ensure your TXT record name matches the selector exactly, including capitalization. You can test this in real time using MailTester’s inbox placement tool, which simulates real-world delivery and checks DKIM validation alongside spam filters, authentication, and routing.

What happens when email verification software misses case-sensitive DKIM selectors?

When email verification software fails to account for case-sensitive DKIM selectors, it may incorrectly flag a valid email as invalid or risky, simply because it didn’t match the exact case of the selector in the DNS TXT record. This oversight leads to higher false-positive rates, especially with domains that use non-standard casing (like selector1 instead of Selector1), and results in the suppression of deliverable addresses over time — degrading list hygiene and hurting deliverability.

Why case sensitivity matters in DNS TXT records

DNS is case-insensitive for domain names, but TXT record contents — including DKIM selectors — are strictly case-sensitive. A mismatch in capitalization between the software’s lookup and the actual record means the DKIM check fails, even if the email is deliverable. This is defined in RFC 6376, the standard for DKIM, which specifies that the selector must match exactly as published.

Let’s say your software looks up dkim._domainkey.example.com and finds a TXT record with selector1, but your test case uses Selector1. The comparison fails. The email isn’t invalid — the system is just using inconsistent casing.

The real-world consequences of missing case sensitivity

When a tool ignores this detail, you end up with lists that appear clean but actually exclude valid, engaged recipients. This isn’t just a technical hiccup — it directly impacts your sender reputation. Sending to a suppressed list (even one created by false positives) signals poor hygiene to inbox providers.

Over time, this leads to increased bounce rates and lower inbox placement, especially when using bulk sending platforms. The more often you exclude valid addresses due to a misread selector, the weaker your sender domain looks. A well-designed verification tool won’t miss these details — it’ll retrieve and compare the TXT record exactly as it exists, with full case preservation.

At MailTester, our verification process respects case sensitivity in DNS records. This means we don’t rely on assumptions — we validate the exact data returned from DNS. For developers, this means accurate real-time results via our verification API, and for marketers, it means cleaner lists through bulk verification with minimal false positives.

How does MailTester handle case sensitivity in DKIM selector resolution?

MailTester performs DNS lookups for DKIM records using exact case matching—no normalization, no adjustments. This strict adherence to DNS standards ensures that TXT record names like selector1._domainkey.example.com are queried exactly as written, preserving correctness in selector resolution. That precision is part of what enables MailTester’s 98.9% accuracy in email verification.

Why exact case matching matters in DKIM verification

DKIM relies on precise DNS record lookups. The selector name, part of the TXT record's DNS query, is case-sensitive. A mismatch—even in capitalization—can result in a failed verification, even if the underlying key is valid. MailTester avoids false positives by treating the query exactly as specified, aligning directly with RFC 1035 and RFC 6376, the foundational documents governing DNS and DKIM.

Many tools attempt to "fix" discrepancies by normalizing case, but this introduces risk. For instance, a selector like test._domainkey.example.com won’t resolve if the record is actually stored as Test._domainkey.example.com. Normalizing case can mask configuration errors, leading to unverified bounces or poor sender reputation signaling. MailTester rejects that shortcut.

Let's say your system generates a DKIM record with mixed case. MailTester checks it exactly as delivered—not altered, not corrected. If no matching TXT record exists, the result is flagged as invalid or missing, which is exactly what you want for accurate deliverability prediction. This applies to all verification workflows, whether you're doing batch list cleansing or real-time validation via our verification API.

Trust in the standard, not the workaround

Tools that auto-normalize TXT record case often assume that email servers treat selectors case-insensitively. But they don’t—the entire lookup process is case-sensitive at the DNS layer. The DNS specification explicitly requires case sensitivity for domain names, including subdomains and record names.

MailTester respects that. It doesn’t guess. It doesn’t assume. It queries the DNS exactly as it is presented, ensuring that every result reflects the actual configuration. This consistency means you can trust your verification output, whether you’re testing inbox placement with our inbox tester or validating thousands of addresses in bulk with bulk verification.

Accuracy isn’t about guesswork. It’s about precision. And strict case matching in DKIM selector resolution is a critical part of that precision.

A real-world example: a case-sensitive DKIM failure in a bulk send

You're verifying email addresses to ensure deliverability, but a valid address bounces due to a case mismatch in a DKIM selector. The software assumed the selector was case-insensitive, but DNS TXT records are case-sensitive. The tool looked for 'DMARC' while the record used 'dmarc', causing a failed signature validation that was misreported as 'invalid'. This oversight led to unnecessary list cleanup and wasted sends.

How the failure happened step by step

Start with a valid email address — [email protected]. It’s on a known list, well-formed, and passes basic syntax checks. You’d expect delivery to proceed.
Check DKIM configuration — your email system signs messages using a selector named 'dmarc'. The TXT record is published correctly on the DNS: selector._domainkey.domain.com. IN TXT "v=DKIM1; k=rsa; p=...". The value is lowercase.
Verification software queries DNS — the tool looks up the TXT record for dmarc._domainkey.domain.com. It assumes case doesn't matter, so it retrieves the dmarc record.
Software incorrectly queries in uppercase — due to an internal bug or misconfiguration, the query is made for DMARC._domainkey.domain.com. DNS treats this as a different record.
DMARC record not found — the DNS returns no match. The software concludes the selector is invalid or non-existent, triggering a hard bounce.
Result: false negative — the original address is valid. The bounce was caused by a case sensitivity error in the verification tool, not the email itself. It was logged as 'invalid', leading to cleanup of a good address.

Why this matters in real email operations

Case sensitivity in DNS is defined in RFC 1035, which states that domain names are case-insensitive, but label names in TXT records are not inherently tied to that. The actual query, especially when automated, can fail silently if the tool doesn't handle casing correctly.

The 6 steps described in “How the failure happened step by step”, in order.

This mistake wasn’t in your infrastructure. It was in the tool you trusted to validate your list. The result? A false positive on deliverability, wasted verification credits, and a damaged sender reputation because real user emails were incorrectly flagged.

MailTester’s verification process respects DNS specifications. Our API and bulk checker handle TXT record lookups with full case fidelity. You can verify entire lists with 98.9% accuracy, and our real-time API ensures your sender side is aligned with mail server expectations.

You might assume DKIM selector resolution is straightforward, but case sensitivity in TXT records often breaks it. Many verification tools treat DNS lookups as case-insensitive, but RFC 1035 and real-world DNS behavior show that labels are case-sensitive. A selector like 'S1' won't resolve if the DNS record is stored as 's1'. This mismatch leads to false invalid results, especially with dynamic or non-standard selectors. Always validate selector casing at the DNS level before trusting verification outcomes.

Why mixed-case selectors cause unexpected failures

DKIM selectors such as 's1', 'S2', or 'Dkim2' are often stored inconsistently; the DNS lookup must match the case exactly, even if the tool assumes otherwise.
Some email verification tools perform DNS queries without preserving case, leading to a failed lookup when the actual record is in lowercase or mixed case.
Dynamic selector generation (e.g., timestamp-based or UUID-backed) often produces non-standard capitalization that isn't accounted for in verification workflows.
Mail servers and DNS resolvers treat domain labels as case-sensitive, per RFC 1035, so mismatched case will always result in a DNS record not found error.

How verification tools misrepresent results due to this mismatch

Tools that normalize case during DNS lookups may report a valid DKIM record when no such record exists with the correct casing.
Even if the selector's content is valid, a case mismatch results in a failed signature check during email delivery — a red flag that shouldn't be masked by the tool.
Some services claim high accuracy but ignore case sensitivity, leading to undetected risks in senders who rely on automated verification to avoid bounces.
Using real-world DNS querying — not just cache-based or pre-normalized results — ensures the validation reflects actual deployment behavior.

Let’s be clear: if your verification tool doesn't account for the exact casing of a DKIM selector, it's producing false confidence. You’re not testing the real email delivery path — you’re testing a hypothetical. To verify DNS records correctly, use a tool that queries the actual DNS hierarchy with proper case handling.

How do other email verification tools handle case sensitivity?

Most email verification tools perform DNS lookups for DKIM records but don't publicly disclose how they handle case sensitivity in TXT record selectors. ZeroBounce, NeverBounce, Kickbox, Bouncer, Hunter, Emailable, and MillionVerifier either omit details or confirm only that they check DNS — not whether they enforce exact case matching. Only MailTester’s approach is transparent: it uses exact-case matching when resolving DKIM selectors, which aligns with RFC 6376’s specification.

Why this matters for verification accuracy

DKIM selectors are case-sensitive per the standard. A mismatch—like treating “s1” differently than “S1”—can cause false negatives or false positives during verification. If a tool normalizes case silently, it may pass a non-existent or invalid selector as valid. This skews accuracy, especially in high-volume list cleaning where even subtle errors accumulate.

Let’s say you’re verifying a list of 10,000 addresses with DKIM-enabled domains. If your tool performs case-insensitive TXT lookups, it might confirm a selector that doesn’t actually exist under the exact capitalization expected by the receiving server. That address appears valid in your list, but fails in production sends.

Opaque practices across competitors

ZeroBounce and NeverBounce perform DNS checks but don’t document their case handling. Kickbox and Bouncer offer TXT record lookups but lack detail on whether they enforce case sensitivity. Hunter, Emailable, and MillionVerifier provide verification services without confirming how they process selector case. Without public disclosures, users must assume these tools may normalize case by default—potentially masking issues or misrepresenting delivery readiness.

Only MailTester documents its behavior: it applies exact-case matching during TXT record resolution. This matches the actual technical requirements defined in RFC 6376, where DKIM selector names are case-sensitive strings. For teams requiring precise, standards-compliant validation, this transparency is a measurable advantage.

If you’re verifying large lists or debugging deliverability, using a tool that respects exact case ensures you’re not trusting false positives. You can test this behavior live with our email checker or integrate real-time verification via our verification API. For bulk lists, our bulk verification tool applies the same exact-case logic at scale.

Best practices to prevent DKIM resolution failures in verification

Case-sensitive TXT records are a common but often overlooked hurdle in DKIM selector resolution. If the selector name in the DKIM signature doesn’t match the DNS TXT record’s exact case, verification fails—even if the content is correct. You can prevent this by validating the full case-sensitive record using tools that don’t normalize case, ensuring your email verification software checks records as they exist in DNS.

Use DNS tools that preserve case sensitivity

Run lookups with MxToolbox or dig and check the exact case of the DKIM selector in the record—e.g., selector1._domainkey.example.com must match exactly.
Never assume DNS tools normalize case; many do, which can hide real mismatches. Use command-line tools like dig TXT selector1._domainkey.example.com to see raw output without adjustment.
Validate using multiple DNS resolvers to confirm consistency—discrepancies can indicate configuration drift or caching issues.

Verify your verification software’s handling of case

Ensure your email verification tool performs exact-case matching on TXT records, not normalized or lowercase-only comparisons.
Check whether your tool treats selector names as case-sensitive by default—some systems auto-lowercase them, which breaks DKIM resolution.
Use MailTester’s bulk verification to test your list with full DNS validation, including case-sensitive DKIM checks, and review logs for DKIM validation failed entries.
If you see repeated DKIM failures, audit the raw DNS records and compare them to how the tool resolves the selector—case mismatches are a frequent root cause.

DKIM validation fails not because the key is wrong, but because the selector name was entered with a lowercase 's' instead of uppercase 'S' in the DNS record.

Real case sensitivity doesn’t just matter in theory—it trips up thousands of senders each year. A verified, exact-match lookup is the only reliable check. For teams using MailTester, the in-app logs and deliverability reports make tracking these issues straightforward and actionable.

How MailTester’s verification process ensures reliability

MailTester checks DKIM selectors exactly as they appear in DNS—including case—without adjusting for common variations. This prevents false positives from case-insensitive lookups and aligns with DNS RFC standards. The result is a 98.9% accuracy rate in both bulk and real-time verification, because we treat every record name as written, not guessed.

Why exact case matters in DNS lookups

We query DNS using the full selector name with its original case—never lowercase, never uppercase, never standardized.
Even a single character mismatch due to case can make a record inaccessible, and we catch that.
DNS is case-sensitive by design, and our system enforces this rule at every step, in line with RFC 1035, which defines DNS name syntax.
Some email verification tools automatically normalize selector names to lowercase, assuming case doesn't matter—this is incorrect and leads to inaccurate results.
MailTester never applies casing adjustments, even when the record might theoretically exist in another case. It’s either there, as typed, or it isn’t.

How this affects verification accuracy

By preserving exact case during lookup, we avoid false positives where a selector appears valid only because of case normalization.
This ensures the DKIM validation outcome reflects the actual state of the domain’s DNS configuration.
The consistency of this approach underpins our 98.9% accuracy rate across both bulk verification and real-time API checks.
If you’re validating a list before sending, this level of precision means you won’t waste sends on addresses where DKIM is broken—and you won’t falsely trust those where it seems valid only because of a casing mistake.
Try it yourself with our bulk verification tool, or use our real-time API to validate individual addresses with full DNS fidelity.

Case sensitivity isn’t a minor detail—it’s foundational to how DNS resolves records. Skip it, and you skip the truth.

Why case matters more than you think: a deeper look into DNS standards

Even though domain names are technically case-insensitive in DNS, TXT record names—including those used for DKIM selectors—are not. A mismatch in capitalization between your DNS entry and the software querying it—like selector1 vs Selector1—will cause the lookup to fail, breaking DKIM validation. This tiny inconsistency can silently ruin your email deliverability, especially when your email verification software relies on accurate DNS resolution.

The real rule: DNS is strict about label case

According to RFC 1035, while domain names are treated as case-insensitive in practice, the full label name—including case—must match exactly during DNS record retrieval. This applies to TXT records, where every character matters. So if your DNS provider stores a DKIM TXT record under Selector1._domainkey.example.com, and your software queries selector1._domainkey.example.com, the answer will be "not found."

Let’s be clear: this isn’t a quirk. It’s how DNS works. The standard requires exact matching. Even one letter differently cased means no result. This is why a single uppercase letter can invalidate an entire email verification process.

How this impacts verification tools like MailTester

When email verification software like MailTester checks DKIM records, it’s doing a raw DNS lookup. If the selector string is mis-cased in your record, the tool returns a "DKIM not found" result—even if the domain and key are correct. This leads to false negatives, marking valid addresses as invalid.

That’s especially dangerous during list hygiene. A high false-negative rate means you’re excluding legitimate users, which hurts engagement and damages sender reputation over time. It also makes it harder to diagnose real deliverability issues, because you’re filtering out good emails due to a trivial case mismatch.

MailTester’s API and bulk verification tools perform these checks at scale. They’re built to follow DNS standards precisely, handling case sensitivity exactly as specified. If your DKIM selector is mis-cased, MailTester will flag it so you can fix it before sending. You can test individual addresses to verify resolution before adding them to campaigns.

For deeper insight, you can review the original specification at RFC 1035, which outlines how DNS label comparison works. The takeaway? Treat TXT record names as case-sensitive—even if the domain itself isn’t. It’s not a suggestion. It’s a requirement.

The bottom line: don't let case sensitivity break your verification

Case-sensitive TXT records are not a hypothetical issue—they’re a real, documented barrier in DNS resolution that directly impacts DKIM selector validation. Ignoring or normalizing case during verification leads to inaccurate results, especially when testing real-world configurations.

Email verification tools that treat TXT records as case-insensitive produce false negatives. This weakens list hygiene and creates a misleading sense of accuracy. True reliability requires respecting DNS standards exactly as they are defined, not as you’d prefer them to be.

MailTester processes DNS queries without normalization. Every lookup reflects actual server behavior, ensuring that verification outcomes match what happens in production. This adherence to technical precision is why MailTester delivers 98.9% accuracy across real-world deployments.

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

Are DNS TXT records case-sensitive?

Yes. While domain names are treated as case-insensitive in DNS, TXT record names are processed with exact case matching.

Can a DKIM selector with wrong capitalization still work?

No. If the selector name in the email header does not exactly match the TXT record name, DKIM validation fails.

Why do some email verification tools fail to detect valid DKIM records?

They may normalize case during DNS lookup, which causes valid selectors to be missed if the case differs.

How does MailTester avoid false positives from case mismatches?

It performs DNS lookups using exact case matching without normalization, preserving standard behavior.

What happens if a DKIM selector is incorrectly cased in the DNS record?

The email will fail DKIM validation regardless of sender authenticity, often resulting in rejection or spam filtering.

Is there a tool to test DKIM selector case accuracy?

Yes, command-line tools like `dig` or online DNS lookup services can verify exact case of TXT records.

Do all email verification tools use exact case matching?

Not publicly confirmed. Most do not disclose their DNS handling, but MailTester explicitly uses exact case.

Can case changes in DKIM configuration break existing verification?

Yes. Updating a selector’s case without re-publishing the record breaks backward compatibility and verification.

Why is 98.9% accuracy important in email verification?

It means 98.9% of verdicts—valid, invalid, catch-all, risky—are technically correct, reducing false outcomes.

What does 'risky' mean in an email verification result?

It indicates high likelihood of deliverability issues, such as role accounts, temporary blocks, or catch-all configurations.

Can disposable email providers pass DKIM verification?

Yes, if they set up DKIM properly. But many do not, and their domains often fail authentication checks.

Do all email verification tools test DKIM?

No. Some only confirm syntax or domain existence. MailTester includes actual DKIM selector resolution in its checks.