Split Large DKIM Keys in DNS TXT Records

Why can't you fit a DKIM key in a single DNS TXT record?

You're trying to set up DKIM, and your provider says your key is too long. You paste it into your DNS zone file, hit save, and get a validation error. You double-check the key — it's correct. So why won't it work?

DNS TXT records are limited to 255 characters per string. A standard 2048-bit DKIM key, even when base64-encoded, often exceeds that. Even 1024-bit keys can push close to the limit. When you try to store a full key in one record, it gets truncated — and DKIM verification fails silently.

That’s why you need to split large DKIM keys across multiple TXT records. It’s not a workaround — it’s how DNS was designed to handle long data.

Key takeaways

DNS TXT records are capped at 255 characters per string, making single-record storage impossible for large DKIM keys.
Splitting a DKIM key into multiple TXT records preserves full key integrity and enables successful verification.
Properly formatted, concatenated TXT records are required for SPF, DKIM, and DMARC to function correctly in DNS.

What happens when a DKIM key is too long for a single TXT record?

If a DKIM key exceeds the 255-character limit per TXT record, DNS resolvers return incomplete or malformed responses. Mail servers cannot validate the signature, leading to authentication failures. This breaks SPF and DKIM alignment, causing emails to be rejected or marked as spam, which harms sender reputation and inbox placement.

Why the 255-character limit matters

DNS TXT records are capped at 255 characters per string. A standard DKIM key—especially with a 1024-bit or 2048-bit public key—is often longer than that. When the key is split across records, DNS resolvers must reassemble them in the correct order. If the split is malformed or the record names don’t align, the full key is never retrieved.

Let’s say your DNS provider doesn’t handle multibyte or fragmented TXT records correctly. The mail server receives a partial or garbled version. Even a single missing character breaks the signature verification. This is why RFC 6376 defines a strict format for DKIM record concatenation using numbered fragments.

You might assume a long record just fails silently. But in practice, most MTAs (Mail Transfer Agents) reject messages with invalid or missing DKIM signatures during the initial handshake. This can trigger hard bounces, blacklisting, or inbox filtering based on sender reputation signals.

According to DMARC analysis from major email providers, poorly formatted DKIM records are a common reason for domain-level authentication failures. These failures reduce message delivery rates by as much as 20–30% for domains with weak DNS configurations.

How to fix and verify DKIM key alignment

Proper DKIM key splitting uses DNS TXT record names like 201501._domainkey.yourdomain.com, with each fragment appended in numerical order. Tools like IANA’s DNS Parameters document this format explicitly.

Once split, you must verify that all fragments are present and correctly ordered. One missing or misordered fragment invalidates the entire key. Automated tools—like the bulk verification feature at EmailListChecker—can scan your DNS records for integrity and flag anomalies before they impact delivery.

Use a DNS record checker to confirm the full DKIM key is retrievable as a single, continuous string. Many tools also validate the syntax and fragment ordering, helping you catch issues before they reach the inbox.

Don't treat DKIM as a one-time setup. Monitor it regularly, especially after key rotations. Even small errors in TXT record formatting can trigger delivery failures across thousands of messages.

How to properly split a DKIM key across multiple TXT records

You must split a DKIM key into fragments of no more than 255 characters each, enclose every fragment in double quotes, and assign them sequential numbers (like 001, 002) under the same DNS TXT record name (e.g., selector._domainkey.example.com). This follows DNS standards and avoids failure during verification. Use tools like MXToolbox to validate your configuration before sending mail.

Step-by-step process

Break the key into 255-character chunks—each fragment must be under 255 characters, including quotes and spaces. Use a script or tool to avoid human error. Longer fragments cause DNS lookup failures.
Enclose each fragment in double quotes—this ensures the full string is treated as a single logical value by DNS resolvers. Omitting quotes breaks parsing.
Label fragments with sequential numbers—use 001, 002, 003, etc., to denote order. The record name must always be the same, e.g., 001._domainkey.example.com, 002._domainkey.example.com.
Use the correct record name format—always follow selector._domainkey.example.com. The selector is a unique identifier you define (e.g., gmail, default). This aligns with RFC 6376.
Remove trailing spaces and extra characters—trim whitespace before and after each fragment. Any extra character (like a newline or invisible Unicode) can invalidate the record.
Test completeness and syntax—use RFC 1035 as reference for DNS TXT record structure. Validate with tools like DNSChecker.org to confirm all fragments are resolved correctly.

Why this matters for deliverability

Misconfigured DKIM keys lead to rejected or marked spam emails. Even a single missing quote or off-by-one fragment can prevent SPF/DKIM alignment. Verification tools like inbox placement testing detect such flaws early. This process isn't just technical—it’s part of ensuring your sender reputation stays strong.

