Why does your DKIM s= selector matter for inbox delivery?

You’ve set up DKIM. Your emails are signed. But why are some still landing in spam—or vanishing without a trace?

The answer might hide in a tiny part of your DNS record: the s= selector. It’s not just a label. It’s the key that receiving servers use to find your public signature key. If the selector breaks DNS rules, the handshake fails—before the message even reaches the inbox.

Using underscores in your s= selector might seem harmless. But it violates RFC 5322 and strict DNS naming conventions. Only letters, digits, and hyphens are allowed. Even if your email sends, strict validators will reject the record. Authentication breaks. Reputation suffers. Deliverability drops. No exceptions.

Key takeaways

  • DKIM s= selectors must use only letters, digits, and hyphens—underscores are invalid per DNS standards.
  • Even valid-looking DKIM records with underscores can fail strict DNS validation, breaking email authentication.
  • Invalid selectors can lead to failed authentication, reduced inbox placement, and long-term damage to sender reputation.

What exactly is a DKIM s= selector and why does it matter?

The s= selector in a DKIM DNS record identifies which public key to use for authentication. It’s part of the TXT record name, like default._domainkey.example.com, where “default” is the selector. But underscores in selectors violate RFC 1035 and RFC 5322, which restrict DNS labels to letters, digits, and hyphens—underscores are not allowed. This can break email validation even if everything else is correct.

How selectors work in DKIM

When you set up DKIM, you generate a public-private key pair. The public key goes into a DNS TXT record under a label like selector._domainkey.example.com. The s= field in that record tells incoming mail servers which key to use for verification. This lets you rotate keys without changing the entire domain setup.

For example, if you use mail1._domainkey.example.com, the selector is “mail1”. If mail servers can’t resolve that label correctly due to invalid characters, DKIM validation fails—even if the key itself is valid. That means your emails may end up in spam or bounced outright.

Why underscores break things

Under DNS standards, domain labels must follow specific rules. RFC 1035, the foundation of DNS naming, defines label syntax: only letters (a-z), digits (0-9), and hyphens (-) are permitted. Underscores are explicitly excluded.

While some DNS servers accept selectors with underscores (like my_selector._domainkey.example.com), others reject them during validation, causing inconsistent behavior. This can lead to unreliable DKIM results, especially across major email providers like Gmail and Outlook, whose systems enforce strict parsing.

Even if your DMARC reports show alignment, broken DKIM due to invalid selectors can still hurt your sender reputation. And unlike a typo in a body text, this error isn’t caught by most user-facing tools. It only surfaces in logs or deliverability reports.

You can test whether your DKIM setup is valid using tools that check DNS record syntax. For example, ICANN’s root zone files and RFC 1035 are definitive references on what valid label syntax looks like.

To avoid issues, always use only letters, digits, and hyphens in your DKIM selectors. If you're building or auditing your authentication setup, tools like MailTester’s real-time verification API or email checker can help surface syntax problems early, before they impact deliverability.

Can underscores in DKIM s= selectors break email delivery?

Yes — underscores in DKIM s= selectors can break email delivery, even if the key and signature are technically valid. While some mail servers tolerate them, strict validators and major providers like Gmail and Outlook reject messages with underscores in the selector due to DNS standard violations. This causes authentication failures and prevents delivery, even when all other components are correct.

Why underscores in s= selectors are problematic

According to RFC 6376 (the DKIM specification), the s= selector must consist of "a sequence of printable characters" without restrictions on underscores. But in practice, DNS implementations and validation systems often treat underscores as non-compliant in certain contexts. Many modern validation systems enforce stricter parsing than the RFC allows, especially when checking for DMARC alignment.

Even if your DKIM signature verifies locally, a selector like s=mail_server_2024 may fail during DNS validation. This happens because some DNS resolvers or authentication gateways expect only alphanumeric characters and hyphens, treating underscores as malformed. When this occurs, the receiving server can’t retrieve the public key, and DKIM fails — even if the key is correct and the signature authentic.

