Why does a single underscore in your DKIM selector cause email rejection?

You sent an email that failed to land in the inbox — no bounce, no alert, just silence. You check your domain records, everything looks correct. But the sender reputation is still shaky. The culprit might be hiding in plain sight: an underscore in your DKIM selector.

DKIM selectors are part of the DNS TXT record used to verify email authenticity. They must follow strict naming rules. Even a single underscore in a non-standard position can break the signature validation process, leading to rejection by major providers like Gmail, Outlook, or Yahoo.

You might assume underscores are safe in domain identifiers — but in DKIM, placement matters. Misplaced underscores disrupt the cryptographic verification process, causing senders to be flagged as untrustworthy. This isn’t a minor glitch. It’s a hard rejection.

Key takeaways

  • DKIM selectors must follow strict naming conventions — underscores are allowed only in specific, standardized positions.
  • Improperly placed underscores can break DKIM signature validation, leading to automatic email rejection by major providers.
  • Even small DNS configuration errors like this can harm sender reputation and reduce inbox placement, despite otherwise correct email setup.

What exactly is a DKIM selector, and why does its format matter?

A DKIM selector is a unique identifier in your domain’s DNS that points to the public key used to validate DKIM signatures in incoming emails. It’s part of both the DKIM-Signature header and the DNS TXT record (e.g., mail._domainkey.example.com). The format matters because DNS label components—like the selector—must only use letters, digits, and hyphens; underscores are not allowed by the standard and can cause signature validation failures, leading to email rejection.

How selectors work in real-world email flow

When your email server signs a message with DKIM, it includes a selector in the signature header. The receiving mail server looks up the corresponding DNS record using that selector to fetch the public key and verify the signature. If the selector contains an underscore, it might not resolve properly because DNS labels must follow strict naming rules.

For example, a selector like selector_1 or newsletter_user violates the DNS specification. While some older or lenient systems might still accept it, modern mail servers (including Gmail, Outlook, and SendGrid) strictly enforce DNS label rules. This can result in your emails being dropped or marked as spam due to a signature validation failure.

Let’s be clear: underscores in DKIM selectors are not just a best practice—they’re a violation of DNS standards. According to RFC 1035, DNS labels must only contain letters, digits, and hyphens. Even if a system temporarily accepts an underscore, you’re gambling on inconsistent behavior across receiving providers.

Digital hygiene: validate your selector format before sending

You can’t rely on assumptions. Misconfigured selectors are a common cause of DKIM failures, even when other parts of your setup are correct. Before launching a campaign, double-check your DNS records using tools like MxToolbox or DNSChecker.org.

If you're managing a large mailing list or automated senders, you can verify your entire domain's DKIM configuration with a tool like MailTester’s bulk email verification. This checks not just syntax but also deliverability signals like DNS record completeness and alignment with standards like RFC 6376.

How does an underscore in the selector trigger rejection?

Using an underscore in a DKIM selector violates RFC 1035, the standard governing DNS label syntax. DNS labels may only contain letters, digits, and hyphens. An underscore is not allowed, and any DNS lookup with one will fail. Mail servers that enforce strict DNS validation reject the DKIM signature, leading to your message being filtered or outright rejected.

DNS labels must follow RFC 1035 rules

DNS labels — including DKIM selectors — are restricted to a narrow character set: lowercase letters, digits, and hyphens. This is not arbitrary; it's codified in RFC 1035, the foundational document for DNS. Any deviation, like inserting an underscore, breaks the syntax. The DNS resolver treats the label as malformed and returns a failure.

Let’s say your selector is mail_2024. The underscore is a syntax error. Even if the rest of the DKIM setup is flawless, the receiving server won't be able to resolve the public key. Without that key, the signature can’t be verified — and the message falls through the cracks.

Strict validation means rejection, not forgiveness

Modern mail servers, especially those handling high-volume traffic (like Gmail, Outlook, or enterprise gateways), apply strict DNS validation. They don’t skip over malformed labels — they reject them outright. This behavior is consistent across industry-standard practices and reflects the need for predictable, interoperable systems.

