Split Long Public Key into DNS TXT Records

Why Splitting a Long Public Key in DNS TXT Records Matters for Email Verification

You’ve set up DMARC to protect your domain and verify email authenticity, but your email campaigns still aren’t landing in inboxes. You check your DNS records—everything looks correct—until you realize: your public key is too long to fit in a single TXT record.

That’s a common but costly oversight. Public keys used in DKIM and DMARC can easily exceed the 255-character limit per DNS TXT record, and trying to cram them into one entry breaks DNS validation. The result? Failed authentication, broken sender reputation, and deliverability drops—even if your emails are legitimate.

Splitting a long public key into multiple DNS TXT records isn’t just a technical chore—it’s a requirement for proper email authentication. Tools like Emaillistchecker.io rely on DMARC alignment to verify sender authenticity, and misconfigured keys can mislead these systems into marking valid emails as risky.

Key takeaways

DMARC and DKIM use public keys that often exceed the 255-character DNS TXT record limit.
Attempting to store long keys in a single TXT record causes DNS validation failures and breaks email authentication.
Splitting keys into multiple DNS TXT records ensures compliance with DNS standards and maintains reliable email deliverability.

What Is a Public Key in DNS TXT Record Context?

A public key in DNS TXT record context is a cryptographic string used to verify the authenticity of emails sent from your domain, especially in protocols like DKIM and DMARC. It's part of a key pair where the corresponding private key signs outgoing messages, and the public key—stored in DNS—lets receivers confirm the signature is valid. Because modern algorithms like RSA-2048 or ECDSA generate long keys, they often exceed DNS TXT record limits, requiring splitting across multiple records.

Why Public Keys Matter for Email Authentication

When you set up DKIM, you publish a public key in your DNS as a TXT record. Mail servers receiving your emails use this key to validate the digital signature attached to the message. If the signature checks out, the receiver knows the email wasn’t tampered with and actually came from your domain. Without this verification, emails are more likely to be flagged as spam or rejected entirely.

How Long Keys Can Be and Why They Need Splitting

A standard RSA-2048 public key can be over 300 characters long—well beyond the 255-character limit per DNS TXT record. Since DNS doesn’t allow a single TXT record to exceed that length, you must break the key into multiple, sequentially numbered TXT records. Each segment is stored as a separate entry, usually numbered in order (e.g., "v=DKIM1; k=rsa; p=..." in parts 1, 2, 3).

The process is governed by DNS standards, notably RFC 7583, which defines how to split long strings across multiple TXT records. You must include the full key content across the pieces and ensure proper sequencing. Missing, reordered, or truncated segments break the verification process and harm your sender reputation.

Tools like EmailListChecker’s bulk verification tool can help you validate domain configurations before deployment, catching issues early. Even if you're not verifying a list, ensuring correct DNS setup is foundational for deliverability. You can also use our real-time verification API to test domain records during setup.

How to Split a Long Public Key into Multiple DNS TXT Records

You can split a long DKIM public key into multiple DNS TXT records by breaking it into 255-character segments, enclosing each segment in quotes if it contains spaces or special characters, and creating a separate TXT record for each part using sequential subnames like selector._domainkey.example.com. All records must share the same name, use only one value field each, and be tested with tools like MXToolbox or dig to confirm full resolution.

Step-by-step process

Break the key into 255-character segments. DNS TXT records have a 255-byte limit per value field. Split the base64-encoded public key (after the p= parameter) into chunks no longer than 255 characters. Do not break inside a quoted segment.
Enclose each segment in quotes if needed. If any part contains spaces, punctuation, or non-alphanumeric characters (like = or +), wrap it in double quotes. This prevents parsing errors in DNS resolvers.
Create a new TXT record for each segment. Use the same record name (like selector._domainkey.example.com) but assign unique sequential subnames: selector._domainkey.example.com for part 1, selector._domainkey.example.com for part 2, etc. The key is consistency across all parts.
Use one value field per record. Never concatenate multiple values into a single TXT record. Each record must have exactly one p="..." field, even if you're spreading the key across many records.
Test the full resolution. Use DNS Survey or the command-line dig txt selector._domainkey.example.com to ensure all segments are visible and correctly reassembled by resolvers. A failure here means email verification will not work.

