Anyone can open a browser and query a public website. That is the foundation of the web. But that same openness creates a problem for monitoring tools: if anyone can query, anyone can register a hostname they do not control and start receiving alerts about it. Alerts about infrastructure are sensitive information — they show when a service goes down, when a certificate expires, when a configuration changes — and delivering that signal to someone who does not own the domain would be a security failure, not a feature.
That is why serious monitoring tools require proof of ownership before they start observing a hostname. And that is why the most common way to prove that ownership 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.
The problem is not theoretical. Tools that do not require proof of ownership become a reconnaissance vector: an attacker registers domains belonging to a target, receives alerts about infrastructure changes, and maps the environment without having to break into anything.
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. It requires accessing the DNS dashboard, creating the record, waiting for propagation (usually seconds to a few minutes), and confirming. It is one more step than simply typing the domain and clicking "monitor".
It is also what prevents someone else from receiving information about your domain. Without that step, anyone could register any hostname and see alerts about it.
From the tool operator's perspective, ownership verification is a security decision about who can receive a signal. Monitoring generates information about failures, configurations, and infrastructure. That information needs to reach only those who have authority to act on it.
Next step
If you are evaluating monitoring tools — or building one — it is worth asking: how does this tool decide who can receive alerts about 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 information.
cymesh uses DNS TXT records for ownership verification. The flow is what was described above: register the hostname, publish the token in DNS, confirm. It is one extra step in the signup process, and it is what ensures that alerts about a domain reach only those who control that domain.