Remember: DNS is literal. It executes exactly what you type. A poorly split key isn’t a minor tweak—it’s a delivery failure waiting to happen. Let’s get this right from the start.

What does a correctly split DKIM TXT record look like?

You can split a large DKIM DNS TXT record by breaking the public key into chunks, starting with the full record header in the first record, then appending sequential labels like "001", "002", etc., each carrying a piece of the key. A valid split starts with v=DKIM1; k=rsa; p= followed by the first segment of the key, then continues with additional records labeled "001", "002", and so on, until all key data is distributed. The entire key must be fully reassembled at DNS lookup time.

Structure and formatting rules

Each segment must be a valid TXT record with a label indicating its position. The first record contains the full DKIM header and the initial part of the public key. After that, each subsequent record uses a label like "001", "002", etc., and must not exceed 255 characters in length. This ensures compatibility with DNS servers that enforce this limit.

For example, the first record might appear as: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC.... The second record is: 001=...jYJ5wIDAQAB. The third, if needed, would be: 002=...cZQ==. These are not separate keys — they are fragments of one continuous key. If the sequence is broken or the labels are incorrect, the DKIM verification will fail.

Always verify your DNS records using tools like MXToolbox or DNSCheck to ensure the full key reassembles correctly. The RFC 6376 specification (section 3.4) describes how long DKIM keys should be split and recombined. Misconfigurations here are a common cause of authentication failures, especially when transitioning to larger key sizes like 2048-bit RSA keys.

Common mistakes to avoid

One frequent error is omitting the label in secondary records — using a record with "001=" is critical. Another is splitting the key at arbitrary points without checking character count, which can break the record. Never split the header portion (e.g., "v=DKIM1; k=rsa; p=") across multiple records — that always stays in the first.

When managing multiple DKIM keys (e.g., for different domains or email sources), treat each as a separate DNS entry. If you're unsure, use a verification tool. You can test how your DNS setup resolves by pasting your full key into a public DNS lookup service. For ongoing list hygiene, if you’re managing a large domain list, ensure each sender’s alignment is correct with their DKIM setup — you can verify this at scale with bulk verification.

Common mistakes when splitting DKIM keys

You're likely to hit problems if you skip wrapping each fragment in quotes, use inconsistent sequence names like "part1" instead of numeric order, or forget to split the entire value—including the p= tag. A single missing or duplicated fragment can destroy key validation. Even spaces inside a fragment break DNS parsing. These are all avoidable with careful attention to detail.

Fragment handling errors

Always wrap every fragment in quotes—no exceptions. DNS TXT records require literal quotation marks around each part, and omitting them leads to parsing failures.
Use sequential numeric names like 001, 002, etc. Avoid descriptive but inconsistent names such as part1, sectionA, or first. Consistency ensures DNS tools process the record correctly.
Do not skip the p= tag when splitting. The entire DKIM public key value—including the p= prefix—must be split. Leaving it behind breaks the key structure.
Check for missing or duplicated fragments. Each fragment must be unique and present. Missing a piece or including a duplicate invalidates the key.
Never insert spaces, tabs, or line breaks inside a fragment. Even a single space within a fragment can cause the DNS resolver to reject the entire record.

Validation and testing

It’s easy to overlook small errors during setup. Use trusted tools to double-check your TXT record structure. The DKIM spec outlines the exact format for multi-part TXT records, and adherence to it is mandatory for deliverability.

Test the full key after configuration. Many email providers (like Gmail or Outlook) won’t deliver messages from domains with improperly split DKIM records. If verification fails, check your DNS with tools like MXToolbox.

While DKIM setup is technical, it’s not an excuse to skip double-checking. A properly split key means higher inbox placement and stronger sender reputation—especially when validating email lists at scale.

If you're working with email lists and want to ensure your sender identity is trustworthy, verify your domain’s readiness with inbox placement testing to catch deliverability issues early.

How to verify that your split DKIM key is working

After splitting your DKIM key into multiple TXT records, use a DNS lookup tool to confirm all fragments are correctly published under the right name and in sequence. Validate the full key by reassembling the parts and test email delivery to ensure the signature is verified by receiving servers. Let’s walk through the steps.

Step-by-step DNS validation

Use dig or nslookup to query the TXT record for your DKIM selector and domain.
Check that all fragments appear under the exact name: selector._domainkey.example.com, with no missing parts.
Ensure each fragment has a sequence number (e.g., 1, 2, 3) and appears in ascending order. The complete key must be reconstructible in sequence.
Confirm every quoted value is complete and properly formatted—no line breaks within a fragment, and no missing or malformed " marks.
Reassemble the fragments in order. The resulting string must match the original, unsplit DKIM public key exactly. A single missing or out-of-order fragment will break verification.

