Skip to main content
Domain monitoring finds look-alikes of a domain your organization owns. You give it acme.com. It generates candidate names, such as typos, swapped or doubled letters, homographs, other top-level domains and added words. It also searches new domain registrations and certificate transparency logs for names that contain your domain. Each candidate that has DNS name servers is registered, and becomes a result. Each result carries its DNS records, WHOIS data and web server status. When a web server answers, the scan also takes a screenshot and scores the URL. If you attach your brand keywords or logo, it checks the site for them too. You then triage the results, watch the ones that matter and, where your plan allows, request a takedown. In the dashboard this is Exposure → Lookalike Domains. The API reference groups these endpoints under the SpoofGuard tag, and your plan lists the plan feature under that name too. The API calls a scan an analysis.

​
How it differs from other searches

Monitors and their matches are a separate product. Domain monitoring has its own look-alike monitors and look-alike alerts.

​
Before you start

  • Your plan includes Domain Monitoring. Without it, the scan, brand library, look-alike monitor and alert endpoints return 403.
  • The domain is a registered asset of your organization. Register it with organization_assets_create, with asset_type set to domain, or in the dashboard under Manage → Assets. A subdomain such as shop.acme.com is scanned only when it is registered as its own asset.
  • Optional: a brand library. A logo, brand keywords, a word list and a list of trusted domains make the scan check more. You can attach them later. See Set up a brand library.
Everything belongs to your organization, not to a user or a key. Scans, the brand library, look-alike monitors and look-alike alerts are shared by the dashboard and every API key of your organization. A scan started in the dashboard appears in the API, and holds the same slot. An API key acts only as its own organization. To scan a client’s domains, register them as assets of your own organization and scan them with your key. They share your slots. A client workspace that the client signs in to is a separate organization with its own keys. See Client organizations.

​
Availability and cost

Availability: Domain Monitoring. Plans and quotas lists what each plan includes. Takedowns and powers of attorney need a second plan feature, Domain takedowns. Cost: no metered allowance. Each distinct domain you scan holds one Monitored Assets slot until you delete its scan. Monitors hold the same slots. Rescans, polling, results, triage, exports and the brand library take no slot. Calls made with your API key count toward the API Calls allowance and the per-second rate limit described in Rate limits. Only 2xx responses count toward the allowance. Domain monitoring endpoints refuse a call in these ways: Scans have no metered allowance, so they never return the allowance 429 with resource and period. Sending a takedown does use an allowance. See Take down a look-alike domain. Handle API errors lists every error body.

​
Monitored Assets slots

Your plan includes a number of Monitored Assets slots. Each distinct domain with a scan holds one slot, whether the scan is running, finished or stopped. Each monitor holds one slot from the same pool. Starting a scan when every slot is in use returns 409, and nothing is created:
limit is your slot count, packs included. Branch on resource, not on detail.
  • Delete a scan or a monitor to free a slot. analysis_delete frees the domain’s slot at once. You can scan the domain again later.
  • Rescan instead of starting again. At the limit, start_domain_analysis returns 409 for every domain, including one you already scan. analysis_rescan needs no free slot.
  • One scan per domain. Starting a domain that already has a scan reuses that scan. It takes no second slot.
Plans and quotas explains how slots and packs work. In the dashboard, Manage → Usage shows how many slots are in use.

​
The workflow

1

Set up a brand library (optional)

Upload a logo, and create brand keywords, a word list and trusted domains. Attach them to a scan by ID. → Set up a brand library
2

Scan a domain

Start a scan of a registered domain, poll it until its results settle, read and filter the look-alikes, mark them reviewed, then export them. → Scan an organization’s domain for look-alikes
3

Watch look-alikes and read alerts

Turn on the scan-wide monitors for new look-alikes, put single results under a look-alike monitor, and read look-alike alerts from one inbox. → Watch look-alike domains and read alerts
4

Request a takedown

Upload a signed power of attorney, prepare a takedown draft for a look-alike, and send it to the registrar or hosting provider. → Take down a look-alike domain

​
Errors you will see

The error body depends on where the call was refused:
  • detail when the API refuses the call itself: plan feature (403), Monitored Assets slots (409), and service failures (502, 504).
  • details when the scanning service refuses it: an unknown scan ID (404), a domain it does not accept, or a scan that is still running (400).
  • message for the per-second rate limit and the API Calls allowance (429), and when the scanning service sends a response the API cannot read (502).
The scanning service’s own request limit returns 429 with detail. Field errors from either source are keyed by field name, for example {"domain": ["..."]}. Read the first of detail, details and message that the body contains.

​
Sort lists by date

The scan list, the look-alike monitor list, the look-alike alerts inbox and the takedown list take a date_sort parameter. The scanning service reads it the other way round: date_sort=desc lists the oldest first, and date_sort=asc lists the newest first.
Omit date_sort to list the newest first. Send date_sort=desc only when you want the oldest first.

​
Endpoints

Every Domain monitoring endpoint is in the API reference. These are the ones each step starts from.