Methodology

Principles

The checker reports what public registries and DNS returned at the moment you ran it, and nothing more. It never loads a suspect website to read what is on it, never submits new scans to third parties, never reports an unavailable lookup as a negative result, and never labels a domain malicious on similarity alone. Names on a public hosting platform are the single exception: those platforms answer DNS for every possible subdomain, so each such name receives one request to confirm somebody claimed it, and nothing from the response is read or reported. Every rule below is the rule in the code; there is no undisclosed scoring.

1. Input normalisation

The domain you enter is lower-cased, parsed as a URL if needed, and reduced to its registrable domain using the Public Suffix List, so www.shop.example.co.uk becomes example.co.uk . Internationalised names are converted to their Punycode ( xn-- ) form. IP addresses, private or non-ICANN suffixes, ports, credentials, and labels that are not valid hostnames are rejected with an explanation.

2. Candidate generation

The discovery engine (a separate Cloudflare Worker whose source is in the repository) generates candidate names from the registrable domain with about twenty pattern families modelled on dnstwist: character omission, repetition, transposition, keyboard-neighbour replacement, insertion, hyphenation, vowel swaps, additions, Latin and Cyrillic lookalike characters, bit flips, subdomain splits, prefixed and plural forms, impersonation keywords (login, secure, support and similar) in several positions, about 180 alternative endings including compound ones such as co.uk , and the same name on roughly forty public hosting platforms. The table is produced live for example.com by the same generator that runs your check.

Total for example.com: 3,001 candidates. Every candidate is resolved over DNS over HTTPS; a name that answers with nameservers but no address is kept as dormant (registered, not yet live), and hosting-platform names are confirmed with an HTTP request because those platforms answer DNS for every subdomain. A Workers invocation may make 1,000 subrequests, so the engine resolves candidates in pages of 990 and a check reads up to three pages: names beyond the first 2,970 candidates are not resolved, and the report says so. In parallel, certificate-transparency logs (crt.sh) are searched for names containing the brand, which catches lookalikes that already hold a certificate. When the engine is unavailable the check falls back to a built-in sample of 24 common variations and the report says which mode produced it.

3. Public data sources

Registered and dormant candidates, plus certificate-transparency hits, become the rows of the report. Each row is then ranked (a live HTTPS response first, then impersonation keywords, dormant names, certificate hits, and names with an address) and the top 80 rows receive the full public-record lookups below, in batches of four, with a 4.5-second timeout per request; the passive website search runs only when DNS returned an address. Rows beyond the cap keep the engine’s DNS and HTTP evidence and are marked Engine evidence in the report, with their registry record left unfetched rather than guessed. All requests originate from the server, so providers see the server’s address, not yours.

4. What each field means

Registration is the registry’s RDAP answer: Registered (an object was returned), Not found (HTTP 404, which does not guarantee availability), or Unknown (timeout, rate limit, or no RDAP service for that suffix). Domain age is calculated from the RDAP registration event. DNS / IP , Mail records , and Nameservers are the A/AAAA, MX, and NS answers from Cloudflare’s resolver. Website evidence is a passive urlscan.io search for previous public observations of the host; it is historical and is never a live probe. A direct lookup from the account panel sends the name to urlscans.com for a threat-intelligence verdict instead; that service reports categories and reasons in its own words, and this checker still never loads the site to read what is on it. Where a name resolves, the address alone is sent to a third-party geolocation service (ipwho.is, with ip-api.com as a fallback) to record the country it is announced from and the network that operates it. That is a lookup on the address, not a connection to the site. Treat the country as an estimate: providers disagree, and an anycast address announced from many places at once has no single location.

5. Risk labels

Risk expresses review priority, not a verdict. The rules are evaluated in this order and the first match applies.

Possibly yours. Independently of the label, a registered variation that uses the same registrar as the checked domain and either shares a nameserver hostname with it, runs on exactly the same DNS providers, or sits with a corporate brand-protection registrar (MarkMonitor, CSC, Com Laude and similar, which serve brand owners rather than individuals) is tagged Possibly yours, and the registrar is shown in the row. Brand owners register variations defensively, and that combination is the strongest public hint of it. It is a hint to check your inventory, not proof of ownership, and it never changes the label.

6. Jobs, caching, limits, and fairness

A full check takes one to three minutes, so it runs as a background job and the results page polls its progress. The finished public report is stored for 24 hours under the checked domain and served to anyone who checks the same domain in that time; ?fresh=1 starts a new run. Individual record lookups are also cached in server memory for 15 minutes. A client address may start three checks per minute; beyond that the checker asks you to wait rather than degrading other people’s results. Reports run from a panel account are saved to that account until you delete them.

7. Known limitations

Generation is bounded: names beyond the first 2,970 candidates are not resolved, subdomains of unrelated domains are not enumerated, and the Unicode lookalike coverage is the engine’s homoglyph table, not every confusable in Unicode. Full registry lookups stop at the top 80 rows. Registry data may be redacted or delayed, and some country-code registries do not offer RDAP and will show as Unknown. Certificate-transparency search depends on crt.sh being reachable, and passive website evidence on whether anyone has previously submitted the host to urlscan.io. A clean result therefore means “nothing found among these candidates now”, not “no lookalike exists”.

8. Reproducible example

The sample report for example.com is generated from fixed, clearly labelled fictional data. It uses IPv4 addresses from the documentation range reserved by RFC 5737 ( 192.0.2.0/24 ) and the reserved name example.com from RFC 2606, so nothing in it refers to a real registrant. The live variation list on that page is produced by the same generator described above.

9. Corrections and false positives

If a result looks wrong, tell us through the contact page with the checked domain and the variation in question. Because the checker only reports provider answers, most corrections come from re-running the check after registry or DNS records update; where the rules themselves are at fault we change them and note the change below.

Change log

• 9 September 2026 : Methodology published alongside the first public version of the checker.
• 9 September 2026 : Keyword patterns now reach Elevated only on registrations under a year old; older keyword domains are Review. Added the Possibly yours tag for variations that share registrar and nameservers (or DNS providers) with the checked domain, and the registrar is now shown in each row.
• 9 September 2026 : Candidate generation moved to the discovery engine: about twenty pattern families, 180 endings, hosting platforms, dormant-registration detection and certificate-transparency search replace the 24-variation sample, which remains only as a fallback. Checks now run as background jobs, public reports are kept for 24 hours, and full registry lookups cover the top 80 rows.