What is the DNS record length limit for email records?

DNS does not impose one universal 255-character limit on an entire TXT record. Each DNS character-string inside TXT RDATA is limited to 255 octets, and one TXT record can contain multiple strings. SPF processors concatenate those strings without adding spaces. DKIM verifiers must also concatenate the strings in a TXT resource record before use. Separate limits still apply to the full DNS answer and to provider interfaces. Validate the authoritative wire response instead of counting only what a web form displays.

Quick takeaways

• The 255-octet limit applies to each TXT character-string.
• One TXT record can contain several strings.
• Multiple strings are not multiple SPF records.
• Provider UI limits can be stricter than DNS wire format.
• Long SPF answers can exceed legacy 512-octet UDP handling and require TCP fallback.

Who is affected?

SPF, DKIM, DMARC, BIMI, verification-token, and other email records can use TXT. Long DKIM public keys and complex SPF policies are where interface and response-size problems tend to appear first.

The same value can look different in a registrar, an API, a zone-file editor, a recursive resolver, and the mail software that consumes it. Those layers do not always display string boundaries the same way.

Start with the DNS answer, then decide which layer changed the value. SPF authenticates an SMTP identity, DKIM verifies a signing domain, and DMARC checks alignment with the visible From domain.

What are the requirements?

RFC 1035 encodes a character-string with a one-octet length, so one string can carry at most 255 octets. TXT RDATA consists of one or more such strings.

For SPF, strings inside one selected TXT resource record are concatenated in order without added spaces. Publishing two separate v=spf1 TXT records is different and causes a permanent error.

For DKIM, RFC 6376 requires verifiers to concatenate all character-strings in one TXT resource record without intervening whitespace.

Your DNS provider may split a long value automatically, require quoted chunks, or impose a smaller form limit. Follow its exact syntax, then inspect authoritative DNS to see what it actually published.

RFC 7208 recommends keeping an SPF query response within 512 octets so older DNS implementations do not need TCP fallback. Splitting one TXT value into strings solves the 255-octet string limit, but it does not reduce the size of the full DNS answer.

When does the requirement take effect?

The limits apply when the record is encoded and whenever a resolver retrieves it. A value can save successfully in a UI and still be truncated, split incorrectly, or returned in an oversized response.

Revalidate after DNS-provider migration, key rotation, SPF provider additions, and other record changes.

How do I implement the requirement?

1. Measure bytes, not visible characters

Measure the encoded octets, not only the visible characters in a DNS form. SPF records use US-ASCII, and DKIM public keys use base64 text in the p= tag.

2. Use one logical resource record

Split a long TXT value into provider-supported character-strings inside the same record, not separate SPF policies.

3. Keep protocol syntax intact

For SPF, make sure concatenation preserves the spaces required between mechanisms. For DKIM, do not insert spaces into base64 key material.

4. Query authoritative wire data

Inspect TXT answers from every authoritative server and compare them with public resolvers. Test TCP where response size is a concern.

5. Reduce avoidable size

Use separate selectors, simplify SPF authorization, and remove stale values instead of relying on ever-larger responses.

How do I validate compliance?

Confirm that the consumer reconstructs exactly one intended value. Evaluate SPF with real sources and retrieve each DKIM selector key from several resolvers.

Check total response size, truncation behavior, and TCP fallback. A visually complete provider UI is not sufficient.

Use Palisade's Email Security Score for a public-configuration review, but keep DNS answers, delivered headers, SMTP responses, and provider state as the production evidence.

Make SPF, DKIM, and DMARC easier to manage with Palisade. The DMARC Agent turns aggregate-report data into prioritized sender, SPF, DKIM, and DMARC issues, so your team can see what to fix next and follow a guided path toward stronger authentication and DMARC enforcement. Stronger authentication helps protect your domains and supports better email deliverability. start a Palisade account.