Why Strict DNS Servers Reject DKIM TXT Records

What happens when your DKIM record is rejected by DNS?

You send a message, confidently authenticated — but it lands in the spam folder, or vanishes entirely. Why? A single character in your DKIM record might be the culprit.

DKIM relies on DNS to verify your email’s authenticity. If your DNS server rejects the TXT record due to strict syntax rules — particularly around the s= tag — the whole chain breaks. The message isn’t just delayed. It’s marked as untrusted.

The issue? The s= tag, which defines the signing selector, is often misconfigured. Using an underscore in the selector value — like s=mail_2024 — violates RFC 6376. Some DNS servers, especially those with strict parsing, will reject such records outright, even if the rest of your configuration is sound.

Key takeaways

Strict DNS servers reject DKIM TXT records with underscores in the selector value, even if the record is otherwise correct.
Undercored selectors in the s= tag violate RFC 6376 syntax rules, making the record non-compliant.
Even minor syntax violations in DKIM records can lead to email authentication failures and reduced inbox placement.

Why do strict DNS servers reject DKIM TXT records with underscores in s=?

Strict DNS servers reject DKIM TXT records with underscores in the s= parameter because the selector must follow RFC 6376, which allows only letters, digits, hyphens, and periods. Underscores are not permitted, and servers enforcing this rule will silently reject any record containing invalid characters. This means a malformed DKIM record can break email authentication, increasing the risk of messages being flagged or blocked.

The s= parameter and its rules

The s= field in a DKIM TXT record is the selector — a unique identifier that tells receiving servers which public key to use. Think of it like a keyring label: it must be clear, consistent, and follow strict naming rules. If you use an underscore, like s=mail_test, you’re violating RFC 6376, the standard governing DKIM.

Let’s be clear: this isn’t a recommendation. It’s a hard rule. The RFC explicitly states that the selector must be a valid DNS name, meaning only letters (a-z), digits (0-9), hyphens (-), and periods (.) are allowed. Underscores are not in that list.

How DNS servers enforce the standard

Modern DNS implementations, especially those used by major email providers, are built to validate DNS data strictly. When a record like example._domainkey.example.com is queried, the server checks not only that the record exists but also that the s= value is syntactically valid. An underscore breaks that syntax, so the entire response is rejected.

This rejection isn’t just theoretical — it’s common in production environments. For example, Microsoft’s email infrastructure and Google’s Gmail servers both enforce these standards. If your DKIM record includes an underscore, your domain may fail authentication even if your key is otherwise correct. That means deliverability drops, spam scores rise, and inbox placement suffers.

To verify your DKIM record quickly and accurately, you can test it with our inbox placement tester. It checks the entire setup, including DNS validation, and flags issues like invalid selectors before you send a single email.

Fixing this is simple: replace underscores with hyphens. Use s=mail-test, not s=mail_test. Then re-publish the TXT record and test again. This isn’t just about compliance — it’s about trust, and trust starts with correct DNS.

Where does the s= parameter come from in DKIM configuration?

The s= parameter in a DKIM TXT record comes from the selector you choose when generating your DKIM key pair. It identifies which private key was used to sign a message and links it to the public key published in DNS. You set it manually when configuring DKIM—common choices like s=dkim or s=mail work fine. But using underscores, such as s=mail_test, violates DNS standards and causes strict DNS servers to reject the record.

How the selector is chosen

When you generate a DKIM key pair, the selector (the part after s=) is whatever you name it. Most email providers set it automatically—like Google using s=google or SendGrid using s=sg. If you’re using a custom domain or managing your own mail server, you pick it. Stick to letters, numbers, and hyphens. Underscores are not allowed in DNS TXT record values.

Let’s say you’re setting up DKIM for example.com and pick s=mail_test. Even if the key is valid, the DNS server will reject the record because _mail_test._domainkey.example.com contains an underscore in the label part. This breaks the DNS standard, which only allows alphanumeric characters and hyphens in names.

Why strict DNS servers block underscore-based selectors

Strict DNS servers, especially those used by large ISPs and anti-abuse systems, follow RFC 1035 and RFC 1101 closely. These documents define the syntax for DNS labels—not just domain names, but every component of a record’s name. According to those standards, an underscore is invalid in a DNS label.

This means that even if your DKIM signature is cryptographically sound, a record with an underscore in s= will fail DNS validation. The server won't even see the TXT content. This causes DKIM verification to fail, which can hurt your sender reputation and lead to messages being marked as spam or rejected outright. You can check this behavior using tools like MXToolbox or DNS-SD for real-world testing.

Using safe values like s=2025 or s=mail avoids this issue entirely. These are commonly used in production setups and are fully accepted by all compliant DNS resolvers. If you're verifying DKIM configurations, use MailTester’s inbox placement tester to simulate how your messages perform across major email providers and catch issues like this before they impact deliverability.

