DNS Record Limits: TXT Length, CNAME Rules and Other Constraints

Editing DNS records looks simple until a record is rejected or silently ignored. Many problems come from limits and rules built into the DNS standards or into protocols that use DNS, plus limits set by individual DNS providers. Knowing them saves time when configuring email, verification records and aliases.

TXT records and the 255-byte string limit

A TXT record holds one or more character strings, and each string can be at most 255 bytes. Longer values, such as DKIM public keys, must be split into several strings within the same record. Applications reading the record usually concatenate the strings. Many DNS control panels split long values automatically; others require you to enter them in quoted segments. If a DKIM check fails after you paste a long key, incorrect splitting is a common cause.

CNAME rules

A CNAME record makes one name an alias of another. Two rules cause frequent confusion:

• No other records at the same name: if www.example.com has a CNAME, it cannot also have an MX, TXT or A record. The standard allows only DNSSEC-related records alongside it.
• No CNAME at the zone apex: the bare domain (example.com) must have SOA and NS records, so it cannot be a CNAME. Some DNS providers offer non-standard alternatives, often called ALIAS, ANAME or CNAME flattening, which resolve the target and return address records instead.

Also avoid pointing MX or NS records at a name that is a CNAME; the standards require these to point directly at host names with address records.

SPF: the ten-lookup limit

The Sender Policy Framework uses TXT records to list servers allowed to send email for a domain. To evaluate SPF, a receiving server may need extra DNS lookups for mechanisms such as include, a, mx, exists and redirect. The SPF specification limits these to ten per check; exceeding it causes a permanent error, which can lead to mail being rejected or marked as failing. Each include can contain further lookups, so the total grows quickly when several email services are added. A domain should also publish only one SPF record.

TTL basics

The time to live (TTL) tells resolvers how long they may cache a record, in seconds. Long TTLs reduce query load and improve resilience; short TTLs let changes take effect faster. Before a planned change, such as moving to a new host, lower the TTL well in advance, at least as long as the old TTL, so caches expire quickly when you make the switch. Raise it again afterwards. Some resolvers apply their own minimum or maximum caching times.

Response size

Traditional DNS over UDP limited messages to 512 bytes. The EDNS extension allows larger responses, but very large answers can still be truncated, forcing a retry over TCP, or dropped by some networks. Many TXT records at one name, large DNSSEC signatures or long lists of addresses increase response size. Keeping records at commonly queried names tidy helps reliability.

Other standard limits

• Labels are limited to 63 octets and full names to 255 octets in wire format.
• MX and SRV records include priority values; lower numbers are preferred.
• Wildcard records (*.example.com) do not match names that have their own records.

Provider-specific limits

DNS hosting providers often set their own limits on the number of records per zone, the minimum TTL, supported record types and the length of values entered in the interface. If a valid record is rejected, check the provider's documentation before assuming the record is wrong.

Key takeaways

• Split TXT values longer than 255 bytes into multiple strings.
• A CNAME cannot share a name with other records or sit at the zone apex.
• Keep SPF within ten DNS lookups and publish a single SPF record.
• Lower TTLs before planned changes and check provider limits.