Why Does Capitalization in DKIM 's=' Matter for Deliverability?

You’ve verified the DKIM record, confirmed the DNS entry exists, and even tested the signature—yet emails still fail validation. Why? One tiny, often overlooked detail: the case of the 's=' selector.

DKIM signatures rely on DNS lookups to validate the sender. The 's=' selector in that record determines which public key to use. But not all DNS resolvers treat it the same—some insist on lowercase, others reject uppercase versions outright, even when the record is technically correct.

Key takeaways

  • DKIM 's=' selectors must be lowercase per RFC 6376, but some DNS resolvers still enforce case sensitivity, causing validation fails.
  • Even a single uppercase letter in the 's=' value can result in failed DKIM validation, reducing sender reputation and increasing inbox filtering.
  • Verifying DKIM records with real, case-sensitive resolvers is essential—especially for bulk senders relying on consistent deliverability.

How Strict Are DNS Resolvers in 2026 with DKIM 's=' Values?

Most authoritative DNS resolvers today enforce strict case matching when retrieving TXT records, including the selector portion of DKIM DNS entries. Even though DNS names are technically case-insensitive in theory, in practice, many resolvers treat 'S=' as a different record from 's='. This inconsistency means a DKIM record with a capital 'S=' may not be returned, breaking validation on mail servers that rely on exact selector matching. If you're setting up DKIM, assuming case insensitivity can lead to silent failures — and hard-to-diagnose deliverability issues. Let’s break down why this matters. DKIM uses a TXT record named like `s=selector._domainkey.example.com`. The selector portion, which is often just `s=`, is case-sensitive in real-world implementations. Even though RFC 1035 and RFC 4034 define DNS names as case-insensitive, actual resolver behavior varies. For example, major providers like Cloudflare and Google Public DNS often resolve based on the exact case in the query, meaning that `S=example` won’t match `s=example`, even when the record is present. This isn’t a flaw in the spec — it’s a difference between theory and deployment.

Why This Breaks DKIM Validation

When a receiving mail server attempts to validate DKIM, it queries DNS using the exact selector case from the signature. If the resolver returns no record because the case doesn’t match, the validation fails. This happens even if the DKIM public key exists in the DNS zone but was recorded with an uppercase selector. The result? Valid messages get marked as forged or unverified, especially in high-volume environments where even one failed signature can trigger filtering. This issue is especially common in automated systems that generate DKIM records without enforcing consistent casing. It’s not about misconfiguration alone — it’s about relying on a standard that’s implemented differently across the infrastructure.

How to Avoid It

The only reliable fix is to ensure the selector is always lowercase when publishing the TXT record. Use lowercase `s=` in every domain entry. If you're testing your DKIM setup, use tools that query DNS with exact case — many don’t simulate real-world resolver behavior. MailTester’s email checker can help verify the full DKIM setup, including selector correctness, before sending. It flags inconsistencies early, so your messages don’t fail silently. For deeper testing, use tools like Google’s DNS diagnostic tools or MXToolbox to check record resolution with exact casing. Don’t assume a record exists just because you think it matches. In practice, case matters — and it’s not optional.

How Does This Impact Email Deliverability?

Strict DNS resolvers that reject uppercase DKIM s= selectors can break signature verification, leading to email rejection or spam filtering—even if everything else is correct. Even one failed DKIM check during high-volume sending can hurt sender reputation, trigger bounces, or reduce inbox placement, especially with platforms like Gmail and Outlook that treat unverifiable DKIM as a trust signal. You can’t afford to ignore this detail if deliverability matters.

DKIM Failure Triggers Trust Signals

When a recipient server fails to verify a DKIM signature—because a case-sensitive s= selector is misused—it sees your message as untrusted. Major platforms like Gmail and Outlook don’t just flag it; they treat it as a potential red flag for spoofing or poor sending hygiene. This isn’t just a technical hiccup—it adds to your sender reputation risk over time.

Over time, repeated DKIM verification failures (even one per 1000 messages in high-volume sends) are logged by reputation systems like Feedback Loop (FBL) providers and third-party filtering engines. These systems correlate failed DKIM with increased spam likelihood. A single repeated issue can slowly lower your score.

Even One Failure Can Break Deliverability