According to the Internet Engineering Task Force (IETF), which maintains the DNS standards, invalid labels must not be processed. You can find the full specification in RFC 1035. If a label fails parsing, no further steps are taken. This includes signature validation.

Even minor syntax errors in your selector — like a single underscore — can break deliverability. And once a message fails DKIM verification due to a malformed selector, it's often flagged as spam or silently dropped. There’s no second chance.

Check your DKIM selectors before they go live. Use MailTester’s email checker to validate the full DNS structure of a domain, including DNS records like DKIM, SPF, and MX. It’s one of the fastest ways to catch issues like illegal characters before they hurt your sending reputation.

How to validate your DKIM selector value to prevent underscore issues?

You can validate your DKIM selector value by checking its TXT record via DNS lookup tools like dig or online services. Ensure the selector part of the record (e.g., selector._domainkey.example.com) uses only letters, numbers, and hyphens. Avoid underscores entirely—some email systems reject DKIM signatures if the selector contains them, especially when generated automatically by platforms or scripts. Double-checking helps prevent delivery failures before they happen.

Check your DKIM selector using DNS tools

  • Run a DNS lookup on the full selector record: dig TXT selector._domainkey.example.com.
  • Verify the returned TXT record contains a valid DKIM signature with the correct selector prefix.
  • Use tools like MXToolbox or Google’s public DNS for quick verification without command-line access.

Validate selector character rules and format

  • DKIM selectors must contain only letters (a-z), numbers (0-9), and hyphens (-).
  • Underscores (_) are not permitted by RFC 6376 and may be ignored or cause validation failures in some mail servers.
  • When generating DKIM keys via email platforms or scripts, disable any automated naming that includes underscores.
  • If you're unsure, test the selector by sending a message through a trusted email service and inspect the DKIM header in the received email.
  • Always validate before scaling email sends, especially in bulk campaigns.

Let’s make sure your DNS records are clean. You can verify DKIM settings at scale using the MailTester bulk verification tool—it checks not only syntax but also deliverability signals like sender reputation and spam risk. For real-time checks in your workflow, use the MailTester API to validate DKIM configurations during onboarding or deployment.

How to validate DKIM selector values using MailTester’s real-time API

You can validate DKIM selector values in real time using MailTester’s API by checking DNS records during email verification. If a selector contains an underscore, the API flags it as risky or invalid, since underscores in DKIM selectors are not allowed by RFC 6376. This catches configuration errors before they cause delivery failure.

How the API checks DKIM selector format

When you send an email address to MailTester’s real-time verification API, it doesn’t just check if the inbox exists—it digs into DNS records, including the DKIM TXT record. It parses the selector part (the portion before @domain in the selector record) to ensure it follows the standard format. Selectors must consist only of letters, numbers, and hyphens. An underscore breaks this rule.

For example, a selector like selector_1 will be rejected. The API returns a verdict of invalid or risky, depending on the context, so you can correct it before sending. This is crucial in high-volume email workflows where a single malformed DKIM record can trigger filtering or blacklisting.

Use cases during list management and integration testing

Let’s say you’re integrating a new email provider, setting up a new domain, or preparing a bulk send. Use the API to test a sampling of addresses and confirm that their DKIM selectors are properly formatted. This prevents surprises later when messages get rejected due to invalid authentication.

It’s not enough to have a DKIM record—its formatting must be correct. Tools like RFC 6376 specify that DKIM selectors cannot contain underscores. MailTester validates this rule automatically during verification. You’re not just checking deliverability—you’re validating compliance.

For teams automating email checks, the API integrates directly into workflows via REST endpoints. You can validate thousands of addresses in seconds, with results returned in JSON format. Use this to clean your list before sending, especially when managing domains across multiple campaigns.

Test real-world scenarios with inbox placement testing to confirm that your properly formatted DKIM records result in real inbox delivery. The API catches these issues early—before they cost you deliverability.

