--- title: Domain verification failing? How to check TXT records with the TXT Record Lookup description: Google, Microsoft, Stripe or Atlassian asks you to add a TXT record, you add it, and Verify still fails. To check a TXT record, look up every TXT record on the exact name the service checks and confirm your token is there, complete and unquoted. Here's how to do it with the free TXT Record Lookup, what a busy real domain looks like, and the dig commands that show how long strings are split. canonical: https://watchfor.io/blog/how-to-check-txt-records --- # Domain verification failing? How to check TXT records with the TXT Record Lookup 2026-10-04 · WatchFor Team · Guides · guides, dns, email Google, Microsoft, Stripe or Atlassian asks you to add a TXT record, you add it, and Verify still fails. To check a TXT record, look up every TXT record on the exact name the service checks and confirm your token is there, complete and unquoted. Here's how to do it with the free TXT Record Lookup, what a busy real domain looks like, and the dig commands that show how long strings are split. To check a TXT record, look up all TXT records on the exact name the service asked for (usually the bare domain, `example.com`) and find your value in the list. If it's there, complete and without extra quotes or spaces, the record is published, and a failing "Verify" button is a cache or timing issue on the service's side. If it's missing, the record sits on a different name or at a DNS provider your domain doesn't use. The free [TXT Record Lookup](/txt-record-lookup) lists every TXT record on a name, from a real WatchFor location, in under a second. No signup. ## What this tool answers *What TXT records does this name publish right now?* Reach for it when a domain verification (Google Search Console, Microsoft 365, Stripe, Apple, Atlassian, Facebook) won't go through, when you need to see the SPF record in full, or when you want to know which services a domain has verified with. TXT records hold free-form text, so dozens of unrelated values can sit on one name side by side. ## A real example ### Checking TXT records when a verification token isn't found The usual story: a service gives you a token like `google-site-verification=…`, you paste it into your DNS host, press Verify, and get "record not found". Before trying again, check what the domain actually publishes. We looked at a domain with many verifications to show what a crowded but healthy TXT set looks like. In the [TXT Record Lookup](/txt-record-lookup) we typed `github.com`, kept the resolver on **Auto** and pressed **Run lookup**: ![The TXT Record Lookup for github.com from Europe / Lithuania: NOERROR, 24 records in 88 ms, starting with loom-site-verification, miro-verification, openai-domain-verification, serval, shopify-verification-code and stripe-verification tokens, followed by the full SPF record v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com … ~all](/blog/how-to-check-txt-records-result.webp) The lookup returned `NOERROR` with **24 TXT records** in 88 ms. Among them: | Kind | Examples from the run | | --- | --- | | Domain verification | `google-site-verification=` (twice), `MS=` (three), `apple-domain-verification=`, `stripe-verification=`, `atlassian-domain-verification=`, `facebook-domain-verification=` | | Email policy | one `v=spf1 … ~all` record | | Other tokens | `docusign=`, `TAILSCALE-…`, `00Dd0000000hHE0=…` | Three things to take from it. **Two Google tokens coexist**: each service looks for its own value among all TXT records, so adding a new token never requires deleting old ones. **There is exactly one SPF record**, which is the rule (two `v=spf1` records make SPF fail). And the SPF record is long enough that GitHub publishes it as two strings; the tool shows them joined into one value, the same way SPF checkers read it. **The answer:** every token GitHub has added is live and readable from a public resolver. For your own domain, if your token appears in this list, the record is published; wait a few minutes and verify again. If it doesn't, work through the gotchas below. ## How to read the results | What you see | What it means | | --- | --- | | **Resolve time** | How long the query took (green under 50 ms, amber under 200 ms, red above). | | **NOERROR** (green) | The resolver answered. Amber NXDOMAIN can mean the name doesn't exist *or* that it has no TXT records; check the spelling of the name first. | | **24 records** | How many separate TXT records the name has. | | **Value** | The text of each record. Records made of several strings are shown joined, without the quotes DNS uses on the wire. | | **Order** | Whatever the resolver returned. TXT records have no priority; order means nothing. | | **Location** | Signed out, the query runs from the WatchFor location nearest you. | The tool shows values without TTLs; `dig` shows them. ## More ways to use it - **Before a mail migration.** Read the current SPF record in full so you know which `include:` entries to keep. Then check it properly with the [SPF guide](/blog/how-to-check-an-spf-record). - **Cleaning up old tokens.** Verification tokens for tools you no longer use are harmless but clutter the zone, and they disclose which vendors you use. The lookup gives you the list to review. - **Checking a vendor.** A domain's TXT records show which services it has verified with, a quick sanity check during a security review. - **After moving DNS hosts.** TXT records are the ones most often forgotten in a zone export. Compare the old and new provider with Custom IP in the [DNS Lookup](/dns-checker). ## Tips and gotchas - **Wrong name is the top cause.** Many DNS editors add your domain to the host field automatically. Typing `example.com` there creates `example.com.example.com`. Use `@` (or leave it blank) for the apex, and only the label for subdomains. - **Don't paste the quotes.** If the service shows the value in quotes, the quotes are DNS notation. Pasted literally, they become part of the text and the token no longer matches. - **Long values are split into 255-character strings.** That's DNS, not corruption (RFC 1035). SPF joins them with no space (RFC 7208), so split at any character, but never add a space at the joint. - **One SPF record per name.** Merge new senders into the existing `v=spf1` record instead of adding a second. - **"Not found" right after adding it.** If the service checked before the record existed, its resolver may cache the "no such record" answer for the zone's negative TTL; the [SOA guide](/blog/how-to-check-a-soa-record) shows where to read it. - **Check the exact name.** Many tokens live on an underscore name such as `_github-challenge-.example.com` or `_dmarc.example.com`; type the full name. For DMARC and DKIM the dedicated [DMARC](/dmarc-record-checker) and [DKIM](/dkim-record-checker) checkers also parse the record. ## Check it from the command line too ```bash dig +short TXT github.com | grep -E "google-site|spf1" ``` ```text "v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2" "27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all" "google-site-verification=82Le34Flgtd15ojYhHlGF_6g72muSjamlMVThBOJpks" "google-site-verification=UTM-3akMgubp6tQtgEuAkYNYLyYAvpTnnSrDMWoDR3o" ``` `dig` shows the raw strings: the SPF record breaks in the middle of an address, `ip4:62.253.2" "27.114`. Joined without a space it reads `ip4:62.253.227.114`, which is exactly what the tool displayed. To see the TTL at the source, ask an authoritative server: ```bash dig +noall +answer TXT github.com @dns1.p08.nsone.net | grep spf1 | cut -c1-60 ``` ```text github.com. 300 IN TXT "v=spf1 ip4:192.30.252.0/22 include: ``` 300 seconds: a fixed or added TXT record reaches every resolver within five minutes. Underscore names work the same way: ```bash dig +short TXT _github-challenge-github.github.com ``` ```text "97e913252a" ``` ## Keep watching it Some TXT records must stay in place: SPF breaks mail when it's removed, and some services re-check their verification token and drop access when it disappears. A [DNS monitor](/dns-monitoring) on the **TXT** record type re-resolves the name on a schedule, and the **Expected DNS Records** rule with the *contains* match mode (handy for long records) opens an incident when the value you rely on goes missing. ## FAQ **How long does it take for a TXT record to show up?** A new record is visible at your DNS host immediately and at resolvers on their next lookup. If a service already looked and got "not found", it can take up to the zone's negative-caching TTL, often minutes to an hour, before it sees the record. **Can I have multiple TXT records on the same domain?** Yes, as many as you need: verification tokens, SPF and others all coexist on one name. The only rule is a single SPF (`v=spf1`) record per name. **Why does my TXT record show up split or with quotes?** DNS stores TXT data as strings of up to 255 characters, shown in quotes by tools like dig. A long value is split into several strings that consumers join back together. [DNS record types explained](/blog/dns-record-types-explained) covers TXT alongside the other types. --- Canonical page: https://watchfor.io/blog/how-to-check-txt-records · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt