DNS TXT Limit & DKIM Selector Max

What happens when your DKIM selector exceeds the TXT record limit?

You’ve set up DKIM for your domain. It’s been working for months. Then one day, your emails start bouncing. Or worse, they land in spam. You check the logs. The error points to DKIM validation failure — and you realize: your selector might be too long.

DNS TXT records are the backbone of email authentication. But each record has a hard limit: 255 characters per entry. If your DKIM selector — the part of the DNS record that identifies your signing key — pushes beyond that, resolvers truncate the record. The signature becomes invalid. Inboxes see that as suspicious. Inbox placement drops. Your sender reputation takes a hit.

Key takeaways

DNS TXT records cannot exceed 255 characters per entry; exceeding this limit causes truncation and DKIM failure.
DKIM selectors longer than 255 characters risk breaking the DNS record structure, invalidating email authentication.
Using shorter, predictable DKIM selectors (like "default" or "mail") avoids TXT record limits and ensures consistent inbox delivery.

How much space does a DKIM selector consume in a TXT record?

You can fit up to 63 characters in any single DNS label, including the DKIM selector. Since the selector is part of a subdomain (like default._domainkey.example.com), it contributes directly to the length of each label. The full TXT record value must stay under 255 characters, so a long selector can leave little room for the actual DKIM public key data.

DNS label limits: the real constraint

Each part of a domain name — what DNS calls a "label" — must be no more than 63 characters. The DKIM selector is one of these labels. So if your selector is longselector, it uses 12 of those 63 available characters. That might seem small, but when combined with the _domainkey label and your domain, you can hit the limit quickly.

For example, longselector._domainkey.example.com breaks down as: longselector (12), _domainkey (10), example.com (11). Total character count across labels is fine, but the full TXT record value must be under 255 characters — including the data, punctuation, and quotes. That leaves little room for long public keys.

Why length matters for DKIM implementation

DKIM records often contain base64-encoded public keys that are 100+ characters long. If your selector is very long, you might exceed the 255-character limit before fitting the key. This causes the record to be invalid or silently ignored by receivers.

The standard way to avoid this is to keep selectors short. Most use single words like default, mail, or auth. Using a short selector lets you fit the entire key within the TXT record limit, ensuring your DKIM signature validates correctly.

For reference, the Internet Engineering Task Force (IETF) defines these limits in RFC 1035 under DNS label size and record limits.

When setting up DKIM, always verify your full record (selector + key) fits under 255 characters before publishing. If you're managing a large email list or automated senders, using a service like MailTester’s bulk verification can help you catch invalid or improperly formatted records early — including those with oversized selectors or truncated key data.

Can you exceed the DNS TXT record limit without realizing it?

You can silently exceed the DNS TXT record size limit—especially with long DKIM selectors like dkim-2024-q3-prod-primary—even if each label seems harmless. When combined, these labels push the total record length beyond 255 characters, which breaks DNS validation. The result? Email appears valid during checks, but fails silently in flight due to invalid DNS records.

Why long selectors matter more than you think

Every label in a DNS name, including DKIM selector parts, contributes to the total length. A selector like dkim-2024-q3-prod-primary uses nine character labels, each adding overhead. This isn’t just theoretical—RFC 1035 explicitly defines the 255-byte limit for DNS labels, and many implementations enforce this strictly.

Even a single TXT record may contain multiple values, especially when you use multiple DKIM key sets or nested configurations. Concatenating these values increases the total size quickly. A record that’s just under the limit with one selector can easily exceed it when you add multiple keys or metadata.

How this breaks delivery silently

Many DNS resolvers and email servers will truncate or ignore TXT records that exceed 255 bytes. You may not see it in standard checks because the DNS lookup succeeds—just with partial or no data returned. The email client never receives the full DKIM signature, so the message fails verification during delivery.

This type of failure is especially hard to catch. It’s not a bounce, not a soft failure—just a silent drop into spam or rejection. It's one of the reasons why inbox placement testing matters: you can verify the address and the DNS record appears fine, but the message still never lands in the inbox.

Use tools that test the full DNS resolution path. Our inbox placement tester checks delivery from real mail servers across multiple providers and catches these kinds of hidden failures early, including issues from malformed or oversized TXT records.