How do invalid DKIM selectors affect deliverability?

Invalid DKIM selectors—like those with underscores in the s= field—break email authentication. Receiving servers reject messages with malformed DKIM records, which damages sender reputation, increases spam filtering, and hurts inbox placement. Even a single incorrect record across your domain can trigger broader deliverability warnings from major providers.

Why DKIM failures hurt your inbox placement

When you use a non-standard or invalid selector in a DKIM TXT record—especially one with an underscore in the s= tag—the receiving server can’t verify your domain’s authenticity. This isn’t just a technical hiccup; it’s a red flag to mailbox providers like Gmail, Outlook, and Apple Mail. They rely on correct DKIM to distinguish legitimate senders from spammers.

Without valid DKIM, your messages may be marked as suspicious or blocked entirely. This isn’t an isolated issue. If your domain has even one misconfigured record, it can trigger a broader alert in systems like Spamhaus or MXToolbox, which track domain-wide reputation. That means one bad selector can affect all your emails—even those sent correctly.

According to RFC 6376 (the standard for DKIM), the s= tag must follow specific syntax rules. Using underscores is not allowed, and many strict DNS parsers reject such entries outright. If the record is malformed, the signature fails validation during the SMTP handshake, and the email is treated as unverified.

Let’s be honest: even a small syntax error in a TXT record—like an underscore in s=—can cause real harm. It’s not just about being technically correct; it’s about being trusted by the inbox ecosystem. A single failure can reduce your engagement rates and increase the odds your emails land in spam.

That’s why checking your DKIM configuration before sending is critical. Tools like the MailTester email checker can validate the full DNS setup—including the syntax of your DKIM records—before you send a single message. It’s a quick way to catch invalid selectors, incorrect keys, or malformed TXT entries that could sabotage your campaign from the start.

How to verify and fix DKIM TXT records before deployment

You must ensure your DKIM TXT record’s s= value contains only lowercase letters, digits, hyphens, and periods. Any underscore, uppercase letter, space, or special character will cause strict DNS servers to reject the record. Always validate the full record in public DNS before deployment to prevent delivery failures. Use real-time tools to confirm resolution and alignment with RFC standards.

Step-by-step verification process

Use a real-time DNS lookup tool like MxToolbox or DNSChecker.org to verify how your DKIM TXT record resolves across multiple global DNS servers.
Check that the s= value in your record contains only lowercase letters, digits, hyphens, and periods. Do not use underscores—they are not permitted by the DKIM specification. For example, s=mail is valid; s=mail_user is not.
Ensure the entire TXT record is formatted correctly, including the correct selector name, matching the one used in your DKIM signing process. A mismatch here breaks verification.
Test the configuration using your email provider’s diagnostic tools—such as those in Microsoft 365, Google Workspace, or SendGrid’s SMTP debug logs—to confirm the record is recognized and validated.
If errors arise, correct the s= value and re-publish the TXT record. Wait up to 48 hours for global DNS propagation, but test immediately after update with a live lookup tool.

What happens when you violate DKIM rules

Strict DNS servers—especially those enforcing RFC 6376 conformance for DKIM—will reject any TXT record that includes non-compliant characters. This includes underscores, spaces, uppercase letters, or unescaped special characters in the s= field. Even a single invalid character can cause the entire record to be ignored.

For example, if you publish s=mail_user, DNS resolvers may interpret it as invalid syntax, leading to failed DKIM signature checks and message rejection by receiving servers. This can degrade sender reputation and cause deliverability issues across large providers like Gmail, Yahoo, and Outlook.

Always verify your full DKIM record setup before sending emails at scale. Use MailTester’s email checker to spot potential issues in your domain setup, including DKIM misconfigurations, before they impact delivery.

How MailTester helps prevent DKIM record errors before mail goes out

You can avoid DKIM record failures caused by underscores in the s= selector by validating your DNS configuration before sending. MailTester checks your domain’s SPF, DKIM, and DMARC records during bulk email list verification, flagging improperly formatted selectors—like those with underscores in the s= value—before they cause delivery issues. This catches problems early, reducing bounces and protecting sender reputation.

Why the `s=` selector matters

DKIM uses a selector (the s= tag in the TXT record) to identify the private key used to sign emails. While RFC 6376 allows most characters in selectors, some strict DNS servers reject those with underscores because they’re not universally permitted in DNS labels. An invalid selector breaks DKIM validation, leading to rejected or marked-as-spam messages, even if the rest of your email setup is correct.

How MailTester detects and prevents these errors

When you run a bulk list verification with MailTester, it doesn’t just check if an address is valid—it validates the full DNS infrastructure linked to your domain. This includes scanning your DKIM records for non-compliant syntax, including underscores in the s= value. If found, MailTester flags the record as "risky" or "invalid" with a clear explanation. You’ll know exactly what needs fixing before sending.

