Start with the domain, not the page
Phishing infrastructure usually involves several layers: the domain in the link, the server that hosts the page, the mail system that delivered the lure and sometimes a second domain used only for credential collection. Before examining the page content, collect the registrable domain, its RDAP registration record, DNS answers and any certificates associated with it. This gives a stable frame of reference that does not depend on the page still being online.
Record the creation date, registrar, nameservers and current status from RDAP. A domain registered a few days before the campaign started, using a privacy service and pointed at nameservers unrelated to any legitimate brand, is a common but not universal pattern. Treat each of these as one data point rather than conclusive proof.
Hosting and network context
Resolve the hostname to its A/AAAA records and look up the network holder for each IP through the relevant Regional Internet Registry via RDAP. Phishing kits are frequently hosted on compromised legitimate servers, cheap bulk hosting, or behind a content delivery network that hides the origin. Identifying the actual network holder tells you which abuse desk can realistically take the page down.
Where the site sits behind a CDN or reverse proxy, the visible IP belongs to that provider, not the operator. Note this explicitly in the report rather than naming the CDN as the host responsible for the content.
Certificates and related hostnames
Certificate transparency logs, searchable through services such as crt.sh, record every publicly trusted certificate issued for a name. Searching the apex domain and common prefixes can surface related hostnames such as login, secure, mail or pay subdomains that were prepared for the same campaign but have not yet been linked by other means. The log also shows the earliest issuance date, which can corroborate or contradict the registration timeline.
Multiple unrelated-looking domains sharing the same certificate issuance pattern, the same registrar and the same day of registration is a useful lead for identifying a wider campaign, but shared infrastructure alone does not establish common ownership.
Email delivery evidence
If the phishing lure arrived by email, the message headers and the domain's MX, SPF and DMARC configuration provide a separate line of evidence. A domain with MX records configured and a permissive or absent SPF/DMARC policy is ready to send and receive mail, which is relevant when the campaign includes reply-based social engineering rather than just a link.
Keep the original email file intact. Authentication results should be read from your own trusted receiving infrastructure, not recomputed after the fact, because DNS records can change after the incident.
Assembling the report
A useful phishing infrastructure report separates what was observed (DNS answers, RDAP fields, certificate entries, email headers) from what is inferred (likely campaign relationships, likely intent). Each observation should carry its source and a UTC timestamp. Seal the compiled evidence with a cryptographic hash so it can later be shown to be unchanged, then submit precise, evidence-backed abuse reports to the registrar, host and any CDN involved.
- Registrable domain, RDAP creation date, registrar and status.
- DNS: A/AAAA, NS, MX, TXT, SOA with collection timestamps.
- IP network holder for each resolved address, noting CDN use.
- Certificate transparency search for the domain and common subdomains.
- SPF/DMARC posture and, if applicable, preserved original email.
- Sealed, hashed report before submitting abuse notices.