How DNS labels and TXT record size interact in practice

You can hit the 255-byte limit on DNS TXT records even with moderately long DKIM selector names. A domain like longselector._domainkey.example.com already uses 45 characters. Adding the full DKIM key data—including the v=DKIM1; k=rsa; p=MIIB... part—pushes the total record size beyond DNS's 255-byte limit. Once exceeded, resolvers truncate the record, breaking DKIM validation and harming email deliverability.

DNS label length and TXT record limits are not independent

Each DNS label (the parts separated by dots) has a 63-byte limit, and the full name must stay under 255 bytes. A DKIM selector like longselector._domainkey.example.com looks harmless—45 characters is within range—but it's not the labels alone that cause trouble. It's the total length of the entire TXT record that matters.

DKIM records are not just names—they carry the full public key, which is often hundreds of bytes long. The p= value in particular is a long base64 string. When that data is wrapped inside a single TXT record, the full record can easily exceed 255 bytes, especially on large domains with multiple selectors or lengthy key material.

What happens when the limit is exceeded?

DNS resolvers truncate records over 255 bytes. The result? The receiving mail server sees only part of the DKIM signature, fails validation, and may reject or mark messages as spam. Even if the selector name is valid, a truncated DKIM record silently breaks authentication.

Let’s say you're configuring DKIM for a domain with a 20-character selector. That's 67 characters for the full label. Add the standard DKIM header and a 1,024-bit key (about 170 base64 chars), and you're past 255. This is common—especially with longer selectors or multiple records.

To avoid this, you can use shorter selectors (e.g., dkim._domainkey) or split the key across multiple DNS records using DNSSEC-compatible methods like DANE (DNS-based Authentication of Named Entities)—though this is rare in practice. Otherwise, the safest path is to keep selector names short and verify your total TXT record size before deployment.

If you're managing DNS records and want to test whether your configuration is likely to trigger truncation, you can use tools like MXToolbox or DNSChecker.org to query your TXT records directly. For broader email health checks—including DKIM, SPF, and deliverability—consider a verification tool that includes real-time DNS validation. Test your email's inbox placement with MailTester to see how likely your messages are to be blocked due to configuration errors.

Real-world example: A DKIM configuration that fails due to size

You can’t fit a 48-character DKIM selector and a 367-character public key into a single DNS TXT record without exceeding the 255-character limit per string. When total record length hits 415 characters, most MTAs reject the signature during validation — breaking DKIM authentication and hurting deliverability. This isn’t theoretical. It’s a common misstep in real email setups.

Step-by-step: How a DKIM record fails at scale

Define your selector with long naming conventions. You chose very-long-dkim-selector-2024-v2 for clarity and versioning. That’s 48 characters — a valid name, but pushing limits.
Generate your RSA key pair. The public key part is long by design. At 367 characters, it already pushes the edge of what’s usable in a single TXT record.
Combine selector and key into one TXT record. Your full record becomes: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... — 415 characters when combined. This violates the DNS TXT record size limit.
Submit the record to DNS. Your registrar or DNS host may allow the entry, but many MTAs only read the first 255 characters of a TXT record, truncating the rest. The signature fails to validate.
Messages are tagged as unauthenticated. Mail servers that check DKIM see only the truncated record. They reject the signature, and your messages are either blocked or marked as spam.

What happens when you cross the 255-character limit

DNS TXT records are limited to 255 characters per string. This is defined in RFC 1035, which governs DNS record structures. When a record exceeds that, resolvers often truncate it silently. That means even if your DNS config appears correct, MTAs only see a fragment.

The 5 steps described in “Step-by-step: How a DKIM record fails at scale”, in order.

This issue is especially common with long selectors or extended public keys. Some tools or hosts let you split records across multiple strings — but that’s not always supported by the receiving MTA. In practice, only a few providers (like Microsoft and Gmail) handle such records correctly in all cases. The rest assume failure.

Use tools like MailTester’s email checker to validate full DKIM setup before sending. It tests not just syntax, but whether authentication will hold across real-world mail flows. You can catch this kind of flaw before it hits your inbox placement.

How to avoid exceeding the DNS TXT record size limit