Test email delivery and signature validation

Once DNS is validated, send a test email from your domain with DKIM signing enabled. Use a third-party tool like DMARC Analyzer’s DKIM checker or Mail-Tester to validate the signature in real time.

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

These tools parse the received DKIM signature, verify the public key, and report whether the signature passes. If it fails, return to DNS and double-check sequence order and fragment completeness.

Even after successful DNS and signature checks, deliverability can still be affected by sender reputation or inbox placement filters. If your emails land in spam folders, consider testing deliverability with inbox placement testing, which simulates how real mail providers handle your messages.

Remember: DKIM is only one part of email authentication. It works best when used alongside SPF and DMARC. You can check your full authentication setup using DNS lookup tools or email validation services that inspect these records comprehensively.

How Emaillistchecker.io helps ensure DKIM and email deliverability

You can verify DKIM key integrity and detect split or malformed keys during bulk email list checks by using Emaillistchecker.io’s real-time inbox-placement testing and sender reputation analysis. The tool checks for missing, invalid, or incorrectly formatted DKIM records—like keys split across TXT records with improper syntax—and flags them before you send, preventing delivery failures due to authentication errors.

Real-time inbox-placement testing catches what syntax checks miss

Even if your DKIM keys are technically compliant, they can still cause deliverability issues if your domain’s reputation is weak or your emails land in spam folders. Emaillistchecker.io runs inbox-placement tests on real email providers—like Gmail, Outlook, and Yahoo—to show whether your messages actually reach the inbox. This isn’t just a syntax check; it’s a real-world simulation based on current filtering behavior from major platforms.

Proactive detection of DKIM misconfigurations during bulk verification

When you run a bulk list verification, Emaillistchecker.io doesn't stop at checking email syntax. It validates the underlying DNS records, including DKIM, SPF, and DMARC. It flags when keys are split across multiple TXT records without proper concatenation, or when the key format deviates from the standard—such as missing the dkim=...; tag or using invalid base64 padding. These issues often lead to rejection by receiving servers, even if the key is otherwise correct.

For example, a DKIM key that exceeds 255 characters must be split into multiple TXT records. But if the records aren’t properly ordered or the key isn’t reassembled correctly, the receiving mail server will treat it as invalid. Emaillistchecker.io detects this by testing the DNS record resolution and checking for correct alignment with standard practices outlined in RFC 6376.

It also evaluates sender reputation by checking domain history, blacklisting status, and engagement signals. If your domain has a poor reputation, even perfect DKIM keys won’t ensure delivery. You get actionable feedback—like “DKIM key split incorrectly” or “Domain listed on spamhaus.org”—so you know exactly what’s blocking your messages.

Let’s say you’re preparing a campaign with 20,000 recipients. Running a full list through Emaillistchecker.io’s bulk verification will surface not only invalid email addresses but also any DKIM misconfigurations that could cause rejection at scale. This prevents costly email sends that end in high bounce rates or spam folder placement.

For teams using automated workflows, the real-time verification API integrates into your pipeline to catch issues before sending, ensuring consistent deliverability across campaigns.

Is there a tool to split DKIM keys automatically?

Yes — some DNS platforms like Cloudflare and Amazon Route 53 include built-in functionality to split long DKIM keys into multiple TXT records automatically. But even with this help, you still need to verify the syntax and structure manually to avoid deliverability issues. Let’s break down when automation helps and when you need control.

Automated splitting isn’t always enough

While platforms that support long TXT records can handle key splitting behind the scenes, the actual format and content must still meet email authentication standards. A misformatted or truncated DKIM record will break verification, even if the record appears in DNS.

Some tools assume you’ll get the syntax right, but they don’t validate the underlying structure. This is where real-time checks matter. Even a single missing quote or incorrectly split string can cause DMARC failures.

Validation comes before deployment

Tools like Emaillistchecker.io’s real-time API offer syntax validation for email infrastructure fields, including DKIM. You can test a DKIM record’s structure before publishing it to DNS. If the key is malformed or improperly split, the API flags it immediately.

This kind of validation catches errors that DNS resolvers won’t notice until after delivery — when it’s too late. It’s especially useful in automated deployment workflows where configuration slips through without manual review.

Using a tool like our real-time verification API means you can catch malformed DKIM strings before deploying them, avoiding delivery issues and reducing the chance of spam filtering.

DNS TXT records have a 255-character limit per string, and DKIM keys often exceed this. The split must maintain the correct format: each part must be quoted and concatenated properly with the full key value intact. RFC 6376, the standard for DKIM, specifies how keys are encoded and validated.