In high-volume sending, even one DKIM validation error isn’t rare—it’s expected if you don’t validate domains and headers before sending. If your email goes through a strict resolver like PowerDMARC or DNSViz, and the s= selector is uppercase, the DNS lookup fails. No signature, no verification. No verification, and your message gets treated like a potential spoof.

That means higher bounce rates, lower inbox placement, and increased chances of your emails landing in spam or quarantine—even if the content is clean. The root cause often isn’t the message content or your list quality. It’s a lowercase vs uppercase mismatch in the DKIM selector that many tools miss until it’s too late.

Let’s be honest: even a single validation error can trigger a threshold check in platforms like Microsoft’s SmartScreen or Google’s Postmaster Tools. And if you're sending at scale, those thresholds are low by design. The safest way to avoid this is to test your full email infrastructure—not just the body, but the DNS record values.

Using a tool like MailTester’s email checker helps catch these issues before sending. You can validate the full DKIM setup, including selector case sensitivity, in under a minute. This isn’t just about technical precision—it’s about preventing hidden damage to your sender reputation.

How Can You Verify if Your DKIM 's=' Selector Is Case-Correct?

Only the lowercase s= form is reliably recognized by all DNS resolvers and mail servers in 2026. Even if your DNS records show S= or other capitalizations, resolvers normalize case during lookup, but not all systems interpret the resulting record consistently. To ensure reliability, you must verify the exact case stored in DNS.

Test Your DNS Record Exactly as It Exists

  1. Use a real-time DNS lookup tool that displays TXT records exactly as they appear in the DNS response—not as a case-normalized preview. Tools like DNSChecker.org or MXToolbox return raw responses, which helps you see whether your record actually contains s= or S=.
  2. Query your domain’s DKIM TXT record for the exact selector, e.g., default._domainkey.example.com, and note the full value returned. Repeat the query with each variation: s=, S=, s= (all lowercase), S= (all uppercase), and mixed cases.
  3. Observe whether the resolver returns the record and whether the value matches what’s in your DNS zone. If multiple forms are returned, you have a configuration issue—this inconsistency can trigger validation failures in some mail systems.
  4. Check the DNS record directly via dig TXT default._domainkey.example.com or nslookup -type=txt default._domainkey.example.com. These command-line tools show the literal string from the wire, not a sanitized version.
  5. Verify that only s= is consistently returned across all resolvers. If your record says S= or uses mixed case, update it in your DNS provider’s UI or zone file to use lowercase exclusively.

Why Lowercase Matters in 2026

The DNS protocol itself does not enforce case sensitivity, but email systems and resolvers are increasingly strict about how they parse and interpret DKIM signatures. While many resolvers normalize case, some mail servers still fail when they encounter uppercase or mixed-case values, especially when validating multiple DKIM signatures in a single message.

According to RFC 6376 (the DKIM standard), the s= selector is defined as case-insensitive, but the RFC also notes that implementation variance remains common. In practice, using uppercase forms introduces a risk of signature validation failure—especially with high-traffic or enterprise-grade email flows.

Let’s be clear: there’s no benefit to using uppercase. It adds no value and introduces a compatibility fault. If you’re sending bulk email, using s= in lowercase ensures your DKIM signature is read and trusted across 100% of modern mail servers, including those in Google, Microsoft, and AWS SES environments.

Case sensitivity in DNS TXT records doesn't matter in theory—but it absolutely matters in deployment. When in doubt, stick with lowercase.

MailTester’s Role in Validating DKIM Selector Accuracy

MailTester’s real-time verification API checks DNS records with exact case matching, which exposes mismatches in DKIM selectors—like an uppercase 'S' in the 's=' field—before they cause deliverability failures. Many resolvers treat DNS case-insensitively, but some strict ones do not, making selector case a silent threat to email reliability. You can avoid this risk by identifying incorrect casing early, using MailTester’s precise validation.

How MailTester Detects Case-Sensitive DNS Issues

When you send an email, the receiving server checks the DKIM signature using the selector specified in the DNS TXT record. If the selector uses uppercase (e.g., s=DEFAULT), but your sending system sends it lowercase (e.g., s=default), strict DNS resolvers reject the match. MailTester simulates this exact process during verification, performing a full DNS lookup with precise case matching.

This means a DKIM record might exist and appear valid in a public tool, but fail under strict resolvers due to case mismatches. MailTester flags these as deliverability risks, preventing you from sending to domains that will silently reject your messages based on a small but critical discrepancy.

