A Suspicious Domain Investigation Checklist

How to systematically investigate a domain you don't trust — from DNS records to certificate details to IP reputation.

When to investigate

Domain investigation is a first-responder skill for several scenarios: a phishing URL surfaces in your email gateway logs, a user reports clicking a suspicious link, an unfamiliar domain appears in firewall or proxy logs, or a security alert flags a newly registered domain communicating with internal infrastructure.

The goal of a rapid investigation is not a definitive verdict — it is to gather enough signals in 5 minutes to make a triage decision: block immediately, escalate for deeper analysis, or clear as benign. The checklist below produces those signals systematically. Work top-to-bottom; earlier steps inform interpretation of later ones.

Step 1: DNS reconnaissance

Start by establishing basic facts about who controls the domain and where it points.

NS records reveal the DNS provider. Legitimate enterprises typically use their cloud provider's DNS (Route 53, Cloud DNS, Azure DNS) or a managed DNS service. Consumer-grade providers (Namecheap free DNS, Freenom) are common with malicious domains. Bulletproof DNS providers — services that advertise abuse resistance and ignore takedown requests — are a hard signal.

A/AAAA records show where the domain resolves. Note the IP and ASN. Cross-reference with WHOIS for the domain registration date. Domains registered within the past 30 days hosting what purports to be a legitimate business are suspicious by default — established organizations do not appear overnight.

MX records show where email is destined. A domain with no MX records but a functioning website that is soliciting credentials is suspicious. A domain with MX pointing to a free email provider rather than a corporate mail server is also unusual for a claimed business.

WHOIS provides registration date, registrar, and registrant information. Privacy protection masking the registrant is common for both legitimate and malicious domains, so its presence alone is not a signal. However, the registrar and registration date are rarely masked: recently registered via a known abuse-tolerant registrar is a meaningful pattern.

Step 2: Certificate inspection

The TLS certificate is a rich source of signals that are often overlooked in domain investigation. Run a full TLS inspection before loading the domain in a browser.

Issuer — Let's Encrypt is the dominant issuer for both legitimate sites and malicious infrastructure, because it is free and automated. A LE certificate is neutral evidence; the rest of the certificate matters more. A paid commercial CA (DigiCert, Sectigo) with a short-lived cert is unusual — they are expensive and typically used for longer terms.

First issuance date via CT logs — search crt.sh for the domain. The earliest logged certificate reveals when the domain first had HTTPS. A domain claiming to be a long-established company with a first certificate from last week is contradictory evidence. CT log history also shows whether the domain has changed CAs, changed SANs, or had periods of no HTTPS.

Subject Alternative Names (SANs) — the SAN list shows every domain covered by the certificate. Shared certificates covering dozens of unrelated domains indicate cheap hosting on a shared platform. A wildcard covering *.example-bank-login.com covering only that domain was purpose-built. SANs that include both legitimate-looking and suspicious domain names on a single cert are a pivot point — investigate the other domains in the SAN list.

Certificate lifetime — 90-day certificates are standard with ACME automation (LE, ZeroSSL). Very short-lived certificates (under 7 days) or automated rotation with high frequency suggest programmatic abuse infrastructure. Multi-year certificates on domains registered last week are inconsistent (legacy CAs stopped issuing these, but the pattern occasionally appears).

Step 3: IP reputation

Resolve the domain and run the resulting IP through enrichment. The key classification signals:

Geographic location can also be a signal in context. A domain claiming to be a US financial services company hosted on an IP geolocated to a country not known for US financial services warrants scrutiny, though VPNs and CDNs complicate this signal.

Step 4: Email authentication signals

Even for a domain you are not receiving email from, its email authentication posture tells you about intent. Query SPF, DMARC, and MX records.

A domain with no DMARC and a permissive SPF (~all or ?all) is configured to allow spoofing. This is consistent with a domain set up specifically to send phishing while avoiding hard failures. A domain with no MX records but a valid SPF record is often a spoofing-optimized configuration — it can send mail but cannot receive it, which is unusual for anything other than automated sending or malicious use.

Conversely, a domain with v=spf1 -all and v=DMARC1; p=reject and no MX has explicitly declared "this domain sends no mail" — this is a strong configuration seen on legitimate parked or redirect-only domains. It is not a sign of malicious intent.

The absence of any email authentication records on a domain that is actively being used to send email is a red flag. It suggests either a hastily configured abuse domain or an organization with very poor security hygiene.

Patterns that indicate malicious domains

No single signal is definitive, but combinations are highly predictive. High-confidence malicious patterns:

A domain matching two or more of these patterns warrants blocking without waiting for further evidence.

What to do with findings

For immediate threats (known C2, Tor exit, Spamhaus-listed): block at the network perimeter and update threat intelligence feeds. Document the indicators of compromise (IOCs): domain, IP, certificate fingerprint, first-seen timestamp.

For suspected phishing targeting your brand: report to the registrar's abuse contact (abuse@registrar.tld), the hosting provider's abuse contact (derivable from the IP ASN's WHOIS), and relevant CERTs. Submit phishing URLs to Google Safe Browsing and Microsoft SmartScreen. For certificate misuse, report to the issuing CA.

Document your evidence before reporting. Screenshot the DNS records, certificate details, and IP enrichment output with timestamps. Takedowns can move quickly and the original evidence may disappear. A preserved record supports escalation if the initial report is ignored.

Inspect a suspicious domain's TLS certificate

Inspects TLS certificate chain, SANs, issuer, and multi-IP consistency — useful for domain investigation.

Check your site's HTTP headers with spectra

Check your domain's email authentication with beacon