TXT Records: The DNS Junk Drawer That Runs Half the Internet

A Record Type With No Opinion

Every other common DNS record type comes with an opinion baked in. An A record insists its value be a valid IPv4 address. An MX record insists on a hostname plus a priority number. A CNAME insists its value point at another name, and refuses to coexist with anything else at that name. A TXT record has none of that. Its entire specification amounts to "store some text here," and that's it — no validation beyond basic length rules, no required format, no opinion about what the text should mean.

That absence of opinion turned out to be the whole point. Rather than the DNS specification needing to anticipate every future use case and invent a dedicated record type for each one, TXT became the place new, unanticipated needs could simply borrow existing infrastructure. Domain verification didn't need a new record type invented for it. Email authentication didn't either. They just needed somewhere to put a string, and TXT was already there, universally supported, on every DNS server ever built.

The Formal Structure, Briefly

A TXT record's zone-file representation is a name, TTL, class, type, and a quoted text value:

example.com.    3600    IN    TXT    "some arbitrary text value"

The one hard limit that actually matters in practice: a single quoted string within a TXT record is capped at 255 characters at the protocol level. Values longer than that get split across multiple quoted strings within the same record, concatenated back together by whatever's reading them — this is exactly why long DKIM public keys, which routinely exceed 255 characters, appear as several adjacent quoted segments rather than one continuous string.

How This Generic Field Became Load-Bearing

The history here isn't really about any single decision — it's about a pattern repeating across a couple of decades. Each time a new internet service needed to prove something about a domain (that its operator controlled it, that its mail was legitimate, that a particular configuration applied), the engineers building that service faced a choice: propose a new, dedicated DNS record type through the standardization process, which is slow and requires broad resolver support to actually become usable, or just publish a specially formatted TXT record, which works immediately on every DNS server that has ever existed. Almost everyone chose the second option, and the cumulative effect is a record type that now quietly underpins email trust, domain ownership proof, and dozens of third-party integrations.

SPF: The First Major TXT Squatter

Sender Policy Framework was one of the earliest major systems to adopt TXT wholesale. It lists which mail servers are authorized to send email claiming to be from a given domain, published as a TXT record beginning with v=spf1, followed by mechanisms like include, a, mx, and ip4/ip6 that build up the authorized sender list, ending in a qualifier (commonly ~all or -all) describing how strictly to treat anything not matched.

DKIM: Cryptography Riding the Same Rails

DKIM takes a different technical approach — cryptographic signing rather than a simple allowlist — but it too rides on plain TXT records, published at a selector-specific subdomain like selector1._domainkey.example.com, holding a public key formatted with a v=DKIM1 prefix. A receiving mail server fetches this record, uses the public key to verify a signature attached to the message headers, and confirms both that the message wasn't tampered with in transit and that it genuinely originated from infrastructure holding the corresponding private key.

DMARC: The Policy Layer on Top

DMARC ties SPF and DKIM together into an enforceable policy, published as a TXT record at _dmarc.example.com with a value like v=DMARC1; p=quarantine; rua=mailto:reports@example.com. The p= tag tells receiving servers what to do with mail that fails both SPF and DKIM alignment — do nothing but observe (none), route to spam (quarantine), or reject outright (reject) — and the reporting address collects aggregate data that's genuinely useful for understanding what's sending mail as your domain, sometimes surfacing unauthorized senders nobody knew about.

Domain Verification: The Quiet Fourth Use Case

Alongside the three email-authentication systems, an entirely separate use case grew just as large: proving domain ownership to a third-party service without handing over any credentials. A service generates a unique token, you publish it as a TXT record, and the service checks for its presence — since only someone with actual DNS zone access could publish that specific string, finding it there is treated as reasonably strong proof of control. This pattern is now standard across search consoles, cloud platforms, SaaS custom-domain features, and countless developer tools.

Comparison: TXT Against Other Record Types

What SPF, DKIM, and DMARC Each Actually Check

Real-World Scenarios

Common Mistakes

Best Practices

Treat TXT record hygiene as an ongoing responsibility, not a one-time setup task — email infrastructure changes, third-party services get decommissioned, and DNS rarely gets cleaned up automatically alongside those changes. Roll out DMARC gradually through its monitoring phase before tightening enforcement. Keep exactly one SPF record, using include mechanisms rather than duplicate records. And whenever debugging deliverability, start at the TXT layer before assuming the problem lives somewhere more complicated.

Related Tools

Check any domain's TXT records live with TXT Lookup. Dig deeper into mail routing with MX Lookup, or check SPF and DKIM specifically with SPF Lookup and DKIM Lookup. For the domain-verification use case specifically, read Domain Verification next, and for the security implications of misconfigured TXT records, see TXT Record Security.