The real risk emerges when DMARC policies are enforced. DMARC relies on DKIM alignment, meaning the domain in the From: header must match the domain in the DKIM signature. If the s= selector contains underscores and causes a DKIM failure, the DMARC check fails too — even if the message is genuinely from you.

How to prevent delivery issues

Let’s be clear: using underscores in DKIM selectors is not inherently invalid per the standard, but it’s a high-risk choice. Many large providers now flag or block messages with non-standard selectors, particularly those that use characters outside the recommended set.

If you’re unsure whether your domain’s DKIM records are compliant, check your published DNS TXT records with a tool like MxToolbox or DNSSEC.net. These tools can flag selector anomalies before they impact your deliverability.

To verify your setup and catch these issues early, you can test your domain’s authentication with a real delivery simulation. MailTester’s inbox placement test sends mail to major providers like Gmail and Outlook and reports whether DKIM and DMARC are passing. It’s a reliable way to confirm whether your selector configuration is working in practice, not just in theory.

How do strict DNS standards treat underscores in domain labels?

Strict DNS standards prohibit underscores in any domain label, including the s= selector used in DKIM records. According to RFC 1035, domain labels must contain only letters, digits, and hyphens. An underscore is invalid anywhere in a label, which means DKIM selectors using underscores will fail DNS validation.

What RFC 1035 says about label syntax

Domain labels—whether in the root domain, subdomains, or DNS record fields—must follow a strict format. RFC 1035 specifies that labels consist exclusively of letters (a-z), digits (0-9), and hyphens (-). Underscores are explicitly excluded.

This rule applies to all parts of DNS, including the s= selector in DKIM TXT records. If your DKIM selector includes an underscore—like s=mail_test—it will be treated as syntactically invalid by compliant resolvers, leading to verification failures.

Why this matters for DKIM and email deliverability

DKIM relies on DNS TXT records to verify sender authenticity. If the s= selector contains an underscore, even a well-formed record can be skipped or rejected during verification. This breaks the chain of trust, reducing your sender reputation and increasing the risk of emails being marked as spam or rejected.

For example, a selector like s=mail_test might work in experimental or relaxed parsers, but any strict DNS checker—such as those used by major providers—will reject it. This is not a minor issue; it’s a fundamental violation of DNS specifications.

Let’s be clear: you cannot use underscores in any part of a domain label in a valid DNS record. Subdomains, SPF identifiers, DKIM selectors—all follow the same rules. If your email infrastructure uses an underscore in a label, it’s technically non-compliant.

Understanding this helps explain why some DKIM implementations fail silently or inconsistently. The root cause isn’t a misconfigured server or bad SPF—it’s invalid DNS syntax. You can use a tool like the email checker to validate the syntax of your DNS records before deployment, ensuring alignment with industry standards.

What happens when DKIM records fail due to invalid selectors?

If your DKIM selector uses an underscore (like s=example_user), the receiving server may reject the DNS lookup entirely due to invalid character usage in the DNS label. DKIM selectors must be valid DNS labels—only letters, numbers, and hyphens are allowed. When the selector fails DNS validation, the server can’t retrieve the public key, the signature can’t be verified, and authentication fails.

Why invalid selectors break DKIM checks

DKIM relies on a public key stored in DNS under a specific selector. DNS labels — like the part before the domain in example._domainkey.example.com — cannot contain underscores. If your selector includes an underscore, the DNS query itself may return NXDOMAIN or fail to parse, meaning no verification can happen.

Let’s say your selector is s=mail_test. The server looks for mail_test._domainkey.example.com, but the DNS system treats mail_test as an invalid label. Result: no key, no signature check, and failure at the DKIM layer.

Consequences for email delivery and reputation

If your domain uses DMARC with a policy of p=reject, every message with a failed DKIM check gets blocked outright. This means your email won’t reach the inbox — even if the content is legitimate. DMARC is designed to enforce alignment, so a broken DKIM breaks the chain.