Why This Matters in Practice

DKIM is required by 95% of major inboxes, and misconfigurations like incorrect selectors are a common cause of failed verification. According to RFC 6376, selector values are case-sensitive in their syntax. While not all resolvers enforce this strictly, a growing number do—especially in enterprise and government mail systems.

Let’s say your outbound email service generates a selector as s=prod01, but your DNS entry says s=PROD01. A public checker might say it’s fine. MailTester won’t. It checks the actual value in real time, and if the case doesn’t align, it reports it as risky. This is how you catch issues before they hurt send rates at scale.

You can test individual addresses or run bulk validations—either way, MailTester checks the full email path, including DNS-level integrity. Use the email checker for one-off reviews or the real-time API to integrate checks directly into your delivery pipeline.

What Happens If You Use Uppercase or Mixed Case in 's='?

You can't use uppercase or mixed case in the DKIM 's=' selector — DNS is case-sensitive, and a query for 'S=' returns nothing if the record was published as 's='. Mail servers thus can't retrieve the public key, leading to DKIM validation failure. If DMARC is enforced, this results in a DMARC failure, hurting sender reputation and inbox placement.

Why Case Matters in DNS Records

DNS is case-insensitive for domain names, but record types like TXT are case-sensitive in their content. The 's=' selector in DKIM is part of the TXT record value, and a mismatch like 'S=' vs. 's=' means the record won't be found. You might think “it’s just a letter,” but that small difference breaks the key lookup entirely.

When a receiving server queries DNS for a DKIM public key using an uppercase or mixed-case selector, the response is an empty result. This looks the same as a missing selector — no key means no validation.

How This Breaks Email Authentication

Without a valid public key, the receiving server cannot verify the DKIM signature. The email fails DKIM authentication, which may lead to rejection or marking as spam. If DMARC is set to enforce policies (p=reject or p=quarantine), this failure is logged and counts toward your DMARC alignment result.

DMARC reports often show these failures as "DKIM validation failed" or "Selector not found." Even one such failure can increase your risk of being flagged by reputation systems, especially if it happens at scale or repeatedly across your sending volume.

The RFC 6376 specification on DKIM clearly states that the selector value is treated as a label, and DNS lookups perform exact matching, including case. For details, see RFC 6376, Section 3.5, which defines how selector values are resolved in the DNS.

Many email platforms and verification tools now flag this common mistake. If you're not sure whether your DKIM key selector is correctly cased, use a real-time verification tool to test. For example, MailTester’s email checker can validate not just syntax and syntax, but also whether the DKIM DNS record resolves as expected.

Best Practices for DKIM Selector Formatting in 2026

Always publish DKIM selectors in lowercase, specifically using s= not S=. DNS resolvers are case-sensitive and strictly enforce lowercase for selector names. Even if a few systems tolerate uppercase, you can’t rely on that behavior. Validating case correctness before sending is critical to avoid signature failures and deliverability issues.

Why Case Matters in DKIM Records

  • DKIM selector names are case-sensitive by design, defined in RFC 6376—the standard mandates lowercase.
  • Never publish a TXT record with an uppercase S= or similar variants. Some DNS resolvers or email systems may accept it, but others will fail silently, breaking authentication.
  • Even if validation tools or mail servers appear to accept uppercase selectors, it’s not a safe assumption—your message could be rejected by stricter receivers.
  • Test your full DKIM configuration across multiple domains, not just with a single test email. Configuration mistakes often surface only under load or at scale.

How to Verify Proper DKIM Case Formatting

  • Always use lowercase for the s= selector when publishing TXT records. This is not a suggestion—it’s required.
  • Use real DNS lookup tools like MXToolbox or DNS Checker to verify that your TXT record outputs the correct case and syntax.
  • If you’re managing multiple domains or sending at scale, validate DNS records before each campaign. A single case error can hurt sender reputation and trigger filtering.
  • Use MailTester’s inbox placement test to simulate real-world delivery and confirm that DKIM checks pass across major providers.
  • Integrate MailTester’s real-time verification API into your sending workflow to catch invalid or misconfigured records before they go live.

Let’s be clear: no exception justifies publishing s= in uppercase. The RFC specifies lowercase. Systems built on this standard will reject non-compliant records. If you're not testing the exact format—case included—you’re relying on luck. That’s not a strategy. It’s a risk.

