--- title: Free TXT Record Lookup description: Read every TXT record on a name — SPF, domain-verification tokens, DKIM selectors, ACME challenges — in full. A record split into several 255-character strings is shown joined, the way SPF and DKIM read it. 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. A record split into several 255-character strings is shown joined, the way SPF and DKIM read it. Confirm a verification record is live before you press 'Verify' for the fifth time. [How to use this tool](/blog/how-to-check-txt-records) Result No result yet Fill in the form above and run it — the result appears here. Monitor this 24/7 — get alerted when a failure is confirmed. [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, one per row, with the strings of a long record already joined — the way SPF, DKIM and verification checks read it. 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 strings of up to 255 characters. - 3 Read them joined — Applications concatenate the strings of one record before parsing, and so does this tool: each row is one record, already joined. To see where a record is split, use the dig line below. 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 rows here). One record with two strings — "v=spf1 include:…" "~all" in dig — is one row here, already joined. SPF must be a single record, so two rows starting v=spf1 is the bug. ### Quotes and escaping Values are shown without the surrounding quotes. In dig output a literal quote inside is escaped \" and a backslash-DDD sequence is a byte that isn't printable. DKIM keys are long base64 strings that normally span two or three strings; here they appear as one value. ### NXDOMAIN, no records Either the name doesn't exist or it has no TXT records — this tool shows both as NXDOMAIN . Check the label ( _dmarc , the selector, the underscore), then look up another type on the same name to see whether it exists. ### TTL Verification providers re-check periodically; a low TTL lets a fix take effect within minutes. Once verified, the record's TTL rarely matters. The tool doesn't show TXT TTLs; dig does. ## 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 alerted when an outage is confirmed — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 15 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, and this tool shows the joined value; dig shows the parts. 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 — plus an A+ to F DNS health grade for the zone: nameservers, delegation, DNSSEC and CAA.](/dns-propagation-checker) - [Whois LookupModern RDAP-based domain registration lookup: registrar, expiry, nameservers, status flags.](/whois-lookup) - [DNS Health CheckerGrade a domain's DNS A+ to F: how many nameservers it has and on which networks, lame delegation, whether the registry and the zone agree, SOA serials, DNSSEC and CAA, with the fix for every problem. Then see what every probe location answers, on a map.](/dns-health-checker) --- Canonical page: https://watchfor.io/txt-record-lookup · Site guide: https://watchfor.io/llms.txt