You can avoid hitting the 255-character DNS TXT record size limit by using short, consistent DKIM selectors like 'd1' or 'default', verifying total record length before publishing, splitting long DKIM keys across multiple TXT records if your provider supports it, and checking published records with tools like MxToolbox or dig. This prevents delivery failures and ensures your DKIM signature remains valid.

Use short, consistent selectors

Choose simple, short selectors like d1, default, or prod—they fit within the size limit and reduce error risk.
Avoid descriptive but lengthy selectors (e.g., dkim-primary-production-2024) that push record length toward the 255-byte boundary.
Use the same selector across all DKIM configurations to simplify management and reduce configuration drift.

Verify before publishing

Before publishing, calculate the total length of your full DKIM TXT record, including the DKIM1= tag and the full public key.
Use MxToolbox's DNS Check or run dig TXT yourselector._domainkey.yourdomain.com to see the actual published record size.
If the record exceeds 255 characters, split it into multiple TXT records—one for the selector, one for the key content—only if your DNS provider and receiving servers support multi-part TXT records.
Be aware that not all resolvers handle fragmented TXT records the same way, so test across multiple receivers.

Use reliable tools for inspection

Test your records with DNS Survey, which shows full TXT record content across global resolvers.
Run dig TXT _domainkey.yourdomain.com locally to see what’s actually published.
If you're using MailTester’s email checker, you can validate recipient domains for deliverability, catch misconfigurations, and confirm if a sender is receiving mail at all—even if your DKIM is valid.

Shorter selectors and verified record lengths are not a suggestion—they’re a requirement when you’re deploying DKIM at scale.

DKIM selector length vs. DNS record size: The trade-off

DKIM selectors should stay under 50 characters to avoid hitting DNS TXT record size limits, which can cause delivery failures. While longer selectors improve traceability and help identify email sources, they increase the risk of exceeding DNS TXT record limits—especially when combined with long DKIM signatures. You’re balancing clarity against technical compliance: too long, and your records may be truncated or rejected; too short, and you lose auditability without logs.

Long selectors: better traceability, worse DNS safety

Using descriptive selectors like mailserver2023-secure makes it easier to track which system signed a message. But every extra character adds to the overall size of the TXT record. RFC 1035 and DNS standards don’t set a hard upper limit on TXT record size, but implementations often cap it at 255 bytes. When combined with DKIM’s base64-encoded token and other metadata, long selectors can push records beyond that threshold.

Mail providers like Google and Microsoft expect DNS records to resolve completely. If a record is truncated or fails validation due to size, the DKIM check fails—regardless of signature correctness. This can trigger delivery issues or spam filtering, even if your email content is clean. Tools like MxToolbox can help verify record size and completeness before you deploy.

Short selectors: safer, but less transparent

Shorter selectors—like dkim1 or s1—reduce the risk of DNS record size issues. They’re more likely to fit cleanly within the 255-byte limit, ensuring reliable DNS resolution across all receiving systems.

But naming becomes less informative. Without clear context in the selector, you’ll need logs or external tracking to identify which server or campaign generated a specific signature. This complicates troubleshooting in large-scale operations or when investigating abuse. It’s a trade-off: operational safety vs. traceability.

Striking the right balance means choosing a selector that’s descriptive enough to identify the source but short enough to stay under the effective size limit. Use an internal naming convention—like campaign-us or prod-2024—to keep it readable while avoiding unnecessary length. Validate your DNS records before sending.

Want to verify your senders’ email health before deployment? Use our email checker to test individual addresses and validate SPF, DKIM, and DMARC alignment. For bulk list health, bulk verify your database to catch invalid or risky addresses early.

Why this matters for email deliverability

Invalid or truncated DKIM records due to DNS TXT record size limits or overly long selectors break authentication, causing mail servers to reject or flag your messages as spam. This hurts inbox placement and damages sender reputation over time, especially if repeated across multiple sends. Even small errors in DNS configuration can lead to large-scale deliverability failure.

How DNS and DKIM limits affect authentication

DKIM uses DNS TXT records to publish public keys, but these records are limited to 255 characters per label and 512 bytes total in some configurations. If your DKIM selector — the part of the DKIM signature that identifies the key — is too long, or if the key itself exceeds limits, the record gets truncated. This invalidates the signature, and receivers like Gmail or Outlook reject the email during authentication.

