A TXT lookup returns the free-text DNS records attached to a domain - used for domain verification, SPF policies, and other machine-readable notes that do not fit an existing record type.
What is a TXT record?
A TXT (text) record is a DNS entry that holds arbitrary text under a domain or subdomain name. RFC 1035 defined the record type for human-readable notes; RFC 1464 later formalized an "attribute=value" convention so software could parse them too. In practice almost every TXT record on the internet today is machine-readable: a verification token, an SPF policy, or a DKIM public key.
A domain can hold any number of TXT records, and a single record can itself be split into multiple quoted strings. DNS resolvers join those strings back together before handing the record to an application, so from the outside a TXT record looks like one continuous value even when the zone file stores it in pieces.
- Any name in the zone can have TXT records - the apex, a subdomain, or an underscore-prefixed name like _dmarc or a selector._domainkey
- A domain typically carries several unrelated TXT records at once: one for SPF, one or more for site verification, sometimes one for DMARC policy hints
- TXT is the catch-all record type - new protocols reuse it instead of registering a dedicated DNS record type with IANA
Common uses for TXT records
Three uses account for most TXT records seen in the wild.
- Domain verification - Google Search Console, Microsoft 365, and similar services ask you to add a TXT record containing a token they generate, proving you control the DNS zone before they activate a service
- SPF (Sender Policy Framework) - a TXT record starting with "v=spf1" lists which mail servers are allowed to send email as the domain; receiving mail servers check it against the sending server's IP
- DKIM public keys - TXT records at a selector subdomain (e.g. selector1._domainkey.example.com) publish the public key receivers use to verify a message's DKIM signature
TXT record syntax
A TXT record's value is one or more quoted character-strings. Each character-string is limited to 255 bytes by the DNS wire format (RFC 1035); a resolver library concatenates the strings into a single value before returning it, so applications never have to split them back apart manually.
A typical SPF record looks like this in a zone file:
| Zone file line | Meaning |
|---|---|
| example.com. IN TXT "v=spf1 include:_spf.google.com ~all" | Authorizes Google Workspace to send mail, soft-fails everything else |
| example.com. IN TXT "google-site-verification=abc123XYZ" | Domain ownership token for a Google service |
| _dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:d@example.com" | DMARC policy record (lives under the _dmarc subdomain, not the apex) |
| selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." | DKIM public key for the "selector1" selector |
TXT record size limits
Two limits matter and they are easy to conflate. A single character-string inside a TXT record is capped at 255 bytes by the wire format - this is a hard protocol limit, not a policy choice. A TXT record can exceed 255 bytes in total by splitting the value across multiple adjacent quoted strings, which resolvers reassemble transparently; this is why long DKIM keys are often written as two or more consecutive quoted segments in the zone file.
The overall UDP DNS response is historically capped near 512 bytes without EDNS0, though virtually all modern resolvers negotiate larger responses or fall back to TCP automatically, so this rarely causes practical problems for a handful of TXT records. It can matter when a domain accumulates many verification records from different providers alongside SPF and DKIM - some DNS providers warn once a zone approaches these thresholds.
Reading TXT lookup results
The lookup groups every TXT record found under the TXT type badge and shows a count. Each entry lists the domain name it was found on and the reassembled value - the tool joins the record's quoted segments the same way a resolver library does, so what you see matches what a mail server or verification script actually reads. A "no records found" result means the name genuinely has no TXT record, not that the lookup failed - many subdomains never have one.
When several TXT records exist for the same name (common on a domain with SPF plus two or three verification tokens), each is listed as a separate entry so you can identify which one is the SPF policy and which are unrelated verification strings.
FAQ
How many TXT records can one name have?
A single name can hold many TXT records at once - SPF, DKIM, a DMARC policy at _dmarc, and several verification strings often coexist under the same domain. A resolver returns all of them, and each consuming system filters for the prefix it cares about (a mail server reads only the "v=spf1" one, a CA reads only its verification token). The one exception is that a name should carry no more than a single valid SPF record.
Why does my TXT record show up split into two pieces in the zone editor?
DNS TXT records are made of quoted character-strings capped at 255 bytes each. A value longer than that has to span two or more quoted strings in the zone file. Most authoritative DNS providers hide this and let you paste one long value, silently splitting it for you.
Do TXT records have a TTL like other DNS records?
Yes, TXT records carry the same TTL mechanism as any other record type. A short TTL (a few minutes) is common right after adding a verification or SPF record, so a mistake can be corrected and re-propagated quickly; it is often raised once the record is confirmed working.
Can I delete an old domain-verification TXT record once a service is verified?
Usually yes, but check the provider's documentation first. Some services (certain Google Workspace features, for example) only check the token once at verification time and it is safe to remove afterward; others re-check the record periodically to confirm continued ownership and will disable the integration if it disappears.
Is a TXT record the same thing as a DMARC or DKIM record?
DMARC and DKIM records are both published as TXT records - DMARC always at a name starting with _dmarc, DKIM at a selector subdomain ending in _domainkey. TXT is the underlying record type; DMARC and DKIM are conventions for what goes inside it and where it is placed.
Why do two different services ask me to add TXT records with almost identical-looking tokens?
Each verification provider generates its own opaque token and expects its own prefix (google-site-verification=, MS=, facebook-domain-verification=, and so on). They coexist fine as separate TXT records on the same name - there is no conflict as long as each keeps its own record rather than overwriting another provider's.