Evidence & coverage
Collection methodology
How Domain Signals keeps raw DNS observations, distinguishes baselines from changes and reports the coverage of a bounded watchlist.
Domain Signals records changes in domain infrastructure. Every reported change is tied to observations; the first observation for a domain is a baseline.
Two kinds of coverage
Approved ICANN CZDS zone files provide domain-delegation snapshots. A diff identifies names added to or removed from a zone. A zone entry is not a verified business, and its first appearance is not a domain-registration timestamp.
Deeper DNS checks run on a selected, bounded watchlist. This includes selected existing domains and domains added through later zone changes. The public counts describe this watchlist, not all domains in .com or the whole internet. Watchlist limits and scheduled checks affect coverage and the time between observations. Domains awaiting a check form a queue; if that queue exceeds a run’s budget, the actual observation interval can be longer than the intended daily cadence. Existing watchlist domains remain eligible for repeat checks after they disappear from a zone.
Raw evidence and retained history
Checks preserve MX, TXT, NS, A, AAAA, CNAME, www CNAME and DMARC outcomes. Each query retains its status, values, timestamps and errors. Normalized values make comparisons stable, while the stored observations preserve the evidence needed to inspect changes.
The private dashboard links a domain’s events to its observation history. Source zone files remain on the collection server; public pages contain aggregate statistics.
How events are classified
| Event | Meaning |
|---|---|
| Baseline | First confirmed observation of a feature for that domain. |
| New appearance | A feature appears after a successful observation that did not contain it. |
| Confirmed disappearance | The relevant query succeeds, and the previously observed feature is absent. |
| Return | A feature seen earlier reappears after a confirmed absence. |
| Record change | Comparable record values differ between successful observations. |
Temporary resolver failures are retained as errors. They do not clear the last confirmed state or create disappearance events. A successful no-data or NXDOMAIN response is different from a timeout and can support a confirmed absence. Disappearance requires the configured number of successful absence confirmations on separate observation days; repeated manual checks on one day do not supply extra confirmations.
The collection timestamps bound what was visible between checks. They do not establish the exact time a company bought, installed or started using a product.
Evidence types have different meanings
MX indicates visible mail routing. SPF indicates sender authorization. A verification TXT marker indicates that the marker exists. CNAME and NS indicate routing or delegation. DMARC indicates a published policy. No single marker proves a paid subscription, a working mailbox or current use of every product feature.
Pages are published only for technologies with recorded observations. New appearances and returns exclude baselines. Event counts cover retained history and can include repeated events for a single domain. Active counts use the latest confirmed feature state and may remain unchanged while queries fail.
Publication and source use
The public site publishes aggregate research, without domain-level lead lists or contact information. Applicable registry agreements, CZDS access conditions and accepted source terms govern collection and downstream use. Access approval does not itself authorize every downstream use.