Many senders don’t notice this until they start seeing spikes in hard bounces or messages landing in spam folders. The issue is often invisible to the sender until it’s too late. A single malformed DKIM record can break the entire chain of trust needed for deliverability.

Spam filtering and sender reputation consequences

Mail servers and spam filters use authentication signals to decide whether to accept or reject incoming messages. When DKIM fails due to size or selector length issues, the message receives a weak or no authentication score. This makes it easier for spam filters to flag your domain as suspicious or untrusted.

Consistently failing authentication across multiple campaigns sends a clear signal: your sending practices aren’t compliant. Over time, this degrades sender reputation — a critical factor in inbox placement. Reputable services like Gmail and Microsoft’s Exchange maintain reputation scores based on consistent delivery, authentication, and engagement. Once damaged, recovery takes weeks or months.

Let’s be clear: even one failed authentication event isn’t catastrophic, but repeated failures across hundreds or thousands of emails are. It’s especially risky when sending marketing or transactional campaigns at scale. That’s why checking your DNS records and DKIM setup before every send matters.

Use tools like MailTester’s email checker to verify individual addresses and test your DKIM setup in real time. You can also run bulk tests with our bulk verification tool to catch misconfigured records early. These steps help ensure your messages pass authentication before they leave your server.

For more details on how email systems validate DMARC, SPF, and DKIM, refer to the official standards at RFC 6376 and RFC 6377. These define the technical limits that govern DKIM and DNS records.

How to test if your DKIM records are being truncated

Run a DNS query for your full TXT record using tools like dig, host, or a reputable online DNS checker. If the returned value cuts off mid-string—like showing only part of a DKIM signature (e.g., "MIIB...")—your record is likely truncated due to the 255-character limit per TXT record fragment. This breaks DKIM validation and harms email deliverability.

Step-by-step: Verify your DKIM record integrity

Use dig TXT example.com or host -t TXT example.com to query your domain’s full TXT record. This pulls all DNS data attached to the domain, including multiple TXT records if they exist.
Look at the full response output. DKIM records are often split across multiple fragments. Pay close attention to the concatenated value across all fragments. RFC 1035 states each TXT record fragment must not exceed 255 characters.
Compare the full, stitched value against your intended DKIM public key. If it matches exactly—character for character—your record is intact. If it ends abruptly (e.g., "MIIB...Y7A==" but stops mid-sentence), it’s truncated during DNS resolution.
Check for unintended line breaks or broken encoding. Some tools show fragmented values as separate lines; you must reassemble them mentally or with a script. A mismatch here can indicate server-side truncation.
Use a trusted third-party DNS checker like MXToolbox or DNSChecker.org to validate across multiple global resolvers. Results may vary slightly based on ISP and routing, but consistent truncation confirms a real issue.

When DKIM breaks, deliverability breaks

If a DKIM record is truncated, receiving mail servers cannot verify the digital signature. This leads to failed authentication, reduced sender reputation, and higher chances of being flagged as spam—particularly on strict platforms like Gmail or Microsoft 365.

Some organizations split large keys across multiple selectors (e.g., default._domainkey and alt._domainkey) to stay under the 255-character limit. This is common, but it only works if all selectors are correctly published and aligned. If one is missing or truncated, authentication fails.

Use tools like MailTester’s email checker to verify an address’s deliverability—including DNS issues—before sending. It helps catch authentication flaws early in your workflow.

MailTester: Catch configuration issues before they harm deliverability

Use real-time email verification to spot domains with broken DNS records—like oversized TXT records or mismatched DKIM selectors—before they cause bounces or delivery failures. MailTester checks SPF, DKIM, and DMARC alignment during verification, flagging domains where configurations don’t match or exceed technical limits like the 255-character DNS TXT record size cap. This stops misconfigured domains from harming sender reputation early.

How DNS and DKIM settings sabotage delivery

MX records, SPF, DKIM, and DMARC all rely on DNS TXT records, which have a hard limit of 255 characters per record. Long DKIM selectors—especially when combined with long token strings—can push records past this boundary, breaking validation. Even if a domain appears valid, a malformed DKIM setup leads to failed authentication, which mail receivers treat as a red flag. This isn’t just a technicality; it’s a direct reason why emails get filtered or rejected.

