How to Monitor Websites for Domain Fraud

Monitor both new domains that resemble your organization’s domains and changes to domains and subdomains you already own. Then validate each alert against legitimate campaigns, subsidiaries, and vendors before treating it as fraud. A similar name is a reason to investigate, not proof of malicious intent.

Domain monitoring can help find websites used for phishing, malware delivery, or information theft. It does not by itself prevent email spoofing, and monitoring alone cannot guarantee that every fraudulent site will be found or removed. CISA describes domain-name monitoring as a way to discover creation of or changes to an organization’s domains, including new subdomains and domains that mimic them. CISA’s TIC 3.0 guidance recommends monitoring for those changes because they may support phishing or other attacks.

1. Define what you need to monitor

“Domain fraud” can refer to several related problems. Give each one an explicit place in your monitoring plan so that an alert reaches the right team.

Risk	What happens	What to monitor
Lookalike or typosquatted domain	Someone registers a name resembling your domain, possibly to imitate your site or catch mistyped visits.	New registrations and observed websites that resemble your brands and domains.
Unauthorized domain change or hijacking	Someone changes a registration or gains control of a domain without the registrant’s permission.	Registrar account activity, nameserver and registration changes, renewal status, and DNS changes.
Subdomain takeover	A DNS record points to a resource that no longer exists or has been deprovisioned; another party may be able to claim that resource.	Subdomains, their DNS targets, and whether those targets still resolve to resources your organization controls.
Email spoofing	An attacker forges messages that appear to come from your domain.	Email authentication and reporting, including SPF, DKIM, and DMARC.

These risks overlap, but one control does not solve all of them. Website and domain monitoring looks for suspicious names, observations, and changes. DMARC is an email-authentication control built on SPF and DKIM, with reporting that can help domain owners monitor protection against spoofed or modified email. CISA notes that protection for mail you receive depends on the sending domain also deploying DMARC. See CISA’s #StopRansomware Guide for its explanation of DMARC, SPF, and DKIM.

2. Establish an accurate inventory

Monitoring is only as useful as the inventory used to interpret alerts. Record the domains you own, the subdomains you operate, and the people or services responsible for them.

List registered domains, including country-specific domains, product domains, campaign domains, and former domains that remain registered.
Collect known subdomains and their intended purpose, owner, DNS target, and hosting or cloud service. Include records managed by teams outside central IT.
Identify approved brand spellings, subsidiaries, acquisitions, localization variants, and vendors allowed to operate domains for you.
Record registrar, DNS provider, renewal date, account owner, and emergency contact for each important domain.
Decide how long former domains will remain registered and monitored. CISA and the FBI warn that a former organizational domain allowed to lapse could be acquired and misused by a threat actor.

Keep the inventory somewhere responders can access during an incident. Review it after launches, acquisitions, vendor changes, and domain retirements. If a domain is no longer needed, document whether it should remain registered, redirect, or be securely retired.

3. Monitor registrations, DNS, and website observations

Use approved domain-monitoring, registrar, DNS, certificate, hosting, or security tools to watch for both new lookalike domains and changes affecting domains you control. The exact sources and alert speed depend on the services you use; the cited guidance establishes the need to monitor but does not rank products or promise universal coverage.

Lookalike registrations and observed sites

Monitor for names that substitute, add, remove, or rearrange characters; use common misspellings; combine your brand with words such as “support” or “login”; or use a different top-level domain. Include likely visual and linguistic variations relevant to your brand and users. A monitoring service may also report observed web content, but a registered domain with no visible site can still merit review.

Changes to your domains and DNS

Watch registrar and DNS records for unexpected changes, including nameserver changes, new or modified records, and newly created subdomains. Confirm that the people and automation authorized to make changes are known. Investigate unexplained changes promptly, especially for domains used for authentication, customer access, or email.

Dangling DNS and subdomain takeover

Periodically check whether each subdomain’s DNS target still belongs to an active resource under your control. A CNAME or other record that points to a deleted cloud application, hosting project, or third-party service may leave a claimable endpoint. Remove stale records or restore the intended resource, and verify ownership before reconnecting a service.

CISA describes both unauthorized registration changes and subdomain takeover as distinct risks. Registration hijacking can follow compromise of a registrant’s email, social engineering of registrar support, renewal gaps, or compromise of a domain-management service. A subdomain takeover can arise when DNS points to a nonexistent or deprovisioned resource. CISA’s Domains technique reference documents these threat patterns.

4. Triage an alert before calling it fraud