Real-world testing: How do providers react to underscore-containing selectors?

Major email providers like Gmail, Outlook, and Yahoo reject emails with DKIM selectors containing underscores, even if the signature appears valid in lab tests. The DNS syntax rules are strict—underscores are not allowed in selector names—and violations result in silent failures: no bounce, no error message, just undelivered emails. This makes detection difficult without a dedicated verification step.

Why underscoring breaks DKIM in practice

DKIM selectors are part of the DNS lookup process. They’re designed to be human-readable and machine-parsed, but they follow rules defined in RFC 4871, which limits selector names to letters, digits, and hyphens. Underscores violate this rule and cause the DNS lookup to fail silently. You might see a 'signature valid' result in a test tool, but the receiving server never receives the public key—so the signature verification fails regardless.

Why silent rejection is so hard to catch

Unlike a hard bounce, which tells you an address is invalid, a failed DKIM check due to an invalid selector typically results in no delivery notification at all. The email may be silently discarded or quarantined. This is common in large-scale campaigns and often goes unnoticed unless you’re actively testing inbox placement or verifying domains. Let’s say your campaign reaches 10,000 users—half might be delivered, but you won’t know why the other half didn’t show up.

Some providers, like Google’s Postmaster Tools, provide insights into delivery issues over time, but they don’t flag invalid selectors directly. You can use tools like MailTester's inbox placement tester to simulate real delivery conditions and spot whether your DKIM configuration is working across major inboxes. It checks not just whether the signature validates, but whether the DNS record is reachable and correctly formatted.

Even with correct SPF and DKIM syntax, an underscore in the selector will stop delivery before it starts. The fix is simple: use only letters, digits, and hyphens in your DKIM selector. If you're generating selectors automatically, make sure your system strips or replaces underscores. This is not a configuration nuance—it's a hard rule enforced at the protocol level.

Common scenarios where underscore errors creep in

You’ll see DKIM selector errors from underscores when automated tools paste raw selector names without checking compliance, when third-party tools generate non-standard names, or when you rename selectors during migration without verifying DNS standards. The fix? Validate the selector before deployment — especially if it contains underscores, which are allowed but must be handled correctly by your DNS provider and receiving server.

Automated template issues

  • Many email templates embed DKIM selectors directly (e.g., selector1._domainkey.example.com) without sanitization — a single underscore in a name can cause parsing issues if not properly escaped.
  • When templates are reused across domains, they may carry legacy underscored selectors that don’t conform to DNS label limits (63 characters) or expectations of receiving MTA behavior.
  • Let’s say you’re using a marketing platform that auto-embeds a selector like prod_2023._domainkey.company.com. While technically valid, not all MTAs handle underscores well, especially when combined with subdomain flattening or strict validation rules.

Third-party tool pitfalls

  • Tools that generate DKIM keys (like some SSL providers or SMTP services) may output selectors with underscores by default, often without warning. This can lead to silent failures if the DNS record is not validated.
  • When copying a key from a dashboard, you may paste the full selector — including underscores — into DNS without checking how the receiving server processes it. RFC 1035 permits underscores in DNS labels, but real-world validation varies.
  • Some email providers reject messages with selectors containing special characters, including underscores, unless explicitly allowed. Check your mail server logs or test with a tool like Spamhaus Lookup or MXToolbox to see how your domain resolves.

Migration missteps

  • Renaming a DKIM selector during a domain migration (e.g., from old._domainkey.com to new._domainkey.com) can break deliverability if the new selector conflicts with DNS caching or validation timing.
  • Changing the selector name without re-adding the DNS record properly (e.g., missing the _domainkey subdomain) results in a misconfigured DKIM setup — even if the selector has an underscore.
  • Use MailTester’s email checker to validate the full DKIM selector and its DNS resolution before sending. It checks for valid TXT record structure and resolves issues before they reach the inbox.

How to fix a DKIM selector with an invalid underscore

