DDDevDomeTrack. Protect. Grow.

TXT Record Lookup

Every TXT record for a domain, shown exactly as published: multi-chunk records preserved, SPF and DMARC analyzed, verification strings visible. All from your browser.

Your browser queries these services directly, so the name you look up and your IP address are visible to them: Cloudflare DNS and Google Public DNS (both public recursive resolvers) for records and comparison, and rdap.org, a redirector that forwards to the registry's RDAP server, for registration data. DevDome does not proxy, see or store these lookups. Privacy policy.

Run a lookup to get an evidence-based summary: web resolution, delegation, DNSSEC, email records, CAA and expiration, each with the observation behind it.
Enter a name above to query common DNS records (A, AAAA, CNAME, MX, TXT, NS, SOA, CAA) from a public recursive resolver, or pick a specific type including DS, DNSKEY, SRV, TLSA, SVCB and HTTPS.
Registration data appears here via RDAP: registrar, creation and expiration dates, EPP status codes, nameservers and DNSSEC delegation state.
SPF and DMARC analysis appears here: record syntax, the 10-DNS-lookup limit, policy strength and common misconfigurations, with the exact records as evidence.
Compares one record type between Cloudflare and Google. These are observations from two public recursive resolvers, not proof of global propagation. Add an expected value above to check whether your change is visible to each.

Shown as published, not as normalized

TXT is the junk drawer of DNS, and the details matter more than anywhere else: a DKIM key split across chunks, a stray space in an SPF mechanism, a verification string pasted with smart quotes. This lookup preserves what the zone actually publishes: records with multiple character-strings show both the joined value receivers compute and the exact chunks on the wire, so a broken split is visible instead of silently papered over.

For the records that carry policy, display is not enough: the Email tab parses SPF against the RFC 7208 rules (single record, 10-lookup limit, all qualifier) and DMARC against its required tags, each finding tied to the exact record text as evidence. Service names like _dmarc.example.com or selector._domainkey.example.com can be entered directly.

Check your DMARC policy →

TXT record FAQ

What are TXT records used for?

Almost everything that is not routing. The big three are email authentication: SPF (which servers may send as your domain), DKIM public keys (at selector._domainkey names) and DMARC policy (at _dmarc). The rest are mostly ownership verification strings from Google, Microsoft, and certificate or SaaS providers. A domain accumulating years of stale verification records is normal, but each one is also a small disclosure of which services you use.

Why is my TXT record split into multiple quoted chunks?

A single TXT character-string is limited to 255 bytes, so longer values, DKIM keys especially, are published as multiple quoted chunks that receivers concatenate. Most tools silently join them, which hides how the record is actually published and can mask a broken split. This tool shows the joined interpretation and, when a record has multiple chunks, the exact published chunks underneath it.

How do I look up a DKIM record?

DKIM lives at a name built from a selector: selector._domainkey.yourdomain.com, and the selector is only discoverable from the DKIM-Signature header of a real email. Open a message’s headers, find s=selector, then enter the full name above with the TXT type selected. This tool cannot enumerate selectors for you, and neither can any DNS tool: that is by design in DKIM.

Why do I see an SPF record but mail still fails SPF?

Publishing a record is only step one. Common failures the Email tab checks for: more than one SPF record (receivers treat that as a permanent error), more than 10 DNS lookups from include chains (also a permanent error), and +all (which passes everyone and gets your record ignored by reputation systems). Beyond syntax, the sending server must actually be covered by the mechanisms, which only aggregate DMARC reports can confirm.

Is there a limit on how many TXT records a domain can have?

No hard protocol limit: a name can hold many TXT records and the response simply grows. The practical constraints are UDP response size (large sets force TCP retries and slow resolution) and the strict one-SPF-record rule. If your TXT set is growing, prune stale verification strings; if your SPF is growing, flatten includes rather than adding a second record.

More free tools: SPF Checker · DMARC Checker · MX Lookup · DNS & WHOIS Lookup