Verdicts, change events and the evidence pack

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. No change to it is recorded or alerted, even if it later gains mail, because a domain you own gaining mail is not a threat
Unrelated	Silenced, but re-raised if it rises into Active threat: a genuinely unrelated business that starts copying your homepage is a new fact, and a verdict given in March should not hide it in June
Known	Kept visible, and its changes are still recorded, but it does not alert. 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: Security, Impostor domains, the lookalike's row, Verdict. iOS: open the lookalike; Your call sets It's ours, An unrelated business, or We know about it. The list groups lookalikes under Needs review, Watching and Dismissed (with Restore).
API/MCP: PUT /api/domains/:id/lookalike-verdict (lookalike, verdict, note); tool set_lookalike_verdict.

Change events

Each watch run compares the new reading with the last and records events:

Event	Meaning	Alerts?
appeared	A new lookalike	Only if it can already receive mail or is already an Active threat
gained_mx	It can now receive mail	Yes
lost_mx	It can no longer receive mail	No
gained_certificate	Its first certificate was issued, where the last check had confirmed it had none	No
started_resolving	It now points at a live server	No
escalated	Its band rose into Suspicious or Active threat	Only into Active threat
went_dark	It stopped resolving, or a lookup this run confirmed it is no longer registered	No

A change is recorded only when both the old and the new reading were actually observed. A lookup that failed or was skipped this run is "unknown", never a change, so a busy resolver or a skipped certificate lookup cannot produce a false "lost mail" or "gained a certificate" event. A lookalike that simply drops out of a scan's results is not reported as gone either; only a lookup that confirms it is no longer registered does that. The same change seen again within 24 hours is folded into the existing event.

Events have a lifecycle (acknowledge, resolve) and are the source of lookalike alerts; see Lookalike watch and alerts for which ones alert and how to turn alerts on. 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=… (tool get_lookalike_evidence) assembles what is known about one lookalike into one document:

the registration record, looked up fresh: registrar, registration and expiry dates, registry statuses, and the registrar's abuse address;
a list of observed facts, each one checkable from public records: when it was registered and that your domain is older, whether it publishes MX records, whether it resolves, when its certificate was issued, whether it serves your site icon, its homepage title beside yours (where clearance allowed the comparison), and how many other lookalikes share its nameservers;
a ready-to-send complaint (subject and body) built from those facts, noting when the name uses look-alike non-Latin characters;
where to report it instead when the registry record names no abuse address.

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 registration record). When there is no abuse address, the pack points to the ICANN registrar lookup, the Anti-Phishing Working Group and Google Safe Browsing for phishing, and a UDRP complaint as the formal route. DomainGuard does not file on your behalf and cannot take a domain down.

A lookalike on a shared hosting service, such as yourbrand.pages.dev or yourbrand.myshopify.com, was never registered, so the pack skips the registration lookup and leaves the registrar fields empty. Its complaint says the site is "hosted on" that service and is meant for the service's own abuse process. The pack points there, and to the Anti-Phishing Working Group and Google Safe Browsing for phishing. Only the service can remove the site; a registrar or a UDRP complaint cannot.

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 from the API and the MCP tool. The complaint body is plain text you can paste into an email.