You must regenerate your DKIM key pair using a tool that enforces standard selector formatting—replace any underscore with a hyphen—then update your DNS TXT record. After waiting 24–48 hours for propagation, test delivery with MailTester’s inbox-placement feature to confirm the fix works. Underscores are not allowed in DKIM selectors per RFC 6376, so invalid syntax can cause message rejection.

Step-by-step: Fixing an invalid DKIM selector

  1. Use a DKIM key generator that enforces RFC-compliant syntax. Tools like OpenSSL or dedicated email security platforms will allow you to specify a selector without underscores. Let’s be clear: RFC 6376 explicitly defines selector values as text strings restricted to letters, digits, hyphens, and dots—underscores are excluded.
  2. Generate a new selector using only letters, digits, and hyphens. For example, use mail-2025 instead of mail_2025. This prevents parsing errors during email validation, especially on strict filtering systems.
  3. Update your DNS TXT record with the new selector and public key. Ensure the record matches the domain and includes the correct syntax: selector._domainkey.example.com. Replace the underscore before domainkey only if it was mistakenly used there—but that’s a different issue entirely.
  4. Wait 24–48 hours for DNS propagation. During this window, your new selector becomes globally visible. Use tools like MXToolbox to verify the TXT record resolves correctly before testing delivery.
  5. Test your email delivery using MailTester’s inbox-placement tester. This lets you send test messages to real inboxes across major providers and track whether they land in the inbox or get filtered to spam.

Why this matters

Many mail servers reject messages with invalid DKIM selectors outright. Even if your key is technically valid, a single underscore can trigger a parsing failure. This isn’t just theoretical: major providers like Gmail and Outlook enforce strict syntax checks. Fixing it early prevents bounces, sender reputation damage, and long-term deliverability issues. Once the DNS is correct and propagation complete, your messages will pass authentication checks consistently.

How MailTester helps prevent DKIM selector issues before sending

You can validate DKIM selector values—like those containing underscores—before sending by running your list through MailTester’s bulk verification or real-time API. These tools check DNS-level DKIM record structure, flagging non-standard formats such as underscores in selectors that could trigger rejection by receiving servers. This early detection prevents deliverability issues before they happen.

DNS-level checks catch selector syntax errors early

DKIM selectors must follow RFC 6376, which allows alphanumeric characters and hyphens, but not underscores. Let's be clear: while some mail servers may tolerate a selector like mail_2024, many strict validation systems reject such records outright. MailTester's system tests the full DNS record for valid syntax during verification, identifying non-compliant selectors—including those with underscores—before you send.

The platform performs these checks at scale. Whether you're processing 100 or 100,000 addresses, the verification process includes parsing the DKIM TXT record and validating the structure against known standards. It doesn’t just check if the record exists—it checks whether it’s properly formatted to avoid blocking.

Accuracy and real-world reliability

With 98.9% accuracy in detecting invalid or risky configurations, MailTester identifies not just syntax issues like forbidden characters, but also common misconfigurations such as missing tags or malformed signatures. This level of precision means fewer false positives and fewer bounces due to technical misconfigurations.

For teams integrating with SendGrid, Mailchimp, or HubSpot, the integration path is straightforward—tools like MailTester's integrations allow you to verify and clean your list before it enters your workflow. The result? Lower bounce rates and stronger sender reputation.

For individual checks, MailTester’s email checker lets you validate one address in seconds, including its DKIM readiness. For larger campaigns, the bulk verification tool processes entire lists with full DKIM validation built in. The system doesn’t just tell you if an address exists—it tells you whether it’s deliverable in practice.

While RFC 6376 defines the format, real-world delivery depends on strict compliance. By catching issues like underscoring in selectors early, MailTester reduces the risk of rejection during delivery. It’s a preventive mechanism—not a post-mortem fix.

Best practices for maintaining DKIM selector integrity

Use hyphens, not underscores, in DKIM selector names. Validate DNS records before publishing new keys. Test configurations at scale with tools like MailTester’s real-time API or bulk verifier to catch issues early. This prevents email rejection due to invalid or malformed selectors.

