Anyone can open a browser and query a public website. That is the foundation of the web — and it also holds for the signals an external monitoring tool watches: the certificate the server presents, whether the site responds, which headers it sends, when the domain expires. That data is open to any curl or openssl. But there is one question no public GET answers: who controls this domain?
That is where ownership proof comes in. It does not hide what is already public; it asserts, through a verifiable action, that whoever registered the hostname has authority over it. And the most common way to make that proof is a DNS TXT record.
Why a public GET is not enough
A public GET proves the site responds. It does not prove the domain is yours.
Think of an extreme example: someone could register google.com in a monitoring tool and start receiving notifications about Google's availability, SSL certificate, and security headers. The tool would run its external checks normally — the site is public, after all — and deliver information about a third party's infrastructure to the person who registered it.
For public signals, that exposes nothing new — the same data comes out of any terminal. The problem appears when the tool offers something that is not public, or when someone needs to trust that the person who registered the hostname answers for it: a report delivered to a client, an audit, a feature that acts on the infrastructure.
In those cases, the solution is to require an action that only someone who controls the domain's DNS can perform.
What a TXT record is and why it works
DNS (Domain Name System) is the system that translates domain names into IP addresses and other operational data. A TXT record is a free-text field associated with a name — it can sit at the domain root (example.com) or at a subdomain (_cymesh.example.com).
Creating or modifying a TXT record requires access to the domain's DNS dashboard or the DNS provider's API. It is not something you do by accident, and it is not something you can do without control of the domain. That barrier is exactly what turns the TXT record into proof of ownership.
The typical flow is:
- The user registers the hostname in the monitoring tool.
- The tool generates a random value (a token) and asks the user to create a TXT record with that value at a specific location — for example,
_cymesh.example.com. - The tool queries DNS publicly, reads the TXT record, and confirms the value matches.
- Ownership is verified. Monitoring begins.
Someone who does not control DNS cannot publish the TXT record. Without the TXT record, the tool does not start observing. It is that simple.
Why TXT and not another record type
There are other DNS record types — A, AAAA, CNAME, MX, and others. Each one has a specific purpose. TXT is chosen for ownership verification for a few practical reasons:
- It does not change how the domain works. A TXT record does not change where the site points, does not alter email routes, does not affect name resolution. It sits there as a machine-readable note, with no side effects.
- It supports free-form text. The value can be a long, unpredictable token, suitable for cryptographic verification.
- It is the industry standard. ACME (the protocol used by Let's Encrypt) uses the DNS-01 challenge, which is essentially the same idea: publish a TXT record to prove control. Anyone who has validated a domain with Let's Encrypt has already done this kind of verification.
Alternatives like modifying an A or CNAME record would work as proof, but they would have real side effects on traffic. TXT is the option that proves without interfering.
What this means in practice
From the tool user's perspective, ownership verification is an extra step: open the DNS dashboard, create the record, wait for propagation (usually seconds to a few minutes), and confirm. That is why it makes sense for it not to be a barrier to what is public — and to be required for what is not.
It is also what separates "I am watching this domain" from "this domain is mine". Anyone can make the first claim; the second needs proof.
From the tool operator's perspective, ownership proof is a decision about what each feature requires. Following a public certificate requires little; asserting authority over the infrastructure requires more.
Next step
If you are evaluating monitoring tools — or building one — it is worth asking: how does this tool decide who has authority over a domain? The answer might be "TXT record", "HTTP file at a known path" (like ACME's HTTP-01 challenge), or "email verification via WHOIS". Each has trade-offs, but they all share the same principle: prove control before delivering what is not public.
At cymesh, monitoring of public signals — certificate, availability, security headers and domain expiry — starts as soon as you register the hostname. TXT record proof is optional: the flow is the one described above (publish the token in DNS and confirm), and it gives the hostname the verified ownership badge, rechecked every 30 days.