Impostor domains
Verdicts, change events and the evidence pack
Tell DomainGuard what a lookalike is (ours, unrelated or known), read the change history for each, and assemble the pack for an abuse report or takedown filing.
Updated · 2 min read
Verdicts
A verdict is your statement about what a lookalike is. There are three, and they are not three words for "dismiss":
| Verdict | Effect |
|---|---|
| Ours | Silenced. You or a sister company own it. It stays silenced even if it later gains mail, because a domain you own gaining mail is not a threat |
| Unrelated | Silenced, but re-raised if it escalates: a genuinely unrelated business that starts copying your title or favicon is a new fact, and a verdict given in March should not hide it in June |
| Known | Acknowledged and kept visible. You know about it and are watching it, or a filing is in progress |
Omit the verdict to clear it. A note can be attached (who owns it, the case number).
- Web: the lookalike's row, Verdict. iOS: Watch or Dismiss moves a lookalike between Needs review and Watching, with Undo.
- API/MCP:
PUT /api/domains/:id/lookalike-verdict(lookalike,verdict,note); toolset_lookalike_verdict.
Change events
Each watch run compares the new reading with the last and records events:
| Event | Meaning |
|---|---|
| appeared | A new lookalike, listed as capable if it already has MX or is an active threat |
| gained_mx / lost_mx | It can (or can no longer) receive mail |
| gained_certificate | A certificate was issued for it |
| started_resolving | It went from parked to live |
| escalated | Its band rose |
| went_dark | It stopped resolving |
Events have a lifecycle (acknowledge, resolve) and are the source of lookalike alerts. GET /api/domains/:id/lookalike-events, POST /api/lookalike-events/:id/acknowledge and /resolve; tools get_lookalike_events, act_on_lookalike_event. Reading the history is free on every plan; being told at the moment of change is the paid watch.
The evidence pack
GET /api/domains/:id/lookalike-evidence?lookalike=… (the "Evidence" action; tool get_lookalike_evidence) assembles everything recorded about one lookalike into one document: the registration record from RDAP (registrar, dates, abuse contact), the DNS as read, its mail capability, its certificates with issuers and dates, the homepage title and favicon comparison where clearance allowed it, and the full timeline of events with timestamps.
It is deliberately not plan-gated: a customer who has found something being used against them should not meet a paywall between the finding and the filing.
Filing
The pack is written for a registrar abuse report (the registrar's abuse address is in the RDAP record), a UDRP or URS complaint, or a report to the certificate authority that issued the lookalike's certificate. DomainGuard does not file on your behalf.
Common questions
I gave a verdict on the web; the app still shows the lookalike under Needs review. Pull to refresh; verdicts are stored on the server and the app's list reloads from it.
Can I export the pack? It is a JSON document over the API and a printable page on the web.
Keep reading
Related articles
- The lookalike checkHow variations are generated and ranked, how many are checked on each plan, what is read about each registered one, and why the result states its coverage.Impostor domains ·Updated
- Change events: "Did you make this change?"How DomainGuard detects DNS, nameserver, registrar and certificate changes, the question it asks, and the lifecycle each event goes through.Domains ·Updated
- SPF, DKIM and DMARC checksHow each record is read and graded, what Pass / Review / Fail mean, the recommended record with a Copy button, and the two DMARC policies labelled honestly.Email authentication ·Updated