For example, a selector like s=main_2024 might pass some validators but fail on strict DNS servers. MailTester surfaces this risk. With 98.9% accuracy, it identifies configuration flaws that could otherwise lead to poor inbox placement or sender reputation damage.

Let’s say you’re sending a campaign and use MailTester’s bulk list verification. It runs a real-time check across your domain’s DNS records, not just the email addresses. This gives you confidence that your DKIM setup is compliant with industry standards—no surprises after you hit send.

It’s not just about avoiding one error. It’s about maintaining healthy infrastructure. According to the IETF’s RFC 6376, DKIM selectors must follow DNS label conventions. While the spec allows broad character ranges, real-world DNS servers vary in their interpretation. MailTester helps you stay aligned with the most robust standards, not just the theoretical ones.

By catching these issues early, you reduce the risk of deliverability issues caused by broken authentication. You’re not just checking email addresses—you’re auditing your entire sending environment.

Common DKIM configuration mistakes that go undetected

Strict DNS servers reject DKIM TXT records with underscores in the s= selector because they break RFC 6376’s requirement that selectors be DNS-compatible. The s= field must use only letters, digits, and hyphens—underscores are invalid and cause parsing failures. This leads to DKIM verification failures even if your key is correct. Let’s walk through other silent errors that slip past checks.

Selector syntax: the hidden trap

Using s=mail_test instead of s=mail-test violates DNS standards. The underscore is not allowed in DNS labels. Even if you see the record in DNS, strict resolvers silently discard it.
Mixing case in the selector—like s=MailDKIM—can cause problems. While DNS is case-insensitive in practice, some systems enforce lowercase only. Keep selectors lowercase to be safe.

Formatting errors that break verification

Extra spaces at the start or end of the TXT value (e.g., "v=DKIM1; k=rsa; p=... ") will trigger validation failures. The TXT record must be clean and trimmed.
Trailing punctuation—like a comma, period, or semicolon—outside the quoted value can break parsing. Ensure only valid DKIM syntax is used, and avoid non-RFC-compliant characters like @, $, or # in any part of the record.

DNS resolvers often don’t reject malformed records outright—they just ignore or misread them. This means your DKIM key appears valid in a scan but fails in practice. The issue isn't detected until emails bounce or get flagged as unauthenticated.

According to the RFC 6376 specification, selectors must be "DNS names" with valid labels. Any character outside letters, digits, and hyphens is non-compliant, which is why underscore usage triggers rejections. You can verify your record’s syntax using public tools like PowerAdmin or MXToolbox to test TXT responses.

For teams that send at scale, catching these errors early saves time and reduces bounce rates. Use a real-time email verification service to catch these issues during list management. With MailTester’s single email checker, you can validate individual addresses—including their DKIM readiness—before sending.

What happens if a DKIM record is rejected by a receiving server?

If a receiving server rejects a DKIM TXT record due to an underscore in the s= tag, it cannot validate the signature. This means the message fails authentication, which can trigger spam filters, reduce sender reputation, and result in delivery to spam or outright rejection—especially with strict inbox providers like Gmail or Outlook. Even one failed authentication can hurt long-term deliverability.

Authentication failure leads to deliverability risks

When a receiving server encounters a malformed DKIM record—such as one with an underscore in the s= field—it may reject the entire DNS lookup. Since DKIM relies on the strict structure defined in RFC 6376, any deviation (like using an underscore in the selector) can break the validation process. The server then treats the message as unauthenticated, even if all other headers are correct.

Spam filters, which use DKIM validation as one signal, may flag the message as suspicious if no valid signature is found. This increases the risk of the email landing in spam folders or being blocked entirely. Reputable providers often monitor these failures closely and may begin to lower trust in a domain’s sending reputation after repeated authentication failures.

Impact on sender reputation and inbox placement

Even if the email isn't outright rejected, repeated failures can erode sender reputation over time. Inbox providers like Gmail or Microsoft Outlook use historical delivery patterns and authentication success rates to assess the legitimacy of a sender. A domain with consistent DKIM issues may be tagged as risky, resulting in throttled delivery, reduced inbox placement, or manual review.

The same applies to bulk email sends. If you're sending to thousands of addresses and your DKIM record is invalid due to improper formatting, you’ll see higher bounce rates and more messages routed to spam. According to industry best practices documented by the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), non-compliant DKIM records are a known contributor to poor delivery outcomes.

Use tools like mail testing services to catch issues before sending. A full email list verification can help identify problematic domains and prevent authentication failures at scale. Run your list through MailTester’s bulk verification to ensure your DKIM records and address validity align with receiving server expectations.

How to test your DKIM record in real time