Even if DMARC is set to p=none, a consistent failure to authenticate still harms your sender reputation. Receiving servers track aggregate authentication success rates. Repeated DKIM failures signal poor sending hygiene, increasing the chances your messages end up in spam or get throttled.

According to RFC 6376, which defines DKIM, selector names must follow DNS label rules — no underscores, no special characters. The DKIM specification requires selectors to be "a string that consists of valid DNS label characters only."

Before sending, you can validate your DKIM setup using a tool like MailTester’s email checker. It tests not just syntax but real DNS resolution and authentication chain integrity. If you're managing a large sending list, use the bulk verification tool to catch invalid configurations across thousands of addresses — including malformed DKIM selectors — before they damage deliverability.

How to verify if your DKIM s= selector uses invalid characters?

You can check if your DKIM s= selector uses invalid characters by inspecting the TXT record published under _domainkey.yourdomain.com using a DNS lookup tool. If the selector (the value after s=) contains underscores, spaces, or other special characters, it violates DNS standard requirements, even if the record resolves successfully. This can cause email rejection or filtering by strict mail servers.

Step-by-step verification

  1. Go to a real-time DNS lookup tool like MxToolbox or use the command-line dig tool.
  2. Enter the query: txt _domainkey.yourdomain.com (replace yourdomain.com with your actual domain).
  3. Locate the TXT record that starts with v=DKIM1;. The selector is defined by the s= parameter within the record.
  4. Look at the value after s=. If it includes an underscore (_), a space, or any character outside the allowed range (letters, digits, hyphens), it's non-compliant with RFC 6376.
  5. For example, s=mail_server_1 is invalid due to the underscore. Valid selectors must use only lowercase letters, digits, and hyphens (e.g., s=mail1 or s=2024).

Why this matters

Some email systems enforce strict DNS parsing rules. Even if your selector resolves, a non-standard character like an underscore will break parsing on systems that follow RFC 6376 strictly. This causes DKIM signature validation to fail, leading to delivery issues or messages marked as spam.

Common invalid examples include s=prod_user, s=marketing@, or s=123_abc. These are not rejected by all providers, but they risk failure on major platforms where compliance is enforced.

If you're managing a large list and want to preempt delivery problems, use a tool like MailTester’s bulk verification to check entire domains against email validation standards, including DKIM compatibility and syntax rules, before sending.

Why email verification tools can't catch invalid DKIM selectors — and what they can do instead

DKIM selectors with underscores aren’t invalid per se, but they can fail if they don’t conform to DNS standards like those in RFC 6376. Email verification tools like MailTester check syntax, deliverability, and basic mailbox health — not whether a selector adheres to DNS label restrictions. You can’t verify DNS compliance via standard email validation; it requires direct DNS checks.

What email verification tools actually verify

Tools such as MailTester focus on whether an address is valid, actively receives mail, and avoids common red flags like typos or disposable domains. They test if a user can be reached, not whether your DKIM record conforms to the RFC’s requirement that DNS labels must be lowercase and may not contain underscores.

Let’s be clear: you can have a technically valid email address with a DKIM selector like s=foo_bar that’s still invalid under DNS. This isn’t something email verification tools catch — they don’t parse the DNS layer for RFC compliance.

When you need to check DNS record compliance

Checking whether a DKIM selector is compliant with strict DNS standards requires tools that query DNS directly — not just validate delivery. A selector with underscores, like s=foo_bar, violates DNS label rules because underscores are not allowed in DNS labels, even if they’re used in some email systems.

That’s why, for example, RFC 6376 specifies that selector names must be valid DNS labels — which means only letters, numbers, and hyphens. You can’t enforce this in email validation tools because they don’t touch the DNS record itself.

Instead, you should check DKIM configuration with tools like MXToolbox or command-line utilities like dig or nslookup. These allow you to pull the actual DKIM TXT record and inspect its syntax directly — including selector names — without relying on whether the mailbox delivers.

