TXT Character-String
What is TXT Character-String?
A TXT character-string is the basic unit of a DNS TXT record's data: one length octet followed by up to 255 octets of text, as RFC 1035 defines, so longer values like DKIM keys must be split across several strings in one record. AdminKit's TXT record splitter cuts a long value into correctly quoted 255-octet character-strings.
By AdminKit team, Netbase JSC · Updated
A TXT character-string is the building block of the data in a DNS TXT record. RFC 1035 section 3.3 defines a character-string as a single length octet followed by that many octets of data, so one string holds at most 255 octets, and section 3.3.14 defines TXT-DATA as one or more of these strings. TXT is resource record type 16 in IANA’s DNS Parameters registry. RFC 1035 has been updated by many later RFCs, which its IETF Datatracker page lists. In zone files and DNS provider panels, each character-string is normally written as its own quoted chunk, for example “v=DKIM1; k=rsa; p=MIIB…” “…rest of the key”, all inside one record.
Why do long DKIM and SPF records need to be split?
A 2048-bit DKIM public key in base64 is longer than 255 octets, and a busy SPF policy can be too, so the value cannot fit in a single character-string. The fix is to publish it as several strings in the same TXT record. RFC 7208 section 3.3 says SPF verifiers must treat multiple strings as if they were concatenated without adding spaces, so the split point must not add or drop a character. A common mistake is to publish the pieces as separate TXT records instead, which parsers read as separate values. Splitting does not shrink the DNS response itself; RFC 7208 section 3.4 still advises keeping SPF answers within 512 octets, the classic DNS-over-UDP size that EDNS0 lets supporting resolvers exceed.
AdminKit’s TXT record splitter splits a long value into correctly quoted 255-octet character-strings in your browser. TXT character-strings are part of AdminKit’s DNS cluster; the full AdminKit glossary lists other related terms.
Frequently asked questions
Why is a single TXT character-string limited to 255 octets?
RFC 1035 encodes a character-string as one length octet followed by the data, and a single octet can only count up to 255. The whole string, including its length octet, is at most 256 octets.
Is a TXT record with two strings the same as two TXT records?
No. Several character-strings inside one TXT record form one value that SPF, DKIM and DMARC parsers join together. Two separate TXT records at the same name are two different values, and publishing two SPF records that way makes SPF evaluation fail with a permerror.
Are the strings joined with a space when they are read back?
For SPF, RFC 7208 section 3.3 says the strings must be treated as if concatenated without adding spaces, so a split must fall exactly where no space is intended. DKIM key records are joined the same way.
Does splitting a long record make the DNS answer any smaller?
No. Splitting only satisfies the 255-octet limit per string; the full record still travels in the answer, which is why RFC 7208 also advises keeping an SPF record small enough that the DNS response fits within 512 octets.