You can verify your DKIM TXT record in real time using command-line tools like dig or nslookup. Run a query for your domain’s TXT records with the selector name, check that the output matches the correct DKIM format, and ensure the s= value uses only valid characters—no underscores. This step confirms your DKIM setup is technically correct before sending emails.

Test your DKIM record step by step

Run a DNS query using dig or nslookup. For example: dig TXT your-selector._domainkey.yourdomain.com. This pulls the actual DNS record as seen by receiving servers.
Inspect the output for the v=DKIM1; k=rsa; p=... format. A valid DKIM record starts with v=DKIM1 and includes your public key via p=. The s= tag is required and must be a valid selector.
Check the s= value carefully. It must contain only letters, numbers, and hyphens. An underscore (e.g., s=selector_1) is invalid and causes strict DNS servers to reject the record—this is specified in RFC 6376, the standard for DKIM.
Validate the result by comparing it against your configuration. If the s= value has an underscore, update the record in your DNS provider's console and re-run the test.
Re-run after changes immediately. DNS propagation can take minutes, so test again after updating to ensure the new record is live and properly formatted.

Why this matters beyond syntax

Even a single incorrect character in your DKIM record—like an underscore in the selector—can cause authentication failure. Receivers like Gmail or Yahoo will reject messages with invalid DKIM signatures, harming sender reputation and inbox placement. Testing in real time, before sending email campaigns, prevents this.

“A correctly signed DKIM record is a baseline requirement for deliverability. Without it, even perfectly written content can be blocked.”

Use tools like MailTester’s email checker to test both individual addresses and DNS records in bulk. Our system evaluates DKIM, SPF, and DMARC configurations as part of inbox placement verification—giving you real-time insight into how your messages will be treated across mail providers.

Final takeaway: validation before deployment stops problems

Invalid DKIM records — especially those with underscores in the s= tag — are a silent deliverability killer. Even a single malformed record can trigger rejection by strict DNS servers, leading to failed authentication and inbox placement issues.

Testing your DNS configuration, including DKIM, SPF, and DMARC, before sending ensures that all records are correctly formatted and validated. This prevents authentication failures that otherwise only surface after emails are in flight — too late to fix.

Tools like MailTester offer real-time verification and bulk checks to catch these errors early. By validating DNS settings and email addresses together, you reduce bounce rates, avoid spam traps, and maintain sender reputation.

Sources

Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)
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)

Keep reading

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

Frequently asked questions

Can underscores in DKIM selectors cause email delivery failure?

Yes. Strict DNS servers reject DKIM TXT records containing underscores in the s= selector because it violates RFC 6376 requirements. This results in failed authentication and poor deliverability.

What characters are allowed in the DKIM s= selector?

Only lowercase letters, digits, hyphens, and periods are permitted. Underscores, uppercase letters, spaces, and special characters are not allowed.

How can I check if my DKIM record is properly formatted?

Use a DNS lookup tool like MxToolbox or dig to inspect your domain’s TXT records. Confirm the s= value uses only valid characters as defined in RFC 6376.

Does MailTester test DKIM records?

Yes. MailTester includes DNS-level validation during bulk list verification, checking DKIM, SPF, and DMARC configurations for correctness and compliance.

Why does MailTester have 98.9% accuracy in verification?

MailTester uses real-time SMTP and DNS validation, not just heuristics. It tests actual email infrastructure behavior, providing highly accurate feedback on domain and address health.

Can one bad DKIM record affect my entire domain’s reputation?

Yes. A single malformed DKIM record can trigger broader authentication failures, leading to reduced trust from inbox providers and degraded deliverability.

Are there any tools that automatically detect underscore issues in DKIM?

Yes — MailTester and other advanced email verification services flag invalid DKIM selectors, including those with underscores, during domain and list audits.

What’s the best practice for setting a DKIM selector?

Use a simple, lowercase identifier like s=dkim or s=mail. Avoid underscores, numbers at the start, or non-RFC-compliant characters.

Why does RFC 6376 ban underscores in DKIM selectors?

RFC 6376 specifies a strict syntax for TXT records to ensure consistent parsing across all DNS resolvers. Underscores are not part of the defined character set for selectors.

Can I fix a rejected DKIM record after delivery issues occur?

Yes — update the DNS TXT record with a valid s= value, wait for propagation, and retest. But repair after failure is riskier than prevention via early validation.

How many free verifications does MailTester offer?

MailTester offers 100 free verifications to start. Purchased credits never expire, allowing you to test domains, lists, and configurations on demand.

Does MailTester integrate with email platforms like SendGrid or HubSpot?

Yes. MailTester integrates with Mailchimp, HubSpot, Klaviyo, and SendGrid to automate list hygiene and pre-send verification, reducing bounce rates and improving deliverability.