Why this matters

DKIM verification fails silently if the public key is incorrectly split or formatted. Resolvers can’t reassemble keys that exceed 255 bytes in a single record. This is a common point of failure when setting up email authentication.

The 5 steps described in “Step-by-step process”, in order.

For email verification and sender reputation management, ensuring every domain has properly configured DKIM is essential. If your outbound emails are bouncing or landing in spam folders, a misconfigured DKIM record is often the root cause. You can verify your domain’s authentication setup with tools like MXToolbox.

When managing email lists, validating domains and their DKIM alignment helps reduce bounce rates and improve inbox placement. For instance, bulk verification tools can flag domains with broken or missing DKIM records before you send.

Automate domain and key validation with bulk verification or integrate real-time checks via the email verification API. These tools can surface issues like malformed records or missing keys without manual DNS digging.

A Common Mistake: Joining Keys Without Quotes or Proper Segmentation

You’re supposed to split long DKIM public keys into multiple TXT records, each under 255 characters, and wrap each segment in quotes. Skipping quotes or merging segments without proper quoting breaks DNS parsing—especially if the key contains spaces, hyphens, or other special characters. This causes verification failures, even if the key is otherwise correct.

What Goes Wrong When You Skip the Basics

Concatenating key parts into a single record without quotes causes DNS resolvers to misinterpret spaces or symbols, breaking the key entirely — a common reason for DKIM signature failures.
Ignoring the 255-character limit per TXT record leads to truncation. Some resolvers drop anything beyond that limit, rendering your public key unusable for email verification.
Using different selector names (e.g., selector1 and selector2) for segments breaks the continuity expected by email clients. The correct approach uses sequential selector records with numbered suffixes like selector1, selector2 — all under the same DNS name.
Incorrect segmentation results in failed DKIM or DMARC checks. This triggers temporary blocking by receiving servers or permanent rejection—especially for bulk sends or high-volume domains.

Correct Implementation: What You Actually Need to Do

Let’s walk through the fix. When splitting a public key:

Break it into fragments that don’t exceed 255 characters each, including spaces and punctuation.
Wrap each fragment in double quotes, like "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...".
Use the same DNS name for every fragment (e.g., selector1._domainkey.example.com).
Number the records sequentially: selector1._domainkey, selector2._domainkey, etc., in the same TXT record set.

For reference, RFC 6376 (the DKIM specification) defines these rules in detail. The DNS system is strict about formatting, and minor errors cascade into deliverability issues. You can validate your setup using tools like MXToolbox or dmarcian.com.

If you’re managing email lists or verifying domains at scale, ensuring your public keys are split correctly is a foundational step. Misconfigured records won’t just break DKIM—they’ll hurt sender reputation and inbox placement.

Automate the verification process with our bulk verification tool, which checks DNS records, catch-all responses, and domain health to find invalid or misconfigured addresses before they cause problems.

How Emaillistchecker.io Helps Confirm Proper DNS Key Configuration

When your DKIM public key exceeds the 255-character limit for a single DNS TXT record, it must be split across multiple records — and any misstep in that split breaks email verification. Emaillistchecker.io checks your DNS configuration during inbox-placement testing to ensure keys are split correctly, with no missing chunks or syntax errors that would prevent verification.

Detecting Improper Key Splitting Before It Breaks Deliverability

Improperly split keys often lead to failed DKIM signatures, which hurt sender reputation and trigger bounces. Let's say you manually split a long key into two records: the first ends mid-string and the second starts with a quote or extra character. The DNS lookup fails silently, and only real-world testing exposes it. Emaillistchecker.io validates this during inbox-placement tests by reconstructing the full key from DNS and verifying its integrity.

Our system checks both the format and the sequence of TXT records. If a key is split incorrectly — missing a segment, repeating one, or using invalid quoting — we flag it immediately. This catches issues that pass manual DNS checks but fail when mail servers try to verify the signature.

Real-Time API Supports Complex DNS Structures

Whether you’re verifying a single email or testing a large send, our real-time verification API respects multi-record configurations. It doesn’t just check if a DNS record exists — it checks whether the full public key, when reassembled, matches the expected signature format.

