Split a 2048-bit DKIM TXT Record Over 255 Characters

Short answer: A single string inside a DNS TXT record can hold at most 255 characters, and a 2048-bit DKIM record is about 410. Store it as one TXT record made of several quoted strings, for example "v=DKIM1; k=rsa; p=MIIB...(first 255)" "...rest". Receivers join the strings with no space added. Cloudflare splits long values for you, cPanel writes its own DKIM records already split, and in a BIND zone file you write the strings yourself inside parentheses. Never create two separate TXT records for one key.

We ran the BIND zone tests and the cPanel record checks below on our lab server (AlmaLinux 9.8, cPanel & WHM 11.138, BIND 9.16) on 6 October 2026, using a throwaway test key in a test zone, not a live domain. Cloudflare behaviour was checked against Cloudflare’s DNS documentation the same day.

Why 2048-bit keys need splitting

DNS stores TXT data as “character-strings”, each with a length byte, so one string cannot be longer than 255 characters. A TXT record may hold several strings. For DKIM, RFC 6376 says the strings “MUST be concatenated together before use with no intervening whitespace”. So the split is invisible to receivers as long as all parts are in the same record.

Numbers from our lab: the public key of a 2048-bit RSA key is 392 base64 characters, and with v=DKIM1; k=rsa; p= in front the record is 410 characters. That is two strings: 255 + 155. A 1024-bit key fits in one string, which is why the problem appears when you upgrade to 2048 bits (the size Google recommends).

Right	Wrong
One TXT record with two quoted strings	Two separate TXT records at the same name (RFC 6376 says results are then undefined)
Split anywhere, nothing added or removed	A quote character, backslash or an extra p= pasted into the value
Each string 255 characters or less	One unsplit 410-character string in a zone file (BIND refuses it)

DKIM is forgiving about whitespace: RFC 6376 allows spaces inside the base64 p= value. SPF is not, because spaces separate SPF terms. If you split a long SPF record, keep the space between terms inside one of the strings.

cPanel: what the Zone Editor stores

When cPanel installs DKIM through Email Deliverability, it writes the record already split. On our lab, the zone file line for default._domainkey contained two quoted strings, and DNS returned them like this (strings truncated, lengths added by us):

dig +short TXT default._domainkey.example.com @127.0.0.1 | sed -e 's/" "/"\n"/g'
"v=DKIM1; k=rsa; p=MIIBI...     <- 255 characters
"3ACzk7c+K8ajgIR9OuOWxlE...     <- 156 characters

If you copy a DKIM key out of cPanel to publish at an external DNS provider, copy the joined value (without the quote characters between the parts) and let that provider split it, or copy the strings exactly as they are, quotes included, if the provider accepts multi-string input. When you paste a long value into cPanel’s Zone Editor yourself, check the result with dig afterwards (see the last section).

Cloudflare

Cloudflare’s DNS FAQ explains that when a TXT value exceeds 255 characters it must be split, and that Cloudflare stores it as several quoted strings, so the record may show a quote in the middle, such as "first part" "second part". That is expected, and receivers join the parts back together.

1. In the Cloudflare dashboard, open DNS > Records and add a TXT record.
2. Name: default._domainkey (cPanel), x._domainkey (DirectAdmin) or your selector.
3. Content: paste the whole value in one piece, for example v=DKIM1; k=rsa; p=MIIBIjANBg...IDAQAB, without adding quotes yourself.
4. Save, then check the record with dig.

Cloudflare also notes that if you paste content with unbalanced quotation marks you may get a validation error. If you paste a value that already contains " " from another system, make sure the quotes are balanced, or remove them and paste the joined value.

DirectAdmin

DirectAdmin creates DKIM keys with /usr/local/directadmin/scripts/dkim_create.sh (2048-bit, stored in /etc/virtual/DOMAIN/) and adds the DNS record itself through its task queue, so you only need to split by hand when you publish the key at external DNS. The public key file is /etc/virtual/example.com/dkim.public.key. Build the record value from it:

P=$(grep -v -- ----- /etc/virtual/example.com/dkim.public.key | tr -d '\n')
echo "v=DKIM1; k=rsa; p=$P"

Paste that single line into Cloudflare or another provider that splits automatically, or use the BIND method below. After entering a record by hand in DirectAdmin’s DNS Management, confirm it with dig, since we have not tested how every DirectAdmin version stores long manual TXT entries.

BIND zone files

In a BIND zone file you write the strings yourself. Parentheses let you spread one record over several lines. This command splits a value into 255-character quoted strings:

V='v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB'
printf '%s' "$V" | fold -w 255 | sed 's/.*/"&"/' 

Put the output inside parentheses in the zone:

default._domainkey  IN  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
                               "...IDAQAB" )

Back up the zone file and increase the SOA serial before reloading. On cPanel and DirectAdmin, edit DNS through the panel or its API rather than the files in /var/named, because the panel can overwrite manual edits.

Always test before reloading. In our lab test, a zone with the key split by the fold command passed:

$ named-checkzone example.com fold.zone
zone example.com/IN: loaded serial 1
OK

The same key as one 410-character string failed:

$ named-checkzone example.com bad.zone
dns_rdata_fromtext: bad.zone:5: syntax error
zone example.com/IN: loading from master file bad.zone failed: syntax error
zone example.com/IN: not loaded due to errors.

We also compiled the good zone with named-compilezone, joined the strings it produced and compared them with the original value: they matched exactly.

Check that it worked

Query the published record and join the strings the way a receiver would:

dig +short TXT default._domainkey.example.com
dig +short TXT default._domainkey.example.com | sed -e 's/" "//g' -e 's/"//g' | wc -c

• You should see exactly one line (one record), starting with "v=DKIM1;, possibly with " " in the middle.
• The joined length should be about 410 for a 2048-bit key (the count includes a newline).
• Our DKIM Checker parses the joined record and reports the key.
• Send a message to Gmail and check dkim=pass in the headers, or paste them into our Email Header Analyzer.

Common problems

• Two records instead of one. Each half was saved as its own TXT record. dig shows two lines. Delete both and add one record with the full value.
• “Key not found” after moving DNS. The DKIM record was not copied to the new provider, or it was copied under the wrong name (for example default._domainkey.example.com.example.com when the provider appends the zone name).
• Key pasted with the quotes as text. Depending on the provider, quote characters you paste may be stored literally. The record then contains \" sequences and DKIM fails. Paste the joined value without quotes.
• Old 1024-bit key still published. After regenerating a 2048-bit key on the server, the old record in external DNS no longer matches, so signatures fail until you update it.

Official documentation: RFC 6376: DKIM key records (section 3.6.2.2) · Cloudflare DNS FAQ: TXT records with a quote in the middle · RFC 7208: multiple strings in SPF records (section 3.3)

Related: DKIM Checker · DNS Lookup: Query Any Record Type · SPF, DKIM and DMARC in cPanel DNS: Setup and Checks · MailBaby Cloudflare DNS: 3 Records (SPF, DKIM, DMARC) · Cloudflare cPanel DNS Proxy: Real Visitor IPs

See also: Find a DKIM Selector: Headers, Panel Defaults and Key Checks · DKIM Key Generator: 2048-bit Key Pair and DNS Record · DNS TXT Record Splitter: Split Long Values Into 255-Byte Strings

Frequently asked questions