Why this is the first task
Almost every record in a domain matter is either mutable within minutes or governed by a retention clock that runs whether or not anyone has asked. There is no category that simply waits.
That reverses the usual order of work. In most matters the record is gathered once the issues are framed. Here, framing the issues takes weeks that the record does not have, so collection of the public material comes first and analysis follows. The cost of collecting material that turns out to be irrelevant is a few hours. The cost of not collecting material that turns out to be central is the case's factual foundation.
It also changes who does what. Counsel decides what to demand, from whom, and under what authority. What an expert contributes at this stage is narrower and more urgent: capture what is publicly available today, in a form that can be verified later, and produce a written list of custodians and their retention windows so the decisions about process can be made against real deadlines rather than assumed ones.
Nothing here is legal advice. Every step that involves serving anything on anyone is counsel's.
Rank by volatility
Collection order follows how fast each category can disappear.
First, the live state. DNS answers, the website as served, redirect behavior, registration data as currently published, certificate coverage as currently issued. All of this can change in minutes, and a redirect in particular is configuration that leaves no residue on the domain once removed.
Second, third-party historical sources. Web archive captures and the full capture index for each URL, certificate log entries, passive DNS exports, commercial registration-data history, marketplace listings. These are more durable but not permanent: captures can become unavailable after a later change to a site's robots file, and log operators retire logs.
Third, the material behind process. Provider logs and account records, on windows the provider sets. These cannot be captured directly, so what preservation means here is identification and a written request.
Fourth, the durable layer. Registry records, which change slowly and are least likely to be lost.
Working in that order means the irreversible losses are addressed while the recoverable ones wait.
Capture the raw response
The single most common defect in domain evidence is a screenshot of a lookup tool standing in for the record itself.
What to preserve instead: the structured registration response as returned, or legacy text where that is what the endpoint gives; DNS query output including which resolver answered; the complete HTTP transcript with request and response headers, not only the rendered page; page source; and the certificate itself rather than an aggregator's rendering of it.
Published guidance on acquiring online content is specific about the surrounding metadata: capture the full URL including protocol, host, subdomains, path and session information, together with the dates, timestamps and local time zone of access, and preserve content in its native form and file formats (SWGDE 21-F-001). The same guidance gives preference to video capture of the screen where a sequence is involved, with stills used alongside — which is the right answer for a redirect, because a still frame cannot show a chain.
Renderings still have a place as exhibits. They are just not the record.
Hash at capture, log as you go
Two habits carry most of the weight, and both fail if they are performed later.
Hash at the moment of capture, under more than one algorithm, and record the values in a manifest that travels with the set. A digest computed at report time documents the state of a file after it has been renamed, re-saved, converted or emailed — which is a different claim from the one anyone wants to make.
Keep the collection log contemporaneously, as an append-only record rather than a document that is silently revised. It should record the date, time and time zone, the operator, the source, the tool and its version, the action taken and the result. Contemporaneity is a stated requirement in the published guidance, not a preference; a log written a month afterwards is a different kind of document and will be treated as one.
Then seal the capture set and work only from copies, verifying the integrity of both before any re-examination. And record the exceptions: the capture that failed, the page that would not reproduce from a second location, the item sought and not obtained, with the reason.
The clocks already running
These are published floors, and they run silently.
- Fifteen months after a registrar's sponsorship of a registration ends — the minimum retention of the data elements needed for transfer disputes, under ICANN's Registration Data Policy effective 21 August 2025 (Registration Data Policy).
- Two years after deletion or transfer away — the outer edge of the 2013 accreditation agreement's registration-record obligation.
- One hundred and eighty days — the short-window category covering log files, billing records and communication source and destination data.
- Twelve months — the filing window for a transfer dispute after an alleged violation of the Transfer Policy.
- Provider-set windows for hosting, DNS and authentication logs, commonly measured in weeks, and frequently shorter than the time it takes to identify the custodian and serve anything.
- Analytics retention at the platform level, where event-level data on standard properties is held for a selectable period measured in months rather than years.
Retention floors are also waivable, and registrar-specific relief has been granted, so no single figure describes every custodian.
What a proceeding does and does not freeze
Filing does not preserve the record, and assuming otherwise is a recurring and expensive error.
In a UDRP the registrar applies a lock after the provider's verification request, within two business days. The lock is defined as measures preventing, at a minimum, modification of the registrant and registrar information by the respondent — and it expressly does not affect resolution of the domain name or its renewal. Website content, DNS records, mail configuration and redirects all remain changeable throughout the proceeding, and a party who has just received notice is the party most likely to change them.
In a URS the registry locks the domain within twenty-four hours of the notice of complaint, restricting changes rather than taking the site down; the domain keeps resolving during the case, so live-site evidence stays capturable and equally stays changeable.
US-specific: the statutory mechanism that requires a provider to preserve records pending process is framed around a request by a governmental entity, with a ninety-day period extendable once. It is not a civil-party tool, and treating it as one leaves a matter without the preservation it assumed it had.
What preservation cannot recover
Preservation changes what is still capturable. It does not reach backwards, and a report should say where the reach ends.
Configuration that was never captured. Redirect rules, DNS records and page content that changed before collection began generally exist nowhere except in a provider's change history, if that provider keeps one and for as long as it does.
Archive coverage that was never created. A page can be absent because crawlers were unaware of its existence, because it was password-protected, because a robots file blocked it, or because the owner requested exclusion; the archive makes no guarantee about the outcome of such requests, and captures that were once visible can stop being visible after a change of ownership brings a new robots file with it.
Sensor coverage that never existed. A low-traffic name may have few or no passive DNS observations for the relevant window. Absence is not evidence.
Logs that have rotated. A preservation letter sent afterwards preserves nothing, and no ICANN policy obliges a registrar to hold records because a private party asked.
Live collection also alters state: any live acquisition can create evidence, and requesting an archival capture creates a record of the request.