DKIM selectors (the part before @domain in the selector field) must stay under 255 characters in total when combined with the domain name and DNS structure. While there's no universal limit enforced by the IETF on selector length alone, exceeding this practical cap means the full DNS record won’t resolve. You’ll see delivery issues not because the domain is wrong, but because the authentication layer fails silently.

How MailTester finds issues before they cause harm

When you run a bulk verification with MailTester, the real-time API checks for these exact issues—not just syntax, but structural validity. It doesn’t just say “valid” or “invalid.” It surfaces domains that pass syntax checks but fail alignment (like SPF and DKIM mismatched). For example, a catch-all domain may accept all emails but still fail DKIM if the selector isn’t properly configured.

Every verification result—valid, invalid, catch-all, risky—is based on direct DNS lookup and SMTP probing, not guesswork. The 98.9% accuracy rate means you’re not misclassifying domains with broken or incomplete configurations. You verify only what can deliver. Use the real-time verification API to catch these issues inline, before your list gets sent.

You don’t need to manually inspect every DNS record. MailTester does it for you. The platform flags problems like invalid or oversized TXT records and ensures your DKIM setup is structurally sound.

Learn how DNS limitations affect authentication at RFC 6376 (DKIM) and RFC 1035 (DNS record limits). These standards define the rules your email infrastructure must follow to avoid delivery failure.

Final takeaway: Keep selectors short, test records, defend reputation

The DNS TXT record size limit is not a theoretical constraint—it’s a hard limit enforced by the DNS protocol. Records exceeding 255 characters are truncated, which can break DKIM validation even if the key is correctly generated.

Long DKIM selectors increase the risk of truncation, especially when combined with other DNS entries like SPF or DMARC. This leads to failed signature checks, which hurt sender reputation and result in hard bounces or filtered messages across thousands of recipients.

Defend your domain health

Use shorter DKIM selectors—ideally under 16 characters—to leave room for record growth and protocol overhead.
Test your full DNS configuration in real time before launching campaigns. Small misconfigurations cause large delivery failures.
Validate your domain setup with tools that simulate actual email flow and detect issues like truncated records.

Sources

52.1% of the world's top 1.8 million domains (937,931 domains) now publish a valid DMARC record, up from 29.1% in 2023. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
Google reported 265 billion fewer unauthenticated messages sent to Gmail users in 2024 — a 65% reduction — after its bulk-sender rules took effect, with 500,000+ top domains publishing DMARC records in response. — Google (via MailOver bulk-sender requirements guide) (2024)

Keep reading

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

Frequently asked questions

What is the maximum size of a DNS TXT record?

Each DNS TXT record must be 255 characters or shorter. Longer values are truncated by resolvers, leading to failed authentication.

How long can a DKIM selector be?

A DKIM selector is limited to 63 characters in any single DNS label, but the total record including key data must not exceed 255 characters.

Does my DKIM selector need to be short?

Yes — long selectors increase the risk of exceeding the 255-character TXT record limit, even with short keys.

What happens if a DKIM record is truncated?

Truncation invalidates the signature. Recipients may reject the email or mark it as spam, harming sender reputation.

How do I check if my TXT record is too long?

Use dig or online tools to query the full TXT record. Compare the output length to your intended content.

Can I split a DKIM record across multiple TXT entries?

Yes, but only if the receiving mail server supports it. Most do, but not all. Test carefully.

What is a good DKIM selector name?

Use short, consistent names like 'd1', 'default', or 'prod'. Avoid descriptive or versioned names that grow long.

Do all domains enforce the 255-character TXT limit?

Yes — all RFC-compliant DNS resolvers enforce the 255-character limit per TXT record.

Can DKIM still work if the record is slightly over 255 characters?

No. DNS resolvers truncate data beyond 255 characters. Any truncation breaks DKIM validation.

How does bad DNS configuration affect sender reputation?

Repeated authentication failures signal poor sending practices. Major providers penalize such senders with lower inbox placement.

How can I verify my DKIM record is valid before sending?

Use the MailTester real-time API to test domain authentication and verify SPF, DKIM, and DMARC alignment.

Is there a tool that checks TXT record size before publishing?

Yes — tools like MxToolbox, DNS Checker, or dig allow real-time record inspection. Use them before finalizing DNS changes.