Phishing & Scam Domain Investigation Checklist: Step‑by‑Step Workflow for Analysts and IT Admins

Overview

A suspicious domain is not proven safe merely because it uses HTTPS, has a professional design, or appears in a search result. Conversely, a recently registered domain is not automatically malicious. A reliable assessment combines the message context, the exact URL, domain and DNS records, hosting clues, certificate history, threat-intelligence results, and any observed user impact.

Start with a clear objective: decide whether to block, report, monitor, or escalate the domain. Do not begin by attempting to log in or submit test information. If the site may be active, perform observation from an approved isolated analysis environment, sandbox, or remote browser. Never use real credentials, payment details, personal data, or production tokens during testing.

For a deeper look at impersonation indicators, pair this workflow with How to Investigate a Suspicious Domain and Spot an Impersonation Website. If the suspicious link arrived by email or text, preserve the original message and review How to Investigate a Suspicious Email, Text, or Website Before You Click.

Minimum evidence to collect

• The complete URL, including the scheme, hostname, port, path, query string, and fragment.
• The date and time observed, with the relevant time zone.
• The original email, message, or alert, including headers where available.
• A screenshot of the message and the landing page, captured without entering information.
• Redirect destinations, downloaded files, browser warnings, and visible brand or login prompts.
• Any internal detections, affected users, DNS queries, proxy events, or endpoint alerts.

Record observations factually. “The page requested a password” is more useful than “the site looked dangerous.” Keep the original evidence unchanged and work from copies when possible.

Checklist by scenario

Scenario 1: A suspicious email or text contains a link

1. Do not click the link in the original message. Copy the displayed link only if your process permits it, or obtain the URL from message headers, a secure analysis tool, or a screenshot. Watch for shortened URLs, encoded characters, look-alike letters, unexpected subdomains, and misleading text such as a trusted brand name in the path.
2. Inspect the sending context. Compare the sender address, reply-to address, authentication results, display name, message timing, language, and requested action. A legitimate-looking sender name does not establish that the message came from the claimed organization.
3. Compare the domain with the claimed service. Separate the registrable domain from subdomains and paths. For example, in login.example.test.attacker.example, the relevant registrable domain may be attacker.example, not the brand-like text at the beginning.
4. Check for independent confirmation. Navigate to the organization through a known bookmark or manually entered address, or contact it through a trusted channel. Do not use phone numbers, support links, or contact details supplied by the suspicious message.
5. Report and contain. Submit the message through your organization’s reporting process, add the indicators to the appropriate monitoring or blocking workflow, and warn potentially affected users without forwarding the live link unnecessarily.

Scenario 2: The domain hosts a login or payment page

1. Capture the URL and page appearance without entering credentials or payment data.
2. Check whether the page uses a brand, login flow, logo, or support language that is inconsistent with the organization’s normal service.
3. Review the certificate subject, issuer, validity period, and hostname match. Treat a valid certificate as transport protection, not proof that the operator is trustworthy.
4. Check DNS records, hosting details, domain registration data, passive DNS history, and certificate transparency records where available. Privacy-protected registration, shared hosting, or a recent certificate can be useful context, but none is conclusive alone.
5. Search approved threat-intelligence sources such as VirusTotal, MISP, internal intelligence platforms, or abuse feeds. Note the source, timestamp, verdict, and exact indicator; do not treat an automated score as a final determination.

Scenario 3: A user already clicked or submitted information

1. Ask the user to stop interacting with the page and preserve the message, URL, screenshots, and approximate timeline.
2. Determine what was exposed: credentials, multifactor codes, payment details, identity information, internal documents, or only a page view.
3. For credentials, reset the affected password through the legitimate service, revoke active sessions where supported, and check for reuse on other accounts. Escalate immediately if privileged or business-critical accounts were involved.
4. For payment or identity information, follow the organization’s established fraud, privacy, and incident-response procedures. Avoid promising that a password reset alone resolves the exposure.
5. Review endpoint, identity-provider, email, proxy, and DNS logs for follow-on activity. Block the domain and related indicators only after checking for business dependencies and documenting the change.

Use the evidence and escalation template in How to Report a Phishing Email, Text, or Website when handing the case to security, a provider, or the affected organization.

Scenario 4: An internal alert identifies a suspicious domain

1. Validate the alert’s indicator type: full URL, hostname, IP address, email sender, hash, or certificate fingerprint.
2. Identify affected assets and users, including whether the domain was resolved, visited, blocked, or merely observed in an intelligence feed.
3. Correlate the indicator with endpoint, network, identity, and email telemetry. Look for repeated DNS lookups, redirects, downloads, authentication attempts, or unusual sign-ins.
4. Assign a confidence level and business impact. A single low-context feed hit should be handled differently from confirmed credential submission on a privileged account.
5. Document the decision, owner, timestamps, and next review point. This makes the investigation auditable and prevents duplicate work.

What to double-check

Use the exact hostname. A domain’s reputation may not apply to every subdomain, URL path, or redirect destination. Preserve the complete chain where possible.

Interpret WHOIS and DNS carefully. Registration dates, nameservers, IP addresses, and hosting providers provide context, not a verdict. Shared infrastructure can host unrelated legitimate and malicious sites, and registration details may be redacted.

Check certificate transparency without overreading it. Certificate records can reveal related hostnames or infrastructure changes. They do not prove who operates a site or whether its content is safe.

Separate reputation from evidence. A clean result in a public scanner may mean only that the indicator has not been reported or detected. A negative result is not clearance. Conversely, conflicting detections should be recorded and investigated rather than averaged into false certainty.

Protect sensitive data during enrichment. Public analysis services may retain submitted URLs, files, or metadata according to their own terms. Do not submit confidential links, customer data, internal hostnames, access tokens, or proprietary files without authorization. Use an approved private instance or internal workflow when required.

Preserve chain of custody. Store the original message, raw headers, screenshots, exported results, and analyst notes with timestamps. Hashing collected files can help demonstrate that evidence was not changed, but a hash does not establish that a file is safe. Treat decoder and checker tools, including JWT or hash utilities, as analysis aids rather than trust signals; do not paste live secrets into unapproved tools.

Common mistakes

• Opening the site from a production workstation. Use a controlled environment and follow your organization’s safe-browsing procedure.
• Logging in to “test” the page. This can expose credentials and may alert an operator that the target is being examined.
• Trusting HTTPS, a padlock, or polished design. These indicate connection characteristics, not business legitimacy.
• Blocking only one URL. Attackers may use several paths, subdomains, redirectors, or related domains. Document the full indicator set and avoid overly broad blocks that disrupt legitimate services.
• Relying on one reputation provider. Compare independent evidence, record timestamps, and explain uncertainty.
• Forwarding the live message to coworkers. Share sanitized screenshots or an approved report instead, especially when links can be clicked accidentally.
• Failing to ask what happened after the click. The response depends on whether the user viewed a page, downloaded a file, submitted a password, approved a multifactor prompt, or used a payment method.
• Closing the case without lessons learned. Update mail rules, browser protections, awareness guidance, playbooks, and detection logic when the investigation reveals a gap.

For adjacent operational processes, see the Security Alert Triage checklist and the incident response checklist for teams.

When to revisit

Revisit this checklist before seasonal planning cycles, tabletop exercises, and phishing simulations, then update it when your browser isolation, email security, DNS, endpoint, identity, or threat-intelligence workflows change. Review the approved tools and reporting routes at least quarterly, and immediately after a major phishing campaign, provider change, industrywide takedown, or internal incident.

Keep a short change log: date reviewed, tools or contacts changed, new indicators or tactics observed, and the person responsible for the next review. Before closing any future case, run the practical sequence: preserve the original evidence, extract the exact indicators, assess the message and domain independently, enrich without exposing sensitive data, contain proportionately, check for user impact, report through trusted channels, and record the final reasoning. That repeatable process is more dependable than trying to decide from a domain’s appearance alone.