TXT Record Lookup

A TXT record is a DNS resource record whose data is one or more text strings. RFC 1035 defined it in 1987 as descriptive text with no fixed meaning, and RFC 1464 later suggested the attribute=value convention most modern uses follow. TXT became the general purpose record for protocols that attach a policy or a proof of ownership to a domain.

example.com.                      3600  IN  TXT  "v=spf1 include:_spf.google.com -all"
example.com.                      3600  IN  TXT  "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"
_dmarc.example.com.               3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"
selector1._domainkey.example.com. 3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
_mta-sts.example.com.             3600  IN  TXT  "v=STSv1; id=20260917T120000"
_smtp._tls.example.com.           3600  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"
default._bimi.example.com.        3600  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"

The first two live at the domain itself: SPF (RFC 7208) lists the servers allowed to send mail, and the verification string proves to Google Search Console that you control the zone (Microsoft 365 uses MS=ms followed by digits, Apple uses apple-domain-verification). The rest live at reserved subdomains: DMARC policy (RFC 7489) at _dmarc, the DKIM public key (RFC 6376) at a selector under _domainkey, the MTA-STS policy pointer (RFC 8461) at _mta-sts, TLS reporting (RFC 8460) at _smtp._tls, and the BIMI logo location at a selector under _bimi.

A TXT record lookup returns every text string published at the exact name you query, with the TTL on each record. It does not walk subdomains, so a lookup on example.com shows the SPF and verification records but not the DMARC record at _dmarc.example.com or a DKIM key under _domainkey. Query those names directly, or use our SPF checker, DMARC checker and DKIM checker. Our DNS lookup tool sends the query to Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) and OpenDNS at the same time and marks whether they agree.

Open Command Prompt or PowerShell. nslookup ships with every version of Windows, and Resolve-DnsName is the PowerShell cmdlet. Add a resolver address, as in the last two lines, to ask a public resolver instead of your network's.

nslookup -type=TXT example.com
Resolve-DnsName -Type TXT example.com
nslookup -type=TXT example.com 8.8.8.8
Resolve-DnsName -Type TXT example.com -Server 1.1.1.1

macOS ships dig, so no install is needed. Open Terminal and run one of these. The +short form prints only the record values, and the @ form sends the query to a specific resolver.

dig TXT example.com
dig TXT example.com +short
dig @1.1.1.1 TXT example.com

dig and host come from the dnsutils package on Debian and Ubuntu and from bind-utils on Fedora and RHEL. The +noall +answer options print only the answer section, and +tcp forces the query over TCP when you suspect a truncated UDP answer.

dig TXT example.com +noall +answer
host -t TXT example.com

After you change a TXT record, the authoritative nameservers answer with the new value immediately, and every recursive resolver that cached the old record keeps serving it until the cached TTL runs out. Our DNS lookup tool above shows whether Google, Cloudflare, Quad9 and OpenDNS agree yet, and the Authoritative option reads the value straight from the zone's own nameservers. The DNS propagation checker asks resolvers in more locations and lays the results out side by side.

Google, Microsoft and Apple verify from their own resolvers, so a verification that fails right after you add the record usually just needs the previous cached answer to expire.

The limit applies to a single string, not to the record. RFC 1035 stores each string with a one-byte length prefix, so a string holds at most 255 bytes. A TXT record may contain any number of strings, and a reader joins them in order with nothing in between. The whole record can be as large as the DNS message allows, up to 65,535 bytes.

selector1._domainkey.example.com. 3600 IN TXT (
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx7K"
    "...rest of the 2048-bit key..."
    "IDAQAB" )

A 2048-bit RSA DKIM key is about 400 characters once base64 encoded, so it always spans two strings. Most DNS control panels split a long value automatically, but some require you to enter each quoted string yourself. DNSX joins the strings back together in the result, so what you see is the value a mail server evaluates.

Every service that verifies domain ownership asks you to add a TXT record, and few people remove them afterwards. A company domain that has been through Google Workspace, Microsoft 365, Atlassian and a few SaaS tools easily carries ten or more strings at the apex, each 60 to 100 bytes, and the answer runs past 512 bytes.

DNS over UDP was limited to 512 bytes by RFC 1035. A nameserver with a bigger answer sets the TC (truncated) flag, and the client is supposed to retry over TCP. EDNS0 (RFC 6891) lets a client advertise a larger buffer, usually 1,232 to 4,096 bytes, so most answers fit in one UDP packet. A tool that does neither sees an empty or partial answer, which is why a TXT check sometimes reports no SPF record on a domain that plainly has one. DNSX sends every query with a 4,096-byte EDNS0 buffer and, if the answer still comes back truncated, repeats it over TCP as RFC 7766 requires.

Every lookup on DNSX is also a JSON endpoint on api.dnsx.dev that you can call from curl or a script with no API key. The response has one result per resolver with its records and TTLs.

curl https://api.dnsx.dev/dns/txt/google.com