That said, tools like MailTester can still help you avoid sending to addresses with broken configurations. For example, if a user’s email fails deliverability checks — or if their domain doesn’t respond to a verification attempt — that’s a strong indicator of larger issues, even if they’re not directly tied to the selector format.

How to fix a DKIM selector with underscores

Replace any DKIM selector containing underscores with a name using only letters, digits, and hyphens—like default or key-2026. Update your DNS TXT record, re-sign outgoing messages, and wait 48–72 hours for propagation. Monitor deliverability results with inbox-placement testing tools to confirm fixes.

Step-by-step fix

  1. Choose a valid selector name using only lowercase letters, digits, and hyphens. Avoid underscores, spaces, or special characters. Examples: mail, default, key-2026. This ensures compatibility with strict DNS standards, including RFC 6376, which defines the syntax for DKIM signatures.
  2. Update your DNS TXT record with the new selector. You must modify the DKIM record in your domain's DNS zone—typically hosted by your registrar or DNS provider. The record should be formatted as selector._domainkey.yourdomain.com, where selector is your chosen name. Use tools like MXToolbox to verify syntax and propagation.
  3. Re-sign all outgoing messages using the new selector. Your email system (e.g., SendGrid, Mailgun, Microsoft 365) must re-sign every outgoing email with the updated DKIM key. Failure to do so results in failed validation and increased spam tagging.
  4. Wait for DNS propagation and verify changes. DNS changes can take 48–72 hours to fully propagate globally. During this time, monitor email deliverability. Use MailTester’s inbox-placement testing to assess whether messages are landing in inboxes, not spam folders.

Monitoring and validation

After switching, test your setup by sending a handful of messages to known inbox providers (Gmail, Outlook, Yahoo). A failed signature or authentication error often points to a misconfigured selector. Use a tool like RFC 6376 to validate that your signature structure conforms to standard formats. You can also use MailTester’s email checker to test individual addresses before sending.

What are some best practices for DKIM selector naming?

You should use simple, RFC-compliant DKIM selector names like default, mail, or key1 — avoid underscores, dots, or any special characters. Selectors must be consistently applied across all domains and mail servers, and documented internally to prevent conflicts. This ensures compatibility with strict DNS standards and prevents validation failures.

Follow RFC guidelines rigorously

  • Use only lowercase letters, numbers, and hyphens — no underscores or dots — in your DKIM selector names.
  • Stick to short, meaningful names like default or mail; avoid naming schemes that include dates, versions, or random strings.
  • Double-check your DNS TXT record syntax using a tool like MxToolbox or RFC 6376, which defines how DKIM selectors must be formatted.

Maintain consistency and internal clarity

  • Apply the same selector across all domains and sending systems to eliminate ambiguity and reduce configuration drift.
  • Document your DKIM selector strategy in internal playbooks or team wikis — this prevents reuse of expired keys or accidental misconfiguration.
  • When rotating keys, update the selector name and DNS record in a coordinated way, and monitor deliverability changes immediately after.
  • Use the bulk email verification tool to test whether your senders are still delivering after a selector change, especially if you’re verifying large lists post-configuration.

Even small errors in selector formatting can break DKIM validation, leading to rejected emails or spam filtering. Let’s keep things simple: short, consistent, and compliant.

MailTester won’t validate DKIM selector syntax like s=selector_with_underscores, because it doesn’t parse DNS records for RFC compliance. But it does test whether emails actually land in inboxes—using real mailboxes and real delivery metrics—so you’ll see the real-world impact of bad DKIM, like low inbox placement or high bounces, even if the syntax is technically invalid.

What MailTester actually checks

You might use a DKIM selector with underscores, thinking it’s fine—until your messages keep hitting spam folders or failing to deliver. MailTester doesn’t care about that specific syntax, but it does care about results. It sends test emails to real inboxes across major providers (Gmail, Outlook, Yahoo) and measures real delivery outcomes. If your DKIM setup is broken—whether due to incorrect syntax, misconfigured keys, or missing alignment—deliverability suffers. MailTester will flag that through its inbox placement reports.

