A DNS form's length error can refer to several different limits. A long TXT value, a single name label and an entire DNS name are not measured in the same way. Shortening a DKIM key or splitting one SPF policy into separate records can turn an input problem into an authentication failure.
Identify which object is too long
References: RFC 1035 §2.3.4, RFC 1035 §3.3, RFC 1035 §3.3.14, RFC 2181 §11.
RFC 1035 limits a DNS label to 63 octets and the full wire-format name to 255 octets including its length fields and terminating root label. Presentation punctuation and Unicode input can obscure those measurements. Count the encoded DNS form, not just what a browser text box displays. Do not apply the hostname character rules blindly to service labels containing underscores.
TXT RDATA consists of one or more character strings, each with a one-octet length and therefore a maximum of 255 octets. That is not a blanket 255-character limit for the entire TXT record. A provider can support a longer record by storing several strings within it, subject to DNS message and service limits.
Split strings without splitting policies
References: RFC 7208 §3.3, RFC 7208 §4.5, RFC 6376 §3.6.2.1, RFC 6376 §3.6.2.2.
For SPF, strings within one TXT record are concatenated without extra spaces. Preserve required spaces at the split boundary. The fixture "v=spf1 ip4:192.0.2.10" " -all" reconstructs one policy. Two separate TXT resource records each beginning v=spf1 are not a supported way to extend it; SPF selects multiple policies and returns a permanent error.
DKIM key data also needs its intended value preserved. Use the provider's documented long-TXT entry method, not manual truncation. Do not split a long selector label by inserting a dot: that changes the DNS name queried by the verifier unless the actual selector configuration is changed consistently.
Run boundary-focused fixtures
References: RFC 1035 §2.3.4, RFC 1035 §3.3.
Create strings of exactly 255 ASCII a octets and 256 ASCII a octets. A single DNS character string can encode the first and cannot encode the second. A record containing two strings of 128 octets each is a different, valid string structure totaling 256 data octets. These markers are not authentication policies.
For names, compare a 63-octet ASCII label with a 64-octet label, then independently test full wire-name length. Preserve the validation error for each rejected case. In a separate test zone, publish one SPF record with two strings, then the intentionally invalid two-policy-record variant. Capture authoritative RR boundaries before and after the corrected one-record publication. Expected application outcomes are single-policy processing versus multiple-policy permerror.
These fixtures specify boundary behavior. A local encoding test can demonstrate lengths but cannot prove a DNS provider accepts a form, a live zone publishes the intended RRset or a receiver authenticates a message. Those execution results must be captured separately.
Verify the resulting wire data
References: RFC 7208 §3.3, RFC 6376 §3.6.2.2.
Query the exact owner and type at all active authorities. Use a DNS parser that preserves each resource record and its string list. Reconstruct values according to the consuming protocol rather than joining every output line. Then compare a relevant recursive answer and test the mail flow.
If the form still rejects valid data, capture the exact error and consult its current provider-specific limit. Do not add broad SPF authorization, weaken a key or create another policy as an expedient workaround. The correct fix preserves both the intended bytes and the DNS structure.
Executed parser and RRset evidence
The retained historical capture from 7 November 2026, inspected but not rerun for this review, records that the dnspython parser accepted a 63-octet label and a 255-octet wire name, and rejected the corresponding 64- and 256-octet cases with length exceptions. Actual UDP authority captures show the before state as two separate SPF TXT records, then the corrected state as one TXT record containing two ordered strings. A loopback forwarder returned the same boundaries. This is a local controlled publication, not a provider-panel change. SPF permerror for the two-policy case remains a source-defined expected result because no SPF evaluator was executed. The boundary and record-capture evidence should not be mistaken for live delivery proof.
Keep the evidence scope explicit
The archived parser and DNS captures are preserved unchanged. This review checks their recorded outcomes and separately calculates byte boundaries locally; it does not repeat UDP publication, run an SPF evaluator or test a provider form. The two-record SPF outcome is normative expectation, not captured authentication execution.