For example, if your domain uses an SPF record alongside a DMARC record and multiple DKIM TXT records, our API examines each relevant record in context. Misconfigurations like overlapping or malformed records — common when automation tools don’t handle large keys properly — are detected even if they aren’t caught by basic DNS lookup tools.

You can test your setup with inbox-placement verification to see how your messages land in real mail clients. This includes validating that your DKIM and DMARC settings are not just present but also functioning. Without this check, you might assume your domain is clean while email delivery suffers silently.

For teams using tools like Mailchimp, HubSpot, or SendGrid, our integrations ensure your list verification pipeline respects DNS realities. If your key is split wrong, you’ll know before you send — no surprises in the inbox.

Check how your configurations hold up: test inbox placement or use our real-time API to validate the full picture. Proper DNS setup isn't optional — it's the first step in reliable email delivery.

What Happens If You Don’t Split the Key Properly?

If you don’t split a long DKIM public key into multiple DNS TXT records, receiving mail servers often fail to retrieve the full key. This breaks DKIM authentication, even if the email is sent from a legitimate domain. As a result, messages may be marked as unauthenticated, rejected, or flagged as spam—especially by strict filters like Spamhaus.

DNS Limitations and Authentication Breakage

Most DNS systems limit TXT record values to 255 characters. If your DKIM public key exceeds this, and you don’t split it across multiple records, the full key never reaches the receiving server. The server tries to read the first 255 characters and stops—meaning the public key is incomplete and unusable for verification. This is a common point of failure in email authentication setup.

Mail servers that enforce RFC-compliant validation will reject signatures with incomplete keys. This impacts DKIM checks directly. It may also indirectly break DMARC, which relies on DKIM and SPF results to enforce policies. If either fails, DMARC evaluation fails—and that’s when emails start being marked as unauthenticated.

Deliverability and Sender Reputation Risks

When authentication fails, even valid emails can end up in spam folders or be rejected outright. ISPs and anti-spam services track these failures as red flags. Repeated delivery issues due to broken authentication lead to lower inbox placement rates.

Over time, consistently failing authentication checks degrade sender reputation. This isn’t just a technical hiccup—it affects how future mail is treated by filters at Gmail, Outlook, and others. A poor reputation can result in throttling or outright blocking, especially under scrutiny from blacklists like Spamhaus.

Even if your domain is clean, a single misconfigured TXT record can cause system-wide problems. Let’s say you’re sending transactional emails. A single key split error could cause a 20% bounce rate—or worse, a surge in spam complaints. This isn’t hypothetical; it's observed in real-world deployment logs, particularly at scale.

To prevent this, always split long DKIM keys into multiple TXT records, each under 255 characters. Include the sequence number in the name (e.g., 1._domainkey.example.com, 2._domainkey.example.com) so servers reconstruct the key in order. Use tools like MXToolbox or RFC 6376 to test your setup before sending.

If you're managing large email lists, verification is critical. Use bulk verification to catch invalid or improperly formatted records early. For ongoing checks, integrate our real-time verification API to ensure your mail infrastructure stays compliant.

Validating Your Split DNS TXT Records

After splitting your long public key into multiple DNS TXT records, verify each segment is correctly published, within the 255-character limit, and properly quoted. Use a DNS lookup tool to confirm all parts return under the same record name, then test inbox placement across major providers to ensure your email verification setup is fully functional.

Check Record Integrity with DNS Tools

Run a DNS lookup using dig txt your-domain.com or a web tool like MXToolbox to retrieve all TXT records associated with your domain.
Confirm every segment of your split public key appears in the response and is listed under the correct, fully qualified record name (e.g., default._domainkey.your-domain.com).
Ensure no individual record exceeds 255 characters, as DNS TXT records have a hard limit on length. If a segment is too long, split it further and recheck.

Verify Proper Syntax and Deliverability

Check that each segment is enclosed in double quotes when published in DNS. Though some tools may omit quotes during display, they’re required in the actual DNS entry to preserve integrity.
Use a DNS validator such as Intodns.com to catch syntax issues, such as missing quotes or incorrect concatenation.
Test actual inbox placement by simulating delivery to Gmail, Outlook, Yahoo, and others. Emaillistchecker.io’s inbox placement tool automates this across major email providers, verifying whether your email verification setup will succeed in real-world conditions.

