Decide the scope before collecting
A domain forensic report should state up front which domain, URL or email it concerns, the date and time of the investigation, and the question it is trying to answer, for example whether a given domain's registration and infrastructure are consistent with the claims made in an email it sent. A clear scope keeps the report from drifting into speculation about matters it cannot actually support with evidence.
What to collect and how to record it
Collect RDAP registration data (creation, update and expiration events, registrar, status, and any visible registrant fields), DNS records (A, AAAA, NS, MX, TXT, SOA), SPF and DMARC evaluation, RDAP network data for any resolved IP addresses, and a certificate transparency search for the domain and relevant subdomains. For each item, record the exact query made, the source queried, the full raw response and a UTC timestamp, not just a summarised conclusion.
Where a check could not be completed, for example a registry returning no data or a resolver timing out, record that explicitly as 'unavailable' or 'not returned', rather than leaving a blank that could later be misread as a negative finding.
Writing findings without issuing a verdict
Present each finding as an observation with its source: 'the domain was created on [date] according to RDAP data retrieved at [time]' rather than 'the domain is fraudulent'. Group related observations and note where they are consistent or inconsistent with each other or with an independently confirmed baseline, but leave the ultimate judgment of fraud, compromise or legitimacy to the reader and the wider body of evidence, since DNS and registration data alone cannot establish intent.
Sealing and delivering the report
Once the report is compiled, calculate a cryptographic hash, typically SHA-256, over the final document or evidence bundle and record that hash separately from the document itself. This allows anyone receiving the report later to confirm it has not been altered since it was produced, which matters for abuse complaints, insurance claims, regulatory submissions or legal proceedings where the integrity of the evidence may be challenged. Retain the raw underlying data alongside the report in case a reviewer needs to verify a specific field.
- State scope, subject and the specific question being investigated.
- Record raw responses, sources and UTC timestamps for every data point.
- Mark unavailable data explicitly instead of leaving it blank.
- Phrase findings as sourced observations, not verdicts.
- Hash the final report and retain the underlying raw data.