--- title: Free TXT Record Lookup description: Read every TXT record on a name — SPF, domain-verification tokens, DKIM selectors, ACME challenges — in full, with quotes and string boundaries shown as published. Confirm a verification record is live before you press 'Verify' for the fifth time. canonical: https://watchfor.io/txt-record-lookup --- [Back to all free tools](/free-tools) # TXT Record Lookup Read every TXT record on a name — SPF, domain-verification tokens, DKIM selectors, ACME challenges — in full, with quotes and string boundaries shown as published. Confirm a verification record is live before you press 'Verify' for the fifth time. Result No result yet Enter the inputs above and press Run. Results appear here in a moment. Monitor this 24/7 — get alerts on the first failure. [Start free](/auth/sign-up) Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our [Terms](/legal/terms). ## What is TXT Record Lookup ? TXT records hold free-form text, and over the years everything that needed a place to publish a string moved into them: SPF policies ( v=spf1 … ), DKIM public keys under selector._domainkey , DMARC policies under _dmarc , Google/Microsoft/Facebook site-verification tokens, ACME challenges for certificate issuance, and a dozen vendor-specific *-site-verification= records. A single name can carry many of them, and long values are split into 255-character strings that the reader has to join. This tool returns every TXT record on a name exactly as published — each string, the quotes and boundaries, the TTL. It is the fastest way to confirm a verification record is actually live before you press "Verify" again, to read the SPF record a mail server will evaluate, and to find the leftover verification tokens for services the company stopped using in 2019. ## How it works The query is plain DNS; the interesting part is where to point it: - 1 Pick the right name — SPF and most verification tokens live on the apex ( example.com ). DMARC lives on _dmarc.example.com . DKIM lives on ._domainkey.example.com . ACME challenges live on _acme-challenge. . The record you're looking for is often on a name you didn't query. - 2 Query `QTYPE=TXT` — The resolver returns every TXT record on that name, each as one or more quoted strings. - 3 Read them as published — Strings are shown with their boundaries so a record split at 255 characters is recognisable; applications concatenate the strings of one record before parsing. To interpret the mail-related ones rather than just read them, the SPF, DKIM and DMARC checkers parse and grade the same records. ## When you'd use it ### Domain verification that won't verify Google Search Console, Microsoft 365, Apple Business, Facebook, Stripe — they all ask for a TXT token. When "Verify" fails, look the record up against a public resolver: it's missing, on the wrong name ( www instead of the apex), has a stray quote, or hasn't propagated yet. ### Reading the SPF record Before editing SPF, see what's there and what a receiver sees — including whether there are two v=spf1 records, which is invalid and makes SPF fail entirely. ### Certificate issuance with DNS-01 Let's Encrypt or your ACME client says the challenge wasn't found. Look up _acme-challenge. TXT against 1.1.1.1 and 8.8.8.8 : if it's there, wait for propagation; if it's not, the DNS API call failed. ### Cleaning up old records Verification tokens for tools nobody uses anymore still sit on the apex, making the TXT response bloated and occasionally too big for UDP. List them and delete the dead ones. ## Reading the result ### Multiple records vs multiple strings Two TXT records are two separate answers (two lines). One record with two strings is one line with two quoted parts — "v=spf1 include:…" "~all" — that the application joins. SPF must be a single record. ### Quotes and escaping Values are shown quoted. A literal quote inside is escaped \" ; a backslash-DDD sequence is a byte that isn't printable. DKIM keys are long base64 strings and normally span two or three quoted parts. ### Empty answer NOERROR with nothing means the name exists but has no TXT records. NXDOMAIN means the name doesn't exist — check the label ( _dmarc , the selector, the underscore). ### TTL Verification providers re-check periodically; a low TTL lets a fix take effect within minutes. Once verified, the record's TTL rarely matters. ## Check it yourself dig TXT example.com @1.1.1.1 +noall +answer dig TXT _dmarc.example.com and dig TXT selector._domainkey.example.com read the DMARC and DKIM records on their own names. ## Common pitfalls ### Two SPF records Adding a second v=spf1 record instead of merging into the existing one makes SPF return PermError — every receiver treats the domain as having no valid SPF. Merge the include: mechanisms into one record. ### Putting the record on the wrong name Providers say "add a TXT record to your domain" and mean the apex; the DNS UI's Name field wants @ , not example.com (which becomes example.com.example.com ). The lookup shows which name actually got it. ### Pasting with smart quotes A token copied from a rich-text email arrives with curly quotes or a trailing space. The record looks right in the dashboard and never matches. Look it up and compare byte for byte. ## Run TXT Record Lookup on every change, not just once. Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card. [Start free](/auth/sign-up) ## Frequently asked questions Where is the SPF record? A TXT record on the domain itself (the apex) starting with v=spf1 . There must be exactly one. The old SPF record type (type 99) is obsolete — receivers only read TXT. Where is the DMARC record? A TXT record on _dmarc.example.com starting with v=DMARC1 . Subdomains inherit the organisational domain's policy unless they publish their own. Where is the DKIM record? A TXT record on ._domainkey.example.com , where the selector is chosen by whoever signs the mail ( google , selector1 , k1 …). Find the selector in a signed message's DKIM-Signature: s= header. Why is my TXT record split into two parts? A single DNS string is at most 255 bytes; longer values are stored as multiple strings in one record. Readers concatenate them. DKIM 2048-bit keys always need this. How long does a TXT record take to appear? As long as the old TTL (or the negative-caching TTL from the SOA if the name didn't exist before) — commonly 5 minutes to an hour. Query the authoritative nameserver to see it immediately. ## Related dns tools - [DNS LookupResolve A, AAAA, MX, TXT, NS, SOA, CNAME, PTR, CAA, SRV records for any domain.](/dns-checker) - [DNS PropagationCheck how a DNS record looks from every prober region simultaneously — spot stale anycast nodes and propagation gaps on a world map.](/dns-propagation-checker) - [Whois LookupModern RDAP-based domain registration lookup: registrar, expiry, nameservers, status flags.](/whois-lookup) - [A Record LookupFind the IPv4 address a domain resolves to — every A record with its TTL, from the resolver of your choice. Spot a stale IP after a migration, a missing record behind a 'site can't be reached', or a round-robin set that is one address short.](/a-record-lookup) --- Canonical page: https://watchfor.io/txt-record-lookup · Site guide: https://watchfor.io/llms.txt