While some systems help split keys, none guarantee correct syntax. That’s why testing the actual record structure — not just the raw length — is essential. You’re not just splitting a string; you’re preserving authentication integrity. A single error in a 2048-bit DKIM key can invalidate your domain’s trust signals across email receivers.

What happens if you don’t fix improperly split DKIM keys?

If you don’t fix DKIM keys split across multiple DNS TXT records beyond the recommended 255-character limit, receiving mail servers may reject or flag your emails as unauthenticated. This breaks digital signatures, leads to higher spam filter rejection, and harms your sender reputation, especially with Gmail and Outlook, which enforce strict alignment. Over time, this results in lower inbox placement and damaged deliverability.

Detection and consequences of unverified DKIM records

Receiving servers see your DKIM signature as missing or malformed, which triggers authentication failures.
Major providers like Gmail and Outlook now reject or quarantine emails with invalid or unverifiable DKIM signatures, even if SPF passes.
Spam filters increasingly flag messages from domains with broken signatures, raising the automatic rejection rate.
Over time, persistent failures degrade sender reputation scores, as systems like Sender Score and Microsoft SNDS track consistent authentication issues.

Real-world impact on deliverability

Messages may land in spam folders or be blocked outright — especially for bulk or transactional sends.
Even if delivered, email clients like Gmail often add warnings or reduce engagement tracking, impacting analytics.
Providers like Cloudflare and Google’s Postini rely on properly aligned DKIM to allow inbox placement, so broken keys are a known red flag.
Recovery requires fixing DNS records, but reputation damage can take weeks to reverse even after correction.

Let’s be clear: DKIM is not optional for high-volume senders. The IETF’s RFC 6376 defines strict formatting rules for DKIM alignment and record length — and exceeding 255 characters breaks that. Use a standard-compliant tool to ensure keys are split correctly, or your email risk being treated as untrusted.

Before sending to large lists, verify your full authentication stack—including properly structured DKIM—via a thorough inbox-placement test. Use inbox placement testing to see how your emails appear in real inboxes across Gmail, Outlook, and Apple Mail. Catching issues early prevents long-term deliverability erosion.

How to prevent DKIM key issues in the future

Large DKIM keys must be split across multiple DNS TXT records to comply with the 255-character limit. Manual management risks errors and inconsistent deployment. Use automated tools that handle record splitting and validate syntax before propagation.

Best practices for long-term DKIM stability

Always test DKIM configurations in a staging environment before applying them to production domains.
Monitor inbox placement and spam reports regularly to detect delivery anomalies early.
Validate all DNS changes using third-party tools or Emaillistchecker.io’s real-time API to confirm proper record resolution.

Proactive validation and automated management minimize the risk of failed verification, domain reputation damage, and email delivery failures. Consistency and verification are critical in maintaining sender trust.

Sources

By early 2026, 937,931 of 1.8 million analyzed domains had valid DMARC records — up 79% in three years — but about 56% of them still sit at monitoring-only p=none. — DMARC Report (EasyDMARC 2026 data) (2026)
Validity's analysis of 22+ million domains found 84% of domains used in email From addresses have no published DMARC record at all. — Validity (2024)

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?

Each TXT record fragment must be 255 characters or fewer. Long values must be split into multiple fragments.

Can I use letters instead of numbers for DKIM fragment names?

No. DNS requires numeric sequence numbers (e.g., 001, 002) for valid DKIM key splitting.

Does every DKIM key need to be split?

Only keys longer than 255 characters need to be split. Smaller keys can remain in a single record.

Why does my email fail DKIM verification even though the key looks right?

Check for incorrect fragment order, missing quotes, or spaces in the key. Use a DNS checker to validate.

Can I use Emaillistchecker.io to verify DKIM configuration?

Yes. The tool runs deliverability tests and checks email infrastructure issues, including malformed DKIM entries.

What’s the difference between SPF and DKIM in email authentication?

SPF validates the sending server's IP address. DKIM validates the message’s content integrity using a digital signature.

How many TXT records can I have for one domain?

There is no hard limit. However, each record must be under 255 characters per string.

Does split DKIM affect email delivery speed?

No. Splitting does not impact delivery speed. It only ensures the key is correctly delivered during DNS lookup.

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

Use a DNS lookup tool to fetch all fragments. Reassemble them in order and verify the full key matches the original.

Can I use DKIM with a third-party email service provider?

Yes. Most providers (SendGrid, Mailchimp, HubSpot) support DKIM. Ensure the key is correctly configured and split if needed.

Is DKIM required for email deliverability?

It’s not mandatory, but it significantly improves authentication and inbox placement, especially for bulk senders.

What happens if I remove a DKIM TXT record?

Emails sent from that domain will fail DKIM checks, increasing the chance of spam filtering or rejection.