For example, if your DKIM signature fails validation, many receivers silently drop your email or tag it as suspicious. This isn’t shown in DNS tools. But MailTester captures it: low inbox placement, high spam complaints, or delayed delivery. You’re not just testing whether a record exists—you’re testing whether it works.

Why syntax doesn’t matter as much as impact

Per RFC 6376, DKIM selectors should only use ASCII letters, digits, and hyphens—underscores are not allowed in the official standard. But enforcement varies. Some mail providers ignore malformed selectors; others reject emails outright. The outcome isn’t uniform. That’s why MailTester prioritizes real delivery data over theoretical DNS checks.

Let’s say you’re using s=webmaster instead of s=mail, or worse, s=selector_with_underscores. A DNS validator might flag that, but a real email won’t. MailTester sends the email anyway. If the inbox doesn’t receive it, the result is clear: something’s broken—and likely it’s DKIM.

For deeper insight into how email authentication impacts delivery, you can review the DKIM specification (RFC 6376). While it confirms selector restrictions, the real test is whether messages get read, not whether a record passes a syntax check.

If your email list has high bounce rates or low open rates, your DKIM setup could be part of the problem—even if it’s “valid” by DNS rules. MailTester helps you find that out without needing to debug DNS by hand. Use it to test entire lists, send one-off checks, or run automated inbox placement tests. See real inbox placement results across providers before you send.

The bottom line: Keep your DKIM s= selectors compliant with DNS standards

Using underscores in DKIM s= selectors violates DNS standards and can trigger authentication failures, even if your emails currently deliver.

Non-compliant selectors increase the risk of future delivery issues, especially as receiving servers enforce stricter validation policies over time.

Stick to letters, digits, and hyphens in your DKIM selectors to ensure consistent authentication and reliable inbox placement.

Sources

Keep reading

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

Frequently asked questions

Can a DKIM s= selector with an underscore still work?

It may work in some environments, but violates DNS standards. Strict validators may reject it, breaking DKIM alignment and harming deliverability over time.

Does MailTester check DKIM record validity?

No — MailTester verifies email addresses, not DNS record syntax. It can detect delivery failures caused by bad DKIM but not the root cause.

Is there a standard for DKIM selector names?

Yes — selectors must follow DNS label rules: only letters, digits, and hyphens. Names like 'default' or 'mail' are commonly used and compliant.

What happens if my DKIM record has an underscore in the selector?

The record may fail during strict DNS validation, resulting in DKIM failure. This can lead to message rejection or reduced inbox placement, especially under DMARC enforcement.

How do I test if my DKIM selector is RFC-compliant?

Use DNS lookup tools like MxToolbox or Dig to view the TXT record. Check that the selector (s= value) contains only letters, digits, and hyphens.

Can a DMARC failure be caused by an invalid DKIM selector?

Yes — if your domain enforces DMARC with a policy of p=reject, a failed DKIM check due to an invalid selector can result in message rejection.

Do major email providers check DKIM selector syntax?

Yes — Gmail and Outlook perform strict DNS validation. Non-compliant selectors, including those with underscores, can lead to authentication failure.

How long does it take to fix a DKIM selector issue?

After updating the selector and re-signing messages, DNS propagation takes 48–72 hours. Monitor deliverability with tools like MailTester’s inbox placement tests.

Is it safe to change a DKIM selector in production?

Yes, if done carefully. Re-sign all outgoing mail with the new selector and ensure DNS is updated before any email is sent with the new key.

Why do some tools still allow underscores in DKIM selectors?

Some legacy or internal tools may not enforce DNS standards strictly. That doesn’t make them correct — only that they’re lenient in practice.

Can invalid DKIM syntax affect sender reputation?

Indirectly — repeated DKIM failures due to malformed records can lower reputation over time, increasing the chance of spam filtering or blocklisting.

What’s the most common DKIM selector mistake?

Using underscores, spaces, or special characters in the s= selector. The best practice is to use only letters, digits, and hyphens.