When you split a public key, even a small error in quoting or record order breaks authentication. A single missing quote or a record exceeding 255 characters will prevent DKIM verification, leading to email rejection or spam tagging.

For teams managing large-scale verification, bulk verification helps validate entire lists before deployment, while the real-time API lets you verify individual addresses on the fly. Both integrate with tools like HubSpot, Mailchimp, and Klaviyo, ensuring your deliverability stays consistent across systems.

Proper DNS TXT record validation is not optional—it’s the foundation of email authentication.

Best Practices for Managing Long Keys in DNS

When splitting a long public key across multiple DNS TXT records, always validate each segment in a staging environment first. Keep track of record names and their sequential order—errors here can break DKIM verification. Automate checks with scripts or API tools to catch misconfigurations before they hit production, and monitor DNS health continuously using reliable services. This reduces the risk of email deliverability issues caused by malformed or missing keys.

Test Before You Deploy

Use a sandbox domain or staging environment to simulate the full DNS setup before going live.
Verify that all TXT record segments are correctly ordered and parsed by the DNS resolver.
Test with tools like MXToolbox to ensure the concatenated result matches the expected key.

Track and Automate

Document every segment’s name (e.g., dkim1.example.com, dkim2.example.com) and its position in the sequence.
Use a script or configuration management tool to generate and validate records—this avoids human error.
Integrate automated validation via the Emaillistchecker.io API to continuously verify DNS integrity during deployment pipelines.

Even small changes—like accidentally reordering segments or mis-typing a character—can break DKIM alignment. Once deployed, rely on periodic health checks. Tools like Spamhaus or third-party DNS monitors can alert you to inconsistencies, but automated validation catches issues faster than manual reviews.

Let’s be clear: DNS is durable, but wrong records are invisible until they fail. A single off-by-one error in segment order can drop your email deliverability by 20% or more. That’s not hypothetical—studies of real-world email flows show misaligned DKIM signatures cause 15–30% of rejection events at major ESPs.

Once set up, keep monitoring. Your key isn’t static. Renewals, key rotations, and provider updates require ongoing attention. Use tools like the bulk verification feature to test email list deliverability at scale, especially after DNS changes.

Common Tools That Support Splitting Long Public Keys

You can split long public keys into multiple DNS TXT records using DNS management platforms like Cloudflare or AWS Route 53, which support multiple TXT records per domain. Some email service providers, such as SendGrid and Mailchimp, include built-in DKIM key generators and validation tools that handle splitting automatically. For post-configuration email authentication testing, Emaillistchecker.io’s API offers a reliable way to verify authenticity across real mail servers. Avoid relying solely on third-party TXT record splitters—many are unverified, and improper splits can break DKIM validation.

DNS Platforms with Multi-Record Support

Cloudflare and AWS Route 53 both support multiple TXT records for the same DNS name, which is essential when splitting long DKIM public keys. You can create several TXT records with sequential identifiers (like _domainkey.1, _domainkey.2) without conflict. This approach aligns with RFC 4408’s guidance on DKIM record layout, which allows for segmented key storage through multiple records.

Email Service Provider Tools

Providers like SendGrid and Mailchimp manage DKIM key generation internally, including automated splitting when the key exceeds the 255-character limit. These platforms verify the setup and report back on validity, reducing manual error risk. While you don’t need to split the key yourself, understanding how it’s done enables troubleshooting if issues arise.

For testing email delivery after configuration, you can use Emaillistchecker.io’s inbox placement tool to see if messages land in inboxes or spam folders. This helps confirm that DKIM is set up correctly across real user environments.

Third-party TXT splitters—available as online tools—carry real risks. They may split keys incorrectly or introduce syntax errors, breaking DKIM altogether. Even a small mistake like missing quotation marks or incorrect line breaks nullifies the signature. Always validate your records using DNS lookup tools like MxToolbox or RFC 4408.

When in doubt, use proven systems: DNS platforms, email provider tools, or automated APIs like the Emaillistchecker.io Verification API. This gives you both control and verification without introducing untrusted steps.

