TXT record lookup
Shows a domain's text records, from SPF to the ownership tokens left by Google, Microsoft and other services. DMARC lives under the _dmarc name and is read by the email security check.
Need another tool?
Pick one of the 25 belowOutput
What the TXT record lookup shows
A TXT record lookup shows the text records published at a name, with the TTL of each. The query goes to Cloudflare's 1.1.1.1 from the IPVIEW server over the toolkit's own DNS engine. TXT answers are the ones most likely to overflow a UDP packet, so a truncated answer is retried over TCP, and if that connection fails the page says the answer is incomplete rather than passing a shorter list off as the whole.
At the apex, TXT records usually hold the SPF record (v=spf1) and ownership tokens left by Google, Microsoft, a CDN or a certificate authority. DMARC lives at _dmarc.example.com and DKIM keys at selector._domainkey.example.com; both can be asked for here by typing that name, or read together by the Email security check.
How to read the result
The table lists Name, Value and TTL; long records split into quoted strings by the DNS are shown joined. Two SPF records at one name is an error, not twice the protection: receivers treat it as a PermError and apply no SPF at all. A token for a service the domain stopped using years ago is still a statement about who controls the name. The TTL here is the time left on 1.1.1.1's cached copy and can be lower than the TTL set in the zone; the Full report asks the zone's own nameservers for that.
An empty answer is read from the response code. No TXT record means the zone answered and has none at that name. The name does not exist at all means NXDOMAIN, which for _dmarc.example.com simply means no DMARC is published. The query failed means no answer was had. Under an empty answer, the authority section shows how long resolvers keep the negative answer, which is why a record just added can still read as none.
When it is useful
A service asks you to prove ownership of a domain by publishing a token and its check keeps failing: see whether the token is actually published at the name it asked for, with the exact value, and how long the previous negative answer will be cached.
Mail from the domain lands in spam: read the SPF record and check it names every service that sends on the domain's behalf. Then run the Email security check, which reads SPF, DMARC and the common DKIM selectors together, and the Full report, which counts the SPF lookups against the limit of ten.
Common questions
What is a TXT record used for?
Any text a domain wants to publish: SPF rules, DMARC policies, DKIM public keys and ownership tokens that let a service confirm you control the domain. The format is the concern of whoever reads it.
Why can I not see my DMARC record here?
DMARC is published at _dmarc.example.com, not at the domain itself. Type that name here, or use the Email security check, which looks there for you.
Can a domain have two SPF records?
It can, and it must not. Receivers treat more than one v=spf1 record as a permanent error and apply no SPF at all. Merge them into one.
Why does the page say the answer is incomplete?
The UDP answer was truncated and the TCP retry could not connect. What is shown is real but may not be all of it; try again, or ask the nameserver directly.
Limits. The DNS, WHOIS and SSL tools allow up to 20 requests a minute per IP address. Ping, traceroute and MTR send real packets to their target, so they allow 6 a minute.
The port check runs only against your own IP address. That is deliberate: the question people actually have, "is this port reachable from outside?", is answered by it, while this server cannot be used to scan anyone else's network.
Private and reserved addresses. These are refused by the tools that really connect to their target: the SSL check, ping, traceroute, MTR and the port check. The DNS tools have no such limit, because they only ask a nameserver a question and never connect to the address itself.