DNS TXT records — where SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI all live — have size limits that can bite when you are not expecting them. This article explains the relevant limits, how large records are split and handled, EDNS0's impact, and how UK businesses manage TXT records close to the limits.
| Limit | Size | Where it applies |
|---|---|---|
| TXT string | 255 characters | Per individual string within a TXT record |
| Total TXT record | 64 KB theoretical | Sum of all strings in one TXT record |
| Classic DNS UDP | 512 bytes | Total DNS response without EDNS0 |
| EDNS0 UDP | Up to 4096 bytes (typical) | Total DNS response with EDNS0 |
| Practical safe size | 450 bytes | Full record size avoiding edge-case truncation |
RFC 1035 specifies that a single string within a TXT record cannot exceed 255 characters. This is a fundamental DNS constraint, not email-specific.
For long records (DKIM public keys especially — RSA-2048 public keys are around 400 base64 characters), the record must be split into multiple strings. Most modern DNS providers split automatically when you paste a long value; some require manual splitting using quoted concatenation:
selector._domainkey.firm.co.uk. IN TXT ( "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUA..."
"...A4GNADCBiQKBgQDK+abcd..." )Resolvers concatenate the strings to reconstruct the original content; the 255-character split is invisible to DNS consumers.
The total size of a TXT record (sum of all its strings) has no hard DNS limit — theoretically up to 64 KB. In practice, records over a few KB are rare and can cause issues at edges of the DNS ecosystem.
For email records:
Records that routinely push size limits are DKIM with RSA keys and SPF with many includes/ranges.
The classic DNS UDP packet limit is 512 bytes total. This includes the query plus the response plus all DNS protocol overhead. Large records cannot fit in a classic UDP response.
When a response exceeds 512 bytes, resolvers without EDNS0 support receive a truncated response with the TC (truncation) bit set, prompting a retry over TCP. TCP-based DNS works but is slower and can be blocked by overly-restrictive firewalls.
For email infrastructure, a truncated response is bad news — senders may fail to retrieve SPF, DKIM or DMARC records correctly and fall back to unauthenticated evaluation.
EDNS0 (Extension Mechanisms for DNS, RFC 6891) allows DNS clients and servers to negotiate larger UDP response sizes, typically 1232, 2048, or 4096 bytes. All modern DNS software supports EDNS0; virtually all public resolvers use it.
With EDNS0:
A DNS response containing a 2-KB DKIM record fits comfortably in EDNS0 UDP (at 4096 bytes). Without EDNS0, the same response triggers TCP fallback.
When UDP fails (truncation, oversized response), DNS falls back to TCP port 53. This works but:
For email infrastructure, TCP fallback failures can silently break authentication. A sending server that cannot retrieve your DMARC record because of TCP blocking treats the domain as having no DMARC.
The split-on-255 pattern is the universal solution:
selector._domainkey.firm.co.uk. IN TXT ( "string-1-up-to-255-chars"
"string-2-up-to-255-chars"
"string-3-up-to-255-chars" )Most UK DNS provider UIs accept the full long value and split automatically. For manual splitting:
Resolvers reassemble automatically.
The most commonly affected. RSA-2048 public keys are around 400 base64 characters — exceeds 255 on its own. Always needs splitting.
Switching to Ed25519 (RFC 8463) produces a ~43-character public key, well under any limit. Some modern UK deployments use both key types side-by-side — RSA for broad compatibility, Ed25519 for compactness and speed.
SPF records can grow. A UK SME using Microsoft 365 plus five SaaS senders might have an SPF pushing 300-400 bytes. Still under 450-byte practical limit but getting close.
If SPF approaches 450 bytes, it also approaches the 10-DNS-lookup ceiling. Flattening or consolidation is usually the right remediation.
DMARC rarely exceeds limits but complex records with multiple rua and ruf addresses plus fo= combinations can grow. Keep under 300 bytes for safety.
| Provider | Long TXT handling |
|---|---|
| Cloudflare | Automatic splitting, handles long records transparently |
| AWS Route 53 | Requires manual splitting with quoted strings |
| Gandi LiveDNS | Automatic splitting in modern UI |
| Nominet DNS | Generally automatic |
| Google Cloud DNS | Requires manual splitting |
| Azure DNS | Requires manual splitting via API or template |
| 123-Reg, Fasthosts, Heart Internet | Varies; older UIs may truncate silently |
dig TXT selector._domainkey.firm.co.uk — check the output. If the record appears truncated or split incorrectly, the provider UI may have silently truncated during publication.
Suggests TCP fallback issues at some resolvers. Check response size; if over 512 bytes without EDNS0, some clients may fail.
Check DNS query response size. Oversized responses with buggy TCP handling cause silent failures.
Some resolvers return your record correctly, others do not. Usually indicates TCP fallback or EDNS0 negotiation issues at the failing resolver. Report to the resolver operator or work around.
A typical RSA-2048 DKIM public key in PEM format:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK+abcdefghijklm
nopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghij
klmnopqrstuvwxyz...Split across two strings:
selector._domainkey.firm.co.uk. IN TXT (
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK+abcdefgh"
"ijklmnopqrstuvwxyz...full remaining base64..."
)firm.co.uk. IN TXT (
"v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 ip4:192.0.2.0/24"
" include:spf.protection.outlook.com -all"
)dig after every publication. Catches silent truncation.Q: What happens if I paste a 300-character DKIM record into a UI that enforces 255?
A: Varies. Some UIs reject; some auto-split. Some (older) silently truncate. Always verify with dig after publication.
Q: Can I use Ed25519 DKIM to avoid splitting issues?
A: Yes — Ed25519 public keys are ~43 base64 chars, well under any limit. Recommended for new deployments where receivers support it.
Q: Does DNSSEC increase record size concerns?
A: Yes — DNSSEC adds RRSIG records that increase response sizes. EDNS0 is essential for DNSSEC-signed zones.
Q: Is there any tool to measure DNS record size?
A: dig shows response size in bytes. Online tools like DNSViz show size per record type.
Q: How do I test whether TCP fallback works in my network?
A: dig +tcp TXT large-record.example — forces TCP. If it succeeds, TCP is open. If fails, TCP is blocked — a DNS operational issue.
Q: What is the practical size of a modern DMARC record?
A: 200-300 bytes typically. Well under any limits.
Q: Does the 255-byte limit apply to the display or storage?
A: Storage — at the wire level. The 255 is a single DNS protocol string. Display in UI is cosmetic; what matters is how it appears on the wire.
Q: Can a single TXT record have multiple unrelated values?
A: Technically multiple strings can exist in one TXT record and concatenate. But for DNS semantics, each distinct entity (SPF, DKIM, etc.) lives in its own named TXT record.
Q: What if two TXT records exist at the same name (e.g. two SPFs)?
A: DNS allows multiple TXTs at one name but protocols like SPF and DMARC require exactly one. Multiple = error for those protocols.
Q: Does CDN-hosted DNS handle size limits differently?
A: Not fundamentally — same DNS rules. CDN DNS (Cloudflare, Route 53) supports EDNS0 properly; smaller players may have quirks.
Q: Is the 4096-byte EDNS0 limit universally supported?
A: Most modern resolvers and authoritative servers support up to 4096 bytes. Some constrained networks may negotiate smaller limits (1232 bytes is a common "safer" value).
Q: Are IPv6 networks more prone to DNS size issues?
A: Historically yes (fragment-related issues on constrained networks). Modern IPv6 DNS infrastructure has fewer issues. Test in your specific environment.
Q: What is the maximum realistic DKIM public key size?
A: RSA-4096 — around 800 base64 chars. Rarely used for mail (overkill); most UK deployments use RSA-2048 or Ed25519.
Q: Does SPF flattening produce especially large records?
A: Yes — flattened SPF records listing many IPv4 ranges can reach 400-500 bytes. Close to size concerns; combined with 10-lookup ceiling issues, favour include-based approaches where possible.
Q: Is there a best practice for ordering strings in a multi-string TXT?
A: Order does not matter semantically — resolvers concatenate in DNS-response order. Most DNS providers preserve your input order.
Q: Can TXT records contain binary data?
A: Not practically — TXT is designed for ASCII. Binary data is typically base64-encoded (as with DKIM public keys). Raw binary would cause parsing issues.
Q: How does Content-Security-Policy-style length affect TXT records?
A: CSP is an HTTP header, not DNS. Web-related headers have their own limits (typically 8 KB per header). Unrelated to TXT record size considerations.
Q: Does the 255-byte string limit apply to TXT records in reverse DNS?
A: Yes — same DNS protocol, same limits. Applies everywhere TXT is used.
Q: What is the longest commonly-seen TXT record for UK email?
A: Large DKIM (multiple sender keys) can approach 1 KB per selector. SPF with many includes or flattened ranges reaches 400-450 bytes. MTA-STS, TLS-RPT, DMARC are all short.
Q: Do UK regulators have any specific guidance on DNS record size?
A: Not specifically. NCSC guidance implicitly expects records fit within normal DNS operation. Size becomes a regulatory concern only when records fail due to size and cause security controls (SPF, DKIM, DMARC) to malfunction.
Q: Can I monitor record size as part of DNS health monitoring?
A: Yes. Monitoring tools (Datadog DNS, NS1 Pulsar) track response sizes. Commercial DMARC and email security dashboards flag oversized responses.
Q: What is the practical difference between response size and record size?
A: Response size is the total DNS response (all records plus overhead). Record size is just one record's data. Response can be much larger than any single record if multiple are returned.
Q: Do Akamai and Cloudflare behave differently at DNS size limits?
A: Both handle standard sizes correctly. Cloudflare specifically pushes EDNS0 adoption and supports large responses natively. Akamai equivalent in managed DNS.
Q: Can my upstream ISP's DNS limit response size?
A: Yes — some legacy ISP resolvers have EDNS0 disabled or limited. Public resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) universally support EDNS0. Recommend customers use public resolvers for reliable DNS.
Q: Is there a UK-specific DNS size guidance or compliance requirement?
A: No UK-specific mandate. NCSC guidance implicitly expects DNS operates reliably, which means size limits must not break critical records. Follow standard best practices.
Q: How do DNS size limits interact with DoH (DNS over HTTPS)?
A: DoH uses HTTPS as transport, effectively removing classic UDP size constraints. Modern DoH clients handle arbitrary-size responses. Increasingly common but not universal.
Q: Is there a size limit for NSEC/NSEC3 records in DNSSEC?
A: No specific limit — records can be reasonably large for zones with many entries. Typically not a concern in practice.
Q: What happens when DNS queries from my UK mail server exceed EDNS0-negotiated sizes?
A: Truncation, then TCP fallback. If TCP is blocked, failure. Configure firewall to allow DNS TCP 53 alongside UDP 53.
Q: Can I use compression to reduce TXT record size?
A: DNS protocol supports name compression, but applies to domain names in record data, not content. Cannot compress DKIM public keys or SPF mechanisms directly. Base64-encoded public keys are already near-optimal.
Q: Does the 255-byte limit apply to DKIM signature headers too?
A: No. DKIM signature lives in the message header (SMTP space), not DNS. Different size concerns — email messages have their own header limits (typically 998 chars per line per RFC 5322) but that affects SMTP not DNS.
Q: Can I split a TXT record across multiple lines in a zone file?
A: Yes — standard BIND zone file format supports this with parentheses for continuation. Most DNS hosts handle this transparently via UI.
Q: Are there DNS providers that handle size limits badly enough to avoid?
A: A handful of cheaper DNS hosts have known issues with long TXT records. Signs include silent truncation, inconsistent query results, EDNS0 not supported. Consider migrating if your records are size-sensitive.
Q: What is the impact of splitting on DNS caching?
A: None — caches treat the record as a single concatenated value. Splitting is a wire-format concern, not a semantic one.
Q: Can I use subdomain delegation to avoid size issues?
A: Not directly for size — the record at the subdomain faces the same limits. Subdomain delegation separates administration, which can incidentally limit accidental large records.
Q: How does CNAME-delegated DKIM interact with size limits?
A: The CNAME points at the provider's DKIM hostname. The provider's TXT at that hostname handles the split appropriately. From your side, you publish only a short CNAME, not a large TXT.
Q: Does Anycast DNS affect size handling?
A: No — Anycast is a routing scheme; the underlying DNS protocol and size rules are the same. Anycast providers (Cloudflare, AWS) handle size correctly.
Q: What impact does a 1 KB DKIM record have on DNS infrastructure?
A: Minimal in 2026. Modern DNS comfortably handles KB-sized records. Latency adds a few milliseconds; load on authoritative servers is minor.
Q: Are there plans to lift the 255-byte per-string limit?
A: No — the limit is baked into the DNS wire protocol. Changing would require a new DNS format. Not on any standards track. The workaround (multi-string concatenation) works adequately.
Q: How does DNS over TLS (DoT) or DNS over QUIC (DoQ) affect size?
A: Transport protocols — DoT, DoQ, DoH — lift classic UDP 512 concerns entirely. Responses can be arbitrarily large. Growing adoption in UK but not universal yet.
Q: Can I see how large my DNS responses are?
A: dig +norec TXT record.example shows MSG SIZE rcvd. Gives you the total response size for that query. Useful for catching oversized responses before they cause issues.
Q: Does UK public sector usage of DNS typically face size issues?
A: No — UK government DNS infrastructure supports EDNS0 and large responses. The common email security records fit comfortably.
Q: What if I need to publish an extremely large TXT record (multi-KB)?
A: Split appropriately. Test thoroughly. Consider whether the size is necessary — can the content be published elsewhere and referenced? For email records, the sizes involved are well-managed.
Q: Is there a simpler tool than dig for checking record sizes?
A: host command is simpler but shows less detail. Online tools (MXToolbox, DNS Checker) provide UI-based size checks. Commercial DNS monitoring includes size metrics.
Q: Are UK businesses more affected by DNS size limits than others?
A: No — DNS protocol rules are global. The same size considerations apply universally. UK businesses face the same limits as anyone else.
Q: Does the 255-byte limit ever cause operational issues that are invisible to administrators?
A: Yes — silent truncation in older DNS provider UIs is the classic case. An admin pastes a 350-char DKIM record; the UI silently keeps only the first 255 chars; the record is invalid but no error is shown. Always verify with dig.