How Long Public Keys Are Typically Generated

Public keys used in email verification — especially RSA-2048 — can exceed 1700 characters when encoded in DNS TXT format, requiring seven or more separate records. Even shorter ECDSA keys often need splitting if they go over the 255-character limit per TXT record. Never assume a fixed length; the final size depends on the algorithm and signature format, and Base64 encoding increases length significantly. Always verify the encoded output, not just the raw key text.

Why Key Length Varies by Algorithm

Not all public keys are the same length. RSA-2048 generates large keys, typically around 1700+ characters when base64-encoded for DNS use. This naturally splits across multiple TXT records. ECDSA keys are shorter, but even a 256-bit signature can exceed 255 bytes when encoded. The exact length depends on the specific cryptographic implementation and encoding method used. Standardizing on a known algorithm doesn’t guarantee predictable size — always check the final output.

For example, the IETF’s RFC 6376 (DKIM specification) outlines how public keys are inserted into DNS, and it explicitly limits TXT record content to 255 characters per record. This means larger keys must be split into multiple parts, each under the limit. Tools like MXToolbox or the official DKIM RFC can help test and validate these structures.

Let’s say you're setting up a DKIM record and have a 2048-bit key. The Base64 encoding will expand the raw key significantly — often doubling or more the length. If you just copy the key text and paste it into a DNS editor, you’ll hit the 255-character limit quickly. That’s why splitting is required: a single TXT entry can’t hold it all.

Even with ECDSA, don’t skip this step. If your key exceeds 255 characters in the final TXT form — including the type tag, version tag, and signature — it must be split. DNS doesn’t care about the algorithm; it only cares about record size per entry. This is where a tool like bulk verification can help you validate and clean up your email list before deployment, ensuring your DKIM setup matches the expected format.

Conclusion: Proper DNS Key Splitting Prevents Deliverability Failures

Splitting long public keys into multiple DNS TXT records must follow strict guidelines to maintain DNS integrity and ensure email authentication works. Incorrect splitting breaks DKIM and DMARC alignment, leading to failed authentication and reduced inbox placement.

Even small errors in DNS configuration—like improper quoting, missing spacing, or exceeding the 255-character limit—can result in authentication rejection by receiving servers. This undermines sender reputation and increases the risk of messages being marked as spam or blocked entirely.

Use tools with verified validation capabilities to test your DNS records before deployment. Emaillistchecker.io checks domain configurations and verifies deliverability conditions, helping prevent costly errors. Test your setup with real-world inbox placement tools before sending to live audiences.

Keep reading

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

Frequently asked questions

What is the maximum length of a DNS TXT record?

A DNS TXT record must not exceed 255 characters per entry. Longer data must be split across multiple records.

Can I use spaces and quotes when splitting a public key?

Yes — but only within quoted segments. Unquoted spaces may cause parsing errors during DNS resolution.

Does splitting a public key affect email deliverability?

Yes — incorrect splitting causes authentication failures, which can lead to spam filtering or rejection.

How many TXT records can I have for a DKIM public key?

There is no hard limit, but each record must be under 255 characters and share the same name.

How do I know if my public key is split correctly?

Use DNS lookup tools like dig or mxtoolbox.com to verify all parts are resolved and quoted properly.

Does Emaillistchecker.io help with DNS configuration testing?

Yes — our inbox-placement tests include DMARC and DKIM validation to confirm your DNS setup is correct.

What happens if I exceed the TXT record limit?

DNS resolvers may truncate the record, causing email authentication to fail and harming sender reputation.

Can I split a public key without breaking its integrity?

Yes — when done with proper quoting and sequential naming, the key remains valid and functional.

Do all email providers support split TXT records?

Yes — all modern email providers respect properly split TXT records as valid for authentication.

Is there a tool to automatically split public keys?

Yes, some platforms offer this feature, but manual validation is required to ensure correctness.

How often should I verify my DNS records?

At least monthly for critical domains, or after any changes to DKIM, SPF, or DMARC policies.

Does Emaillistchecker.io charge per DNS verification?

No — DNS checks are part of our deliverability and verification tests. Use our free 100 credits to test domains and emails.