TXT Record Lookup

TXT records hold free-form text used for SPF, DKIM, DMARC, and domain verification. Look up any domain's TXT records across 21 global servers to read them and confirm they have propagated everywhere.

Global DNS Propagation

New York, USA Google	---
Chicago, USA Gcore	---
Los Angeles, USA Cloudflare	---
Toronto, Canada CIRA	---
Mexico City, MX OpenDNS	---
London, UK Quad9	---
Frankfurt, Germany DNS.Watch	---
Paris, France FDN	---
Amsterdam, NL OpenNIC	---
Moscow, Russia Yandex	---
Singapore Singtel	---
Tokyo, Japan IIJ	---
Mumbai, India Google India	---
Seoul, Korea KT	---
Dubai, UAE Etisalat	---
Sydney, Australia Telstra	---
Auckland, NZ Cloudflare	---
São Paulo, Brazil NIC.br	---
Buenos Aires, AR Telecom Arg	---
Johannesburg, ZA ISPA	---
Cairo, Egypt Telecom Egypt	---

DNS Map

0 0

What a TXT record does

A TXT record stores arbitrary text at a domain name. DNS was not built for this, but the format turned out to be a convenient place to publish machine-readable policy. Today TXT records carry email authentication rules and ownership proofs that other services read.

A single name can hold many TXT records at once. The lookup returns all of them. For the full explanation, read what is a TXT record.

How to read the results

Each row shows one of the 21 global servers and the TXT strings it returned, quoted as stored. You will often see several unrelated strings on the same name: an SPF policy, one or more verification tokens, and other service records side by side. Every server should return the same set once propagated.

DKIM and DMARC live on their own subdomains, not the root. DKIM sits at selector._domainkey.yourdomain.com and DMARC at _dmarc.yourdomain.com. Enter that full name to read them, since a root lookup will not show them.

Common TXT record values

An SPF record starts with v=spf1 and lists the servers allowed to send mail, for example v=spf1 include:_spf.google.com ~all. A DMARC record starts with v=DMARC1 and sets a policy such as p=reject. See SPF and DMARC.

Verification tokens look like google-site-verification=abc123 or a random string from a SaaS provider. These are safe to leave in place once added; removing one can break the service that checks for it.

Troubleshooting TXT records

A domain should publish only one SPF record. Two v=spf1 strings on the same name is an error and causes SPF to fail. If mail authentication is failing, look up the TXT records here and confirm there is exactly one SPF policy and that it lists every sending source.

Long TXT values are split into 255-character chunks in DNS and joined back together by the reader, so a DKIM key spanning multiple quoted strings is normal. If a verification check fails right after you add a token, the record may still be propagating. Run the lookup and confirm every region returns the new string before you retry the check.