Hyphens over underscores: a hard rule

  • DKIM selectors must only contain alphanumeric characters and hyphens. Underscores are not permitted by the standard and will cause validation failure.
  • Even if your email service provider accepts a selector with an underscore, receiving servers may reject it due to non-compliance with RFC 6376.
  • Let’s be clear: underscores in selectors are not just discouraged — they’re a known cause of DKIM signature rejection.
  • Adopt a naming convention like default-2025 instead of default_2025 to ensure consistency and compliance.

Validate before you publish, test at scale

  • Always verify DNS entries for SPF, DKIM, and DMARC before enabling them in production.
  • Use trusted tools to scan published records for typos, format errors, or missing components.
  • When deploying new DKIM keys across large domains or lists, automated validation is essential. Manual checks fail at scale.
  • MailTester’s bulk email verification and real-time API can help you test multiple configurations efficiently and find invalid or misconfigured addresses before they impact deliverability.
  • Consider using inbox placement testing to see how your DKIM-signed messages perform in real inboxes after setup.

DKIM is only effective if the signature is correctly formed and verifiable. A single malformed character in a selector—especially an underscore—can break the entire chain. The cost of a failed signature is high: bounce, spam filtering, or complete rejection.

For detailed, real-world testing, use MailTester’s integrations with platforms like SendGrid, HubSpot, and Klaviyo to validate your setup in context and measure real-world deliverability.

Conclusion: Proper DKIM selector formatting is non-negotiable for inbox placement

A single underscore in a DKIM selector can silently break message authentication. Even if the DNS record appears valid, improperly formatted selectors often result in rejection without clear error codes.

Validation must go beyond analyzing email headers. You must check the actual DNS TXT record to confirm selector syntax and ensure it aligns with the signing domain’s policy.

Verify configurations before sending

  • Use MailTester’s real-time API to test DKIM selector formats at scale.
  • Run inbox-placement tests to confirm messages reach inboxes under real-world conditions.
  • Automate checks in your workflow to catch issues before sending to live lists.

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 DKIM work if the selector contains an underscore?

No. Underscores in DNS labels violate RFC 1035 and cause lookup failures. Mail servers reject messages with invalid selectors.

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

Use a DNS lookup tool like dig or MxToolbox to check the TXT record. Ensure the selector uses only letters, digits, and hyphens.

Does MailTester check DKIM selector format?

Yes. MailTester’s real-time verification API includes DNS-level validation, flagging selectors with invalid characters like underscores.

What happens if a DKIM selector is invalid?

The signature fails validation. The receiving server may reject the email or mark it as suspicious, reducing inbox placement.

Are underscores ever allowed in any part of DKIM?

No. The selector must follow DNS label rules. Underscores are not permitted anywhere in the DNS component of the DKIM record.

Can a malformed DKIM selector cause spam filter triggers?

Yes. Even without content issues, an invalid selector signals technical misconfiguration, which spam filters may treat as a risk signal.

Should I reissue DKIM keys if I found an underscore?

Yes. Fix the selector by replacing the underscore with a hyphen, generate new keys, update the DNS record, and test.

How long does it take to fix a DKIM selector after updating DNS?

DNS propagation typically takes 24–48 hours. Test after that window using inbox-placement tools like MailTester.

Does MailTester integrate with SendGrid or Mailchimp for DKIM validation?

Yes. MailTester integrates with SendGrid, Mailchimp, HubSpot, and Klaviyo to validate email configurations, including DKIM setup.

Is 98.9% accuracy in email verification meaningful for DKIM validation?

Yes. MailTester’s 98.9% accuracy includes DNS-level checks, making it reliable for catching DKIM issues like invalid selectors.

Can I test DKIM configuration without sending an email?

Yes. MailTester’s inbox-placement and API tests verify DKIM structure without sending messages, using real-world testing environments.

What should I do if my email service provider allows underscores in selectors?

Do not rely on it. Standard compliance is required for broad deliverability. Use hyphens to ensure compatibility across all providers.