> Source: https://upvera.tech/guides/dns-txt-verification/ > A DNS TXT record proves you control a domain because only someone with access to its DNS settings can publish it. Add the exact value a service gives you as a TXT record at the name it asks for, wait for the record's TTL to pass, then check it with a lookup like the one on this page. The tool queries a public DNS resolver from your browser and labels the verification records it recognizes. [Guides](/guides/)Tools Tool · · For founders · Proof Engine # Check a domain's TXT records and verify you own it Short answer A DNS TXT record proves you control a domain because only someone with access to its DNS settings can publish it. Add the exact value a service gives you as a TXT record at the name it asks for, wait for the record's TTL to pass, then check it with a lookup like the one on this page. The tool queries a public DNS resolver from your browser and labels the verification records it recognizes. Domain Queries go straight from your browser to a public DNS resolver. Upvera does not see them. ## Three ways to prove a source is yours Services that need to know a domain or a repository is yours usually offer three methods. They prove slightly different things. | Method | What you do | What it proves | Good for | | --- | --- | --- | --- | | DNS TXT record | Publish a value in the domain's DNS | You control DNS for the name, often including its subdomains | Domains you manage fully | | File on the site | Serve a file at a fixed path, usually under `/.well-known/` | You control the web server for that exact name | Sites where DNS is managed by someone else | | App or OAuth install | Install the service's app on a code host or platform | You administer the account that owns the repository or listing | Repositories and store listings | A TXT record is the strongest of the three for a whole domain, because DNS sits above every server that answers for it. ## Adding a TXT record, step by step 1. Copy the value exactly as the service shows it, including any prefix such as `name-verification=`. 2. In your DNS provider, add a record of type **TXT**. For the name, use what the service asks for: `@` (the domain itself) or a label such as `_service`. 3. Leave the TTL at the provider's default unless you are in a hurry. A lower TTL makes later changes visible sooner. 4. Save, then check the record with the tool above before you press "verify" on the service. If the tool doesn't see it, the service probably won't either. 5. Keep the record after verification. Many services check again later, and ownership lapses if the record disappears. ## Why verification fails - **The record is at the wrong name.** `_service.example.com` and `example.com` are different places. Some dashboards append the domain for you, so typing `_service.example.com` produces `_service.example.com.example.com`. - **Extra quotes or spaces.** Some providers add quotes themselves. A value saved as `""value""` won't match. - **The old answer is still cached.** Resolvers keep an answer for its TTL. If you edited an existing record, wait at least that long. - **A long value was split.** TXT strings are limited to 255 characters each. Long values are stored as several strings that should be joined without spaces; the tool joins them for you. - **A CNAME at the same name.** A name with a CNAME record can't also hold a TXT record. Use a different label if the service allows it. - **Proxied or managed DNS.** If a platform hosts your DNS, the record has to be added there, not at the registrar. ## Questions ### How long does a TXT record take to work? On most providers a new record is visible within minutes. A changed record can take as long as its previous TTL, sometimes hours. Check from more than one resolver if results differ. ### Can I have several TXT records on one domain? Yes. Domains commonly hold records for email (SPF), search consoles and several services at once. Each service looks only for its own value. ### Is a verification token secret? No. Anyone can read TXT records, as this tool shows. The token only proves that whoever controls DNS chose to publish it. ### Does verifying the apex cover subdomains? It depends on the service. A TXT record on the apex usually proves control of the whole domain, while a file proves only the exact host that served it. ## How Upvera does it On Upvera, a source counts toward a startup's record only after its owner is verified. For a domain that means a TXT record with the value `upvera-verification=` at `_upvera.` or at the domain itself, which covers the domain and its subdomains, or a file at `https:///.well-known/upvera-verification.txt`, which covers only that host. Repositories are verified with a GitHub App. A verified domain then anchors the startup's other sources, such as the developer site of its App Store listing. Domain verification runs on Upvera's servers today and reaches the app with its next release. The [Proof Engine report](/proof/) describes the rest. ## Sources - [RFC 1035, domain names and TXT records](https://www.rfc-editor.org/rfc/rfc1035.html) - [RFC 8615, well-known URIs](https://www.rfc-editor.org/rfc/rfc8615.html) - [Cloudflare DNS over HTTPS, JSON format](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/make-api-requests/dns-json/) - [Google Public DNS JSON API](https://developers.google.com/speed/public-dns/docs/doh/json) ## Related [Guide**How to show startup traction without revealing your numbers**Revenue bands, dated release chains, source age and ownership: proof of progress that keeps your exact figures private.FoundersRead](/guides/show-traction-without-numbers/)[Guide**How to check a startup's claims before you believe them**A checklist with public tools for domain age, site history, store listings, code, packages, team and revenue, plus red flags.Anyone checkingRead](/guides/check-startup-claims/)[UTR-26-01**Proof Engine**Work read at the source. Never typed in.System reportRead](/proof/)