A close spelling match is an indicator, not a verdict. Legitimate subsidiaries, campaigns, localization, vendors, and product launches can resemble suspicious findings. Assign a named owner to review alerts and use a consistent validation checklist.

Compare the domain with your inventory, approved brand variants, recent launches, subsidiaries, and vendor relationships.
Check registration and DNS details using your organization’s approved tools. Note whether the finding is a registration, a DNS change, or an observed live website.
Review the site safely through approved security tooling. Do not enter credentials, download files, or interact with suspicious content from a normal work session.
Look for evidence of impersonation, such as copied branding, credential collection, misleading contact details, or links that direct visitors to unrelated destinations. Treat each observation as evidence to validate, not an automatic conclusion.
Set severity based on likely user exposure, the importance of the impersonated service, observed malicious behavior, and whether the domain or account is under your control.

For a visual record of an accessible suspicious page, a screenshot can preserve what a reviewer saw at a particular time. It is supporting evidence, not proof of who registered or operated the domain. Store it with the observation time, full URL, relevant DNS or registration findings, and the reviewer’s notes.

5. Preserve evidence and respond

For a credible finding, preserve the facts needed by your security team and service providers. Follow your organization’s incident process and evidence-handling rules.

Record the full domain and URL, date and time observed with timezone, and how the alert was received.
Save screenshots or other permitted captures, DNS observations, registration details available to your team, and relevant email headers or message samples if email is involved.
Keep original files and notes with access controls appropriate to the incident. Record who collected each item and when.
Escalate through the incident-response owner. Depending on the finding, involve the registrar, DNS provider, hosting or cloud provider, email provider, and internal legal, communications, or privacy teams.
Use the relevant provider’s abuse or security-reporting channel and include concise supporting evidence. Procedures and outcomes vary by provider and jurisdiction; do not assume a universal takedown process or timeframe.
After containment, update the inventory, correct stale DNS or account controls, and document any monitoring gap the incident exposed.

If the issue is an unauthorized change to a domain you own, contact the registrar and DNS provider through verified support channels and secure the associated accounts. If a subdomain points to a deprovisioned service, remove or repair the record and coordinate with the service provider. If a lookalike is impersonating you, preserve evidence and use the applicable hosting, registrar, and internal escalation paths.

6. Add email controls for the neighboring risk

Website monitoring does not stop someone from forging an email that claims to come from your domain. Configure and maintain SPF and DKIM, then use DMARC policy and reporting to monitor and improve email authentication. Introduce policy changes carefully: validate legitimate senders first so that authorized mail is not rejected unexpectedly. DMARC also does not discover every fraudulent website or control mail sent from a different domain.

7. Make monitoring operational

Alerts only help when someone reviews them and knows what action to take. For each monitored asset or alert queue, define:

Owner: the team or person responsible for review and escalation.
Review schedule: how often alerts are checked and how urgent changes are surfaced.
Validation steps: where to check inventory, registration, DNS, and observed site evidence.
Severity and response path: who handles suspected impersonation, domain-control changes, and dangling DNS.
Evidence location: an approved place to store timestamps, screenshots, and observations.
Closure criteria: what confirms a finding is legitimate, mitigated, or still under investigation.

When evaluating a monitoring service, compare coverage of owned domains and subdomains, detection of newly observed lookalikes and changes, alert speed, evidence and context, false-positive handling, incident-workflow integrations, and response support. Ask how the provider describes its data sources and blind spots. The official sources cited here do not publish comparable provider performance figures.

8. Capture a suspicious page for review

For a one-off visual record, a developer can open the page in a browser and save a screenshot. Treat untrusted sites carefully: use an approved isolated environment, do not submit credentials, and preserve the exact URL and capture time separately. Browser output is only a visual snapshot; it does not establish ownership, intent, or what the site served to other visitors.

npx playwright install chromium

Save the following as capture.mjs, then run node capture.mjs https://example.com suspicious-page.png. Replace the example URL with the URL under review.

import { chromium } from 'playwright';

const url = process.argv[2];
const output = process.argv[3] ?? 'capture.png';
if (!url) throw new Error('Usage: node capture.mjs <url> [output.png]');

const browser = await chromium.launch({ headless: true });
try {
  const page = await browser.newPage({ viewport: { width: 1440, height: 1000 } });
  const response = await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 30000 });
  await page.screenshot({ path: output, fullPage: true });
  console.log(JSON.stringify({
    url: page.url(),
    status: response?.status() ?? null,
    title: await page.title(),
    capturedAt: new Date().toISOString(),
    output
  }, null, 2));
} finally {
  await browser.close();
}

The script waits for the initial document, rather than every network request to finish. This avoids hanging on pages with long-lived connections, but some late-loading content may be absent. Use a disposable, isolated browser environment for suspicious sites, and follow your security team’s rules for outbound requests and evidence collection.

Useful capture options

fullPage: true captures the page’s full scrollable height where supported. Long or dynamically growing pages may need a maximum-size policy.
viewport sets the visible browser dimensions. Use a consistent size when comparing captures.
waitUntil: 'domcontentloaded' waits for document parsing. load waits longer for page resources; network-idle waits can be unreliable on pages with persistent requests.
timeout bounds navigation time. Capture the resulting failure in your incident notes instead of retrying indefinitely.
For an element capture, locate it with a selector and use the locator’s screenshot method. A missing or changing selector should be recorded as a capture limitation.

Playwright’s official documentation covers screenshots and page navigation options. A local browser capture has no per-image API fee, but you maintain the browser installation, execution environment, storage, retries, and security controls yourself.

9. Troubleshoot common monitoring and capture problems

Problem	Likely cause	Practical fix
Many harmless lookalike alerts	Legitimate campaigns, vendors, subsidiaries, or common words resemble the brand.	Validate against the inventory, record approved exceptions, and tune alert rules without suppressing genuinely new variants.
Unexpected changes to a live domain	Unauthorized access, an unplanned deployment, or an undocumented administrator action.	Verify internally, preserve timestamps and records, and escalate to the domain owner, registrar, DNS provider, and incident team as appropriate.
Subdomain points to an unavailable service	The resource was removed while its DNS record remained.	Confirm the intended owner, remove the stale record or restore the service, and verify the endpoint cannot be claimed by another party.
Screenshot navigation times out	The host is slow, unreachable from the capture environment, or keeps requests open.	Use a finite timeout and a suitable navigation event; preserve the timeout as an observation. Do not infer that a timeout proves the site is safe or malicious.
Page looks blank or incomplete	Content loads after initial navigation, scripts fail, or the site varies content by location or session.	Record the capture conditions and try a controlled wait or authorized session in an isolated environment. Keep the original capture and note the limitation.
Browser cannot open the site	DNS failure, TLS error, network policy, or an unavailable host.	Record the error and timestamp, then use approved DNS and security tools to investigate. A failed capture is not evidence that no site exists.
Evidence does not establish who operated a page	A screenshot records appearance, not registrant identity or intent.	Pair it with registration, DNS, hosting, and incident records obtained through approved sources.

10. Performance, reliability, and cost

Domain monitoring is an ongoing detection process, not a guarantee that every registration or change will be observed immediately. Coverage depends on the services and data sources in use. Set review expectations with your provider, monitor the health of alert delivery, and make sure ownership does not depend on one person’s inbox.

For browser captures, concurrency consumes CPU and memory, and full-page screenshots can use substantial memory on long pages. Reuse a managed browser process for batches where appropriate, cap concurrency, set navigation timeouts, and store only the evidence your process needs. Avoid repeatedly capturing the same page without a reason; keep the capture timestamp and conditions so later reviewers can interpret differences.

A local browser workflow avoids a per-request screenshot API charge, but has operational costs: browser updates, compute, storage, maintenance, and safe execution. A hosted screenshot API trades some of that setup for a service fee, so assess its security model, data handling, capture controls, billing behavior, and fit with your evidence process. No provider should be treated as a replacement for domain inventory, DNS ownership controls, incident response, or email authentication.

11. FAQ

Does a lookalike domain prove that someone is committing fraud?

No. It is a signal to validate. Organizations and vendors can have legitimate names that resemble yours.

Can monitoring prevent domain hijacking?

Monitoring can reveal suspicious changes, but prevention also depends on protecting registrar and DNS accounts, renewals, and administrative access.

Does DMARC monitor fake websites?

No. DMARC addresses authentication and reporting for email using a domain. Website and domain monitoring address registrations, sites, and domain changes.

Should we keep former domains?

Make an explicit retirement decision with the domain owner. CISA and the FBI warn that a former organizational domain allowed to lapse may be acquired and misused.

12. Or skip the browser setup

For a visual snapshot, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. It can help preserve a view of a suspicious page, while domain and DNS investigation still establish the wider context. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o suspicious-page.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
open("suspicious-page.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('suspicious-page.webp', res);

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed, and response headers report the page verdict and billing status. An MCP server lets AI agents use the take_screenshot, get_page_info, and capture_pdf tools. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.