DKIM s= Selector Uppercase Error

Why Does a Uppercase DKIM s= Selector Break Email Verification?

You sent a campaign. All your headers and SPF records look correct. But every message bounces with “Authentication failed” — even though your DKIM public key exists in DNS.

It’s not your content. It’s not your sender reputation. It’s a single uppercase letter in your DKIM selector — and it breaks everything.

The DKIM s= selector is case-sensitive by design. According to RFC 6376, only lowercase letters are valid. Using uppercase, even a single one, makes the selector invalid. Most email servers and verification tools reject it outright. The DNS lookup fails because the domain record isn’t found under the wrong case.

A single typo can make all your outbound messages unauthenticated — even if the public key is technically correct and your signing algorithm is sound. This isn’t a minor glitch. It’s a full rejection at the mail transfer layer.

Key takeaways

DKIM s= selectors must be lowercase; uppercase letters are invalid per RFC 6376.
Even a single uppercase letter invalidates the entire DNS lookup path, leading to email rejection.
Verification systems and servers strictly enforce case sensitivity — no exceptions.

How Email Verification Tools Detect DKIM s= Selector Case Errors

You can catch DKIM s= selector case errors during email verification because tools like MailTester perform real-time DNS lookups that validate the exact case of the selector. Most DKIM configurations require the s= value to be lowercase; if it's uppercase or mixed-case, the signature fails validation. MailTester checks this explicitly and returns a clear "DKIM failure" with the note "Selector case mismatch: expected lowercase" to prevent senders from using domains with broken DKIM setups.

Real-Time DNS Checks with Case Sensitivity

When you check an email address, MailTester doesn’t just validate the syntax—it goes further. It performs a live DNS lookup for the DKIM record at the domain, fetching both the public key and the selector’s location. This includes checking the exact case of the s= value, which is often overlooked but critical. According to RFC 6376, section 3.1, the selector is a domain label and must be treated case-insensitively, but the DNS lookup process requires exact string matching. If a server returns a record with an uppercase selector (e.g., s=MySelector), the verification process flags it as invalid because the standard practice is lowercase.

Clear, Actionable Feedback to Prevent Sending Errors

Unlike some tools that return generic "DKIM failure" messages, MailTester gives you the specific reason: “Selector case mismatch: expected lowercase”. This helps you identify the root cause immediately—no guesswork. It’s a safeguard against sending to domains that appear valid but fail authentication because of a case mismatch in the selector. This level of detail is especially useful when cleaning a large list or debugging bulk sends where a single misconfigured domain can impact inbox placement.

Because DKIM is a core part of modern email authentication, catching these issues early avoids delivery problems. You can run a full list through our bulk verification to catch all such issues in advance. It’s one of the few ways to ensure your domain’s DKIM implementation is both technically compliant and operationally sound.

The Real Impact of a Wrong DKIM s= Selector on Deliverability

Using an uppercase s= selector in your DKIM DNS record—like s=MYKEY instead of s=mykey—is invalid. Receiving servers treat this as a syntax error. Messages with malformed DKIM signatures are considered unauthenticated. Even if the email passes other checks, the failure at the DKIM level can trigger spam filters or outright rejection, especially at scale. You don’t need to guess: validating your DKIM setup is a non-negotiable step in ensuring deliverability.

Authentication Failure = Deliverability Risk

DKIM requires strict formatting. The s= selector must be lowercase. When receiving servers parse your DNS record and see uppercase letters, they reject the signature as malformed. This breaks the chain of authentication, leaving your message unverified. Mail servers that enforce strict DKIM policies—like Gmail, Outlook, and Apple Mail—typically treat unauthenticated mail as high risk. Even if your message isn’t blocked, it often lands in the spam folder.

Spam scoring systems, such as those used by Spamhaus and Return Path, assign significant weight to authentication failures. When DKIM fails due to a formatting error, it can push your email’s spam score above the threshold. Once that happens, inbox placement drops, even if your content is clean and your sender reputation is otherwise solid.

Reputation Damage at Scale

One failed DKIM check might not matter on its own. But when you're sending to thousands of addresses and one or more have malformed DKIM selectors—like in a poorly configured bulk email setup—each failed signature contributes to a negative signal. Receiving servers track patterns of inconsistent authentication. If you repeatedly send messages with invalid DKIM, they infer a lack of technical discipline. This harms your sender reputation over time.

For example, a sending domain with consistent DKIM errors can see inbox placement drop from 90% to below 50% within weeks. The damage is cumulative. Each invalid signature adds a data point that reflects poorly on sender trustworthiness.

Let’s be clear: there’s no leniency for format errors in DKIM. The protocol is defined in RFC 6376, and implementations are strict. Misconfigurations like uppercase s= selectors are common in poorly documented or inherited infrastructure. That’s why it’s critical to verify not just your DNS records, but the syntax within them.

Use a tool like MailTester’s email checker to validate the entire email address and its authentication alignment before sending. It checks SPF, DKIM, and DMARC—spotting format issues like invalid s= selectors before they affect your deliverability. You can also verify your full list with our bulk verification to catch systemic issues across your database.

How to Verify a DKIM s= Selector Is Correctly Formatted

DKIM selectors must be lowercase in DNS TXT records. If your s= selector contains uppercase letters — such as s=Mail1._domainkey.example.com — the record is invalid and can break email authentication. Always check the full DNS TXT name for proper formatting: s=lowercase-selector._domainkey.example.com. Use a DNS lookup tool to verify.

Check Your DKIM Record Syntax

Use a tool like MxToolbox or Google’s DNS lookup to retrieve the DKIM TXT record for your domain. Enter selector._domainkey.yourdomain.com (replace selector with your actual value) to fetch the full record.
Inspect the full TXT record name. Look specifically at the s= value. If it contains uppercase letters — for example, s=Mail1 or s=Default — it violates RFC 6376, the standard governing DKIM. Only lowercase characters are allowed.
Confirm the full DNS record name is structured as s=lowercase-selector._domainkey.example.com. The s= part must be followed only by lowercase letters and digits, no uppercase, no special characters.
If uppercase letters are present, update the DNS record in your domain registrar or DNS provider. Remove or replace the uppercase characters and save the change.
Wait up to 48 hours for DNS propagation. Even if your DNS provider says it’s instant, some resolvers still cache records. Use a tool like DNS.google to verify the change has fully propagated before testing again.

Why Format Matters for Deliverability

A wrongly formatted DKIM selector — even one with a single uppercase letter — can cause authentication failure. Receivers like Gmail and Microsoft Outlook reject emails with invalid DKIM signatures. That means higher bounce rates, poor inbox placement, and damage to sender reputation. Email verification tools like MailTester’s email checker can identify invalid records early, helping you avoid delivery issues before they impact your campaigns.

Why Manual Checks Are Not Enough for DKIM Record Validity

Even a single uppercase letter in a DKIM s= selector can break authentication, but manual DNS checks often miss such issues. Human error is unavoidable when copying records—case sensitivity in DNS is easy to overlook, especially when you’re reviewing dozens of keys. Tools that don’t validate DKIM syntax won’t flag invalid selectors, leaving your emails vulnerable to rejection or spoofing.

The Hidden Risk in Multi-Platform DKIM Deployment

Large domains using multiple sending platforms—like marketing, transactional, and automation tools—often maintain dozens of DKIM records. Each adds complexity. One miskeyed selector, like s=mail-1 vs. s=Mail-1, can result in failed verification. The risk isn’t just one mistake—it’s a compounded pattern where a single oversight can disrupt delivery across multiple campaigns.

Most Tools Don’t See What You Miss

Common DNS lookup tools show raw records but don’t parse DKIM syntax. They won’t tell you if the s= token is uppercase, if the selector format breaks RFC 6376, or if multiple keys conflict. Even if you spot the s= part, you might not catch that mail shouldn’t be spelled Mail in the selector. This isn’t a subtle detail—it’s a hard error that breaks SPF/DKIM alignment.

Only tools with built-in DKIM validation logic—like MailTester—inspect the actual structure of the record to ensure compliance. We check the entire DKIM syntax, including the case-sensitivity of selectors, before marking a record as valid. This level of precision is invisible in a simple DNS lookup, but it’s essential for reliable email delivery.

For a real-world reference, the IETF’s RFC 6376 (which defines DKIM) specifies that labels must be case-sensitive. The s= selector, like all DNS labels, must match exactly, including case. You can review the standard at ietf.org/rfc6376. This isn’t optional—it’s part of the protocol. Ignoring it means your emails may not pass authentication, even if they’re routed correctly.

Let’s be clear: if you’re relying on manual checks or generic DNS tools, you’re operating blind. A single uppercase letter in s= can be the reason your emails end up in spam folders or are rejected entirely. The best way to ensure your DKIM records are valid is using a service designed to validate the full syntax—such as MailTester’s real-time verification API, which scans for format issues like malformed selectors, invalid tags, and case sensitivity across all your keys.

MailTester’s DKIM Verification Logic: What It Checks

MailTester checks if a DKIM signature is valid by verifying the full structure, including the selector case, DNS record existence, and key format. It confirms that the domain has a valid public key at the exact lowercase selector specified in the DKIM record—uppercase or mixed-case selectors are rejected as invalid per RFC 6376. This eliminates ambiguity and ensures only correctly formatted signatures pass.

Selector Case Enforcement: Why Lowercase Matters

DKIM requires the selector to be lowercase. Any uppercase letter in the selector, such as s=MySelector instead of s=myselector, results in a failed verification. MailTester flags this precisely as "DKIM invalid (selector case mismatch)" to help you fix it directly.

What the Verdicts Mean

When MailTester evaluates a DKIM signature, it returns one of three clear verdicts:

DKIM valid – The selector matches the DNS entry, the key format is correct, and the signature passes validation.
DKIM invalid (selector case mismatch) – The selector in the header is not lowercase, which violates RFC 6376.
DKIM not found – No DNS record exists for the exact selector, or the public key is malformed.

These outcomes let engineers identify and correct specific issues without guesswork.

Item	Details
DKIM valid	The selector matches the DNS entry, the key format is correct, and the signature passes validation.
DKIM invalid (selector case mismatch)	The selector in the header is not lowercase, which violates RFC 6376.
DKIM not found	No DNS record exists for the exact selector, or the public key is malformed.

The 3 items listed under “What the Verdicts Mean”, side by side.

MailTester doesn’t just confirm “it’s valid or not”—it tells you exactly what’s broken. This precision matters when debugging bounces, improving sender reputation, or ensuring compliance with email authentication standards.

For example, if your email client signs with s=ProdKey, but your DNS has s=prodkey, the signature fails despite the key being functional. Other tools might miss this, but MailTester catches it upfront. This level of detail is why industry-standard practices like those outlined in RFC 6376, Section 3.5 are embedded directly into the verification logic.

Whether you're integrating with SendGrid, validating a bulk list, or testing inbox placement, understanding these nuances helps prevent delivery issues. You can test individual addresses with our email checker, run full list verification at scale with our bulk verification tool, or automate checks via our verification API. The result? Fewer bounces, better deliverability, and clearer paths to troubleshooting.

How to Use the MailTester Real-Time API to Catch DKIM s= Errors

You can catch DKIM s= selectors with incorrect case (like uppercase letters) by sending email addresses through the MailTester Real-Time API with domain verification enabled. The API checks DNS records, including DKIM, and returns a dkim_invalid_selector_case verdict if the selector uses invalid uppercase letters. Fixing this in DNS before sending prevents bounces and protects sender reputation.

Set up the API call to validate DKIM records

Send individual or bulk email addresses to the MailTester Real-Time API using a supported integration method (HTTP POST with JSON body).
Include the verify_dns parameter set to true to enable domain-level checks, including DKIM and SPF.
Set the check_type parameter to include dkim and spf for a full sender authentication review.

Parse the response to detect selector case issues

Examine the dkim field in the response. If it contains a verdict of dkim_invalid_selector_case, the DKIM record’s s= selector uses uppercase letters, which is invalid per RFC 6376.
Correct the DNS record by ensuring the s= selector uses only lowercase letters. For example, change s=MYKEY to s=mykey in the TXT record.
Re-run the verification after the fix. The error should no longer appear in the response.

DKIM selector case sensitivity is strictly defined in RFC 6376, which confirms that only lowercase letters are valid for the s= tag. Using uppercase letters breaks verification and can mark your domain as untrusted by mail providers.

Bulk verification is ideal for scanning large lists. Use the MailTester bulk verification tool to test hundreds of addresses at once, catching all DKIM selector case issues before sending.

The Hidden Risk of Role Accounts and Catch-All Domains in DKIM Validation

You might think a valid DKIM signature means an email address is deliverable, but that’s not always true. Role accounts (like admin@ or sales@) and catch-all domains often pass DKIM validation even though they don’t point to real people. These addresses may accept messages but never deliver them, leading to bounces, poor sender reputation, and inbox placement issues. MailTester flags them as 'risky' or 'catch-all' regardless of DKIM status—so you avoid wasting sends on invalid targets.

Role Accounts: Invisible Bounces and Reputation Damage

Role accounts like info@ or help@ are commonly used in outreach lists. They often trigger auto-replies or silently drop messages, but they still pass basic verification checks. Even if the DKIM signature is valid, there’s no real recipient. Sending to these addresses can hurt your sender reputation over time, especially if your provider penalizes high bounce rates, even when the bounce isn’t technically “hard.”

Let’s be clear: a valid DKIM key doesn’t mean a person is on the other end. It only confirms the message wasn’t tampered with during transit. That’s not enough. A real inbox needs someone to be there—and role accounts rarely are.

Catch-All Domains: The Illusion of Deliverability

Catch-all domains accept all incoming mail, regardless of whether the address exists. While this makes them appear "valid" in many checks, it also means most messages to them end up in spam folders or are ignored. Even if the DKIM signature is correct, the recipient is unlikely to see the email.

According to the IETF’s SMTP standard (RFC 5321), catch-all domains are technically allowed, but they’re a known source of abuse. They inflate your deliverability metrics without improving engagement. Many modern email providers now treat catch-alls as suspicious or low-value, reducing their chances of landing in inboxes.

MailTester detects these cases early by analyzing DNS records, email behavior, and domain patterns. It doesn’t just look at the DKIM signature—it checks whether the domain actually has active, real-world endpoints. If not, it marks the address as catch-all or risky, helping you filter out addresses that would otherwise waste your send budget and damage your sender reputation.

If you're verifying a list before campaign send, you need more than just a passing DKIM check. You need confidence that the recipient is real, engaged, and not just a mailbox that accepts everything. Use our bulk email verification to test entire lists for these risks before sending, and avoid the silent drain on your deliverability.

Best Practice: Validate DKIM Configuration Before Launching Every Campaign

You must verify SPF, DKIM, and DMARC DNS records before every campaign launch. A single misconfigured DKIM selector—like using uppercase letters in s= (e.g., s=Default) instead of lowercase (s=default)—breaks authentication and leads to delivery failure. Even if your domain supports case-insensitive selectors, some receiving servers enforce strict parsing. Always test your full DNS setup in a real-world environment before sending.

Check your DKIM setup systematically

Use MailTester’s inbox-placement testing to simulate how your emails land in real user inboxes, including spam filters and blacklists.
Validate your DKIM selector format: the s= value in the DNS TXT record must be lowercase. Using uppercase letters is invalid per RFC 6376 and may cause rejection by strict mail servers.
Confirm DNS propagation by checking your record via MxToolbox or similar tools to ensure it's live across the internet.
Run a full bulk verification on your email list—especially when migrating domains or changing sending infrastructure—to catch invalid, disposable, or syntactically incorrect addresses.
Automate monthly checks: treat DKIM and SPF configurations as part of monthly list hygiene. Even correct records can break due to changes in your email provider or DNS setup.

Pro tip: Test real-world delivery, not just syntax

Having valid DNS records isn’t enough. A mail server can technically verify DKIM but still block your message due to low sender reputation or poor engagement history. Let’s be honest: syntax errors get you flagged fast; soft bounces and low inbox placement quietly erode deliverability over time. That’s why MailTester’s inboxes testing checks real delivery outcomes—not just the code.

Common DKIM Configuration Mistakes That Look Valid but Aren’t

You might think your DKIM setup is working because the selector appears in DNS, but small mismatches—like case sensitivity, extra spaces, or a wrong selector name—can silently break email authentication. Even if your email sends without error, receiving servers may reject it due to validation failures. A single typo in the selector can cause deliverability issues you won’t see until your inbox placement drops.

Check Your DNS Records for Accuracy

Verify that the DKIM selector (e.g., default, mail1) in your DNS TXT record exactly matches the one you've configured in your email service. A mismatch like Default vs default causes validation failure—even if the record exists.
Ensure there are no trailing spaces, underscores, or hidden characters in your selector. A selector like default or default_ is invalid and will fail DKIM checks.
Use real DNS lookup tools to confirm the TXT record exists and returns the full key. Tools like MXToolbox or DNS Survey can validate the raw record without assuming correctness.

Manage Selectors Per Subdomain

Do not assume one DKIM selector works across all subdomains. Each subdomain (e.g., mail.yourcompany.com) typically requires its own selector and TXT record if it sends emails independently.
Never use a single DKIM record for multiple subdomains unless you’ve explicitly configured it to do so. Many systems default to using default, but this only works if the DNS record for that selector is present and correct.
Double-check your sending platform’s configuration (e.g., SendGrid, Mailgun, AWS SES) to ensure it’s using the exact selector name you’ve published in DNS—case matters, and no automatic case conversion happens on the receiving end.

Even if your DKIM signature appears valid when tested, a single mismatch can still lead to rejection by mail servers. The most common issues are not with the key itself but with how the selector is defined and published. Use MailTester’s email checker to validate individual addresses before sending, and bulk verify your list to catch widespread delivery issues early.

Why MailTester’s 98.9% Accuracy Matters for DKIM Verification

Subtle errors like uppercase letters in the DKIM s= selector can break email authentication, but many tools miss them entirely. This leads to false positives and undetected validation failures.

Unlike systems that rely on static databases or incomplete checks, MailTester validates the full email delivery chain using real-time DNS resolution and protocol simulation. This includes enforcing case sensitivity in selectors, ensuring only valid configurations pass.

With 100 free verifications and credits that never expire, testing your setup is low-risk. Catching these edge cases early prevents deliverability issues before they impact your sender reputation.

Sources

Roughly one in six legitimate commercial emails (16.5%) never reaches the inbox globally — 6.7% is filtered to spam and 9.8% disappears without a bounce. — Validity 2025 Email Deliverability Benchmark Report (2025)
Benchmark testing of 15 major email service providers found about 10.5% of legitimate emails land in the spam folder and a further 6.4% go undelivered. — EmailTooltester deliverability benchmark (via WarmForge) (2026)

Keep reading

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

Frequently asked questions

Does DKIM s= selector case matter?

Yes. The DKIM s= selector is case-sensitive. Only lowercase selectors are valid in DNS records. Uppercase letters cause lookup failures.

Can a DKIM record with an uppercase selector still pass verification?

No. Most verification systems and servers enforce lowercase strictly. An uppercase selector results in a failed DKIM validation.

How do I check if my DKIM s= selector is lowercase?

Use a DNS lookup tool to examine the TXT record at 's=selector._domainkey.example.com'. Ensure the 's=' part and the selector name are fully lowercase.

Why does MailTester show DKIM invalid when my DNS record looks right?

It may be due to case mismatch. MailTester checks the exact spelling and case of the selector. Even one uppercase letter breaks the match.

Can I use different DKIM selectors for different senders?

Yes—each sender can use a different selector (e.g., ‘mail1’, ‘campaign’). Each must have its own published TXT record with the correct, lowercase name.

What happens to emails with invalid DKIM s= selectors?

They are often rejected by recipient servers, marked as unauthenticated, or sent to spam. This damages sender reputation and reduces deliverability.

Does MailTester verify SPF, DKIM, and DMARC together?

Yes. MailTester checks all three authentication protocols in a single verification step, including selector case and record structure.

Can MailTester help me find missing DKIM records?

Yes. It identifies domains where DKIM records are missing or malformed, including case issues, and returns specific error codes.

Do I need to use DNS TXT records for DKIM?

Yes. DKIM uses a DNS TXT record under the selector name. The record must exist and be correctly formatted with lowercase selectors.

How often should I validate my DKIM configuration?

At least monthly during list maintenance, before major campaigns, and after any DNS or domain migration.

Are there tools that don’t catch uppercase DKIM selectors?

Yes—many basic email verification tools skip deep DKIM checks or don’t validate case. This increases the risk of undetected failures.

Can a catch-all domain have valid DKIM?

Technically yes, but it’s unreliable. MailTester flags catch-all domains as risky because they accept all addresses, even invalid ones.