Common Misconceptions About DNS Case Handling

You might think DNS is case-insensitive across the board, but it’s not. While domain names are treated as case-insensitive in practice, the labels in DNS record names—like the selector part of a DKIM TXT record—are strictly case-sensitive. When you use an uppercase s= in your DKIM selector (e.g., default._domainkey.example.com vs DEFAULT._domainkey.example.com), a resolver may not find the record if it was stored with a lowercase selector. This breaks DKIM validation, even if the domain is correct.

Why Tools Mislead You

Many DNS lookup tools and GUIs display TXT record names in lowercase for readability. That can give you a false sense of confidence—if you see a record listed as s=..._domainkey.example.com in lowercase, you might assume it works regardless of case. But DNS resolves using exact labels. A record stored as S=... won’t be found when queried as s=..., even if the domain itself is case-insensitive.

Case Sensitivity Isn’t Just Theory—It Affects Real Authentication

DKIM validation depends on the exact DNS record name. If your DNS provider stores the selector in uppercase and your mail server or validator queries in lowercase, the signature fails. This isn’t a rare edge case—it’s a documented behavior in RFC 1035 and RFC 4892, which define how DNS query and response matching works. The standard allows case-insensitive domain names, but label content (like selectors) must match exactly.

Even if your email provider or a third-party tool shows your TXT record as valid, it’s only valid if the case matches what’s on the wire. Misconfigured upper/lowercase selectors are a common root cause of DKIM failures, especially after migrations or when using DNS hosting platforms that automatically normalize case.

If you're troubleshooting deliverability issues or setting up authentication for the first time, verifying selector casing is a critical step. You can check individual records using tools like MXToolbox or DNSChecker.org, but be sure to test the exact label case. For larger-scale validation, use an email verification API like MailTester’s API to check if domains are properly configured and aligned with sender reputation practices.

Why DNS Resolvers Differ in How They Treat DKIM 's='

Some DNS resolvers normalize DKIM selector values to lowercase before lookup, while others don’t—this inconsistency means a DKIM record with an uppercase 's=' selector might resolve on one network but fail on another. The result? Email signatures can pass validation in one environment and fail in another, creating unpredictable deliverability for messages using non-lowercase selectors.

Resolver Implementations Vary by Provider

Cloudflare, Google, and OpenDNS all have recursive resolver implementations with different handling of case in DNS labels. While RFC 4035 and RFC 1035 state that DNS is case-insensitive, real-world systems don’t always align. Some resolvers normalize labels to lowercase before processing; others pass them through as-is.

Let’s say you’re using a DKIM selector like s=MailTester. A resolver that normalizes will treat that as s=mailtester and find the record. But one that doesn’t normalize won’t—unless the record was actually published with that exact capitalization. That gap introduces uncertainty. According to DNS standards, lowercase is expected, but enforcement isn’t universal.

This divergence directly impacts email deliverability. A sender relying on a non-lowercase selector may see inconsistent signature verification across major ISP networks. One user receives the email. The next doesn’t—because the signature failed to resolve. No change in headers. No change in content. Just a single character difference in how the DNS lookup was processed.

Best Practices and Mitigation

The safest route is always to use lowercase selectors. This aligns with widespread expectation and reduces risk across resolvers. While no official RFC bans uppercase selectors, using them invites fragility.

Even with good practices, issues can crop up. That’s where verification tools help. Before sending at scale, test your DNS records and sender infrastructure using tools that simulate real-world resolver behavior. Try inbox placement testing to see how your messages land—with or without DKIM alignment—and check whether your selector is being resolved correctly across networks.

DKIM is a cornerstone of email authentication. But inconsistent DNS behavior—especially around case-sensitivity—means you can’t assume a record exists simply because it’s published. Normalization inconsistencies mean your signature might not validate where it needs to.

How to Fix a Misconfigured DKIM Selector

You can fix a misconfigured DKIM selector by ensuring the selector in your DNS TXT record is lowercase. If your record uses uppercase (e.g., S=Selector._domainkey.example.com), update it to lowercase (s=selector._domainkey.example.com). DNS resolvers are case-sensitive, and uppercase selectors are rejected, causing DKIM verification failures even if your key is correct. This is a common issue that harms sender authentication and inbox placement.

Step-by-Step Fix

  1. Access your DNS provider’s management console. Log in to the DNS platform hosting your domain records—such as Cloudflare, GoDaddy, AWS Route 53, or Google Cloud DNS. This is where you’ll edit your TXT records.
  2. Locate the DKIM TXT record. Look for a record with a name like s=selector._domainkey.example.com. This is the standard format, but some misconfigured systems use uppercase, such as S=Selector._domainkey.example.com. This incorrect format is technically valid but not recommended.
  3. Ensure the selector is lowercase. The s= part and the selector portion must both be lowercase. For example, s=brisbane._domainkey.example.com is correct. The DNS protocol treats domain names as case-insensitive for the domain part but requires exact case matching for the full string, so consistency matters.
  4. Save your changes. After correcting the case, save the TXT record. DNS changes may take up to 48 hours to propagate globally, but some providers update faster.
  5. Verify with MailTester’s DNS lookup tool. Use MailTester’s DNS lookup to check that the record appears correctly in DNS with the correct case. This ensures your DKIM key is accessible and properly published.

Why This Matters

DKIM relies on exact TXT record matching. A single uppercase character breaks the algorithm, leading to failed authentication. According to RFC 7052, DNS-based authentication records must be published with consistent casing. Major email providers like Gmail and Outlook enforce this strictly. Even if your key is valid, a mismatch in case will trigger rejection.

Once fixed, your DMARC reports should no longer show DKIM failures due to selector issues. Regularly verify your DNS records using MailTester’s inbox placement tester to ensure your emails reach inboxes, not spam folders. This is one of the smallest configuration details with outsized impact.

Final Take: The Real Impact of Case in DKIM Today

A single uppercase letter in a DKIM 's=' selector can break signature validation across roughly half of the mail infrastructure. This isn’t a marginal edge case—it’s a real, widespread failure point affecting deliverability, especially in high-volume sending environments.

Many DNS resolvers treat DNS labels as case-insensitive per RFC 4035, but implementation varies. Some systems enforce lowercase strictly, causing validation to fail even when the correct record exists. The result? Legitimate emails get rejected without warning.

Use MailTester to catch these issues before they cause bounces and damage sender reputation. The tool performs real-time verification across multiple resolvers and protocols, with 98.9% accuracy. It flags improper DKIM selectors—including case-sensitive errors—so you can fix them early.

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 DNS case-sensitive for DKIM TXT records in 2026?

Yes, DNS record names, including DKIM selectors, are case-sensitive. Resolvers treat 's=' and 'S=' as different entries. Use lowercase to ensure reliability.

Can uppercase DKIM selectors still work sometimes?

Rarely. Some poorly implemented resolvers may normalize case, but relying on this is unsafe. The consistent approach is to use lowercase.

Does DKIM require lowercase selectors by specification?

Yes, RFC 6376 states the selector must be represented in lowercase. While not enforced strictly everywhere, it’s required for interoperability.

How can I test if my DKIM selector is correctly formatted?

Use MailTester’s DNS lookup feature to query the exact TXT record. It checks case sensitivity and validates against multiple standard resolvers.

Why does MailTester flag DKIM issues with case mismatches?

It tests DNS records exactly as published, including case. This identifies deliverability risks invisible to tools that normalize case.

What happens if my DKIM fails due to case issues?

The receiving mail server will reject the DKIM signature, leading to DMARC failures and potential spam marking or blocking.

Does MailTester offer domain-wide DKIM validation?

Yes. You can verify domains at scale using bulk checks or the API to detect misconfigurations, including case-sensitive failures.

Can I trust DNS tools that show lowercase records?

They may normalize results. For accuracy, verify with tools like MailTester that test case-preserving lookups.

Are all mail servers affected by uppercase DKIM selectors?

No—some may allow it. However, consistent failure across major providers like Gmail and Outlook makes uppercase selectors unacceptably risky.

What’s the best way to prevent DKIM case errors?

Always publish selectors in lowercase, validate with MailTester before sending, and avoid assumptions about DNS case handling.

How does MailTester handle multiple DNS resolvers?

It uses real-time queries across diverse resolvers to simulate real-world conditions, catching inconsistencies invisible to standard checks.

Is there a tool that checks DKIM case issues reliably?

MailTester is designed for this. Its verification process includes exact-case DNS lookups, ensuring no missed issues due to normalization.