Evidence & coverage
Collection methodology
How Domain Signals preserves DNS history, distinguishes baselines from changes and reports progress through approved .com and .org domains.
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 .com and .org 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 use a continuous queue covering every domain in the approved .com and .org snapshots, with saved checkpoints and no total domain cap. Public counts include only observations collected so far; they do not represent a completed DNS census. New domains and established rechecks share capacity. DNS response times, retries and storage affect progress, and the actual observation interval can exceed the intended daily cadence. Previously observed domains remain eligible for repeat checks after they disappear from a zone. Storage pauses preserve committed history and queue progress.
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.