Typosquat detection: 5 methods and their trade-offs

There is no single right method for finding typosquats — only combinations of imperfect signals, each with a failure mode worth knowing before you trust it. This guide covers five: dnstwist-style enumeration, Certificate Transparency, newly-registered-domain feeds, zone files, and search monitoring.

It also includes a result we didn't expect. On July 25, 2026 we audited our own pipeline: of the 347 candidates it had rated high or critical, we drew 100 at random and probed each one. Not one was a live site impersonating anyone, and 87 no longer existed. The numbers are below, under What 100 high-scoring candidates turned out to be. Finding candidates is the easy half. Deciding which one deserves a human is the half that decides whether the queue is worth watching.

If you want to try a one-shot scan before reading further, the free typosquat candidate generator will enumerate candidates for any brand domain you type in.

What counts as a "typosquat domain" in practice

Before picking a detection method, pin down what you're actually trying to detect. Typosquats split into four families:

1. Character-level mutations (dnstwist-family)

opnbait.com (omission), oepnbait.com (transposition), opeen-bait.com (insertion). Generated manually by attackers or in bulk by automation.

2. Homoglyphs

ASCII characters replaced by visually identical Unicode (Cyrillic а in place of Latin a, 1 for l). Modern Chromium browsers will Punycode-encode these in the address bar, but in emails and chat apps the judgment is left to the user.

3. TLD swaps

openbait.com → openbait.co / openbait.shop / openbait.top. This is the single most common pattern attackers use, because registering a name in a new gTLD costs roughly a dollar and most users never look past the stem.

4. Brand-prefix concatenation

login-openbait.com, openbait-support.com, my-openbait.net. Standard dnstwist algorithms won't produce these — you need keyword dictionaries on top.

Method 1 — Offline enumeration with dnstwist

Overview

dnstwist is the OSS reference for brand-name mutation. Python, one command:

dnstwist openbait.com

Strengths

• Candidate coverage is strong — homoglyphs, character insertion / omission / transposition, keyboard-layout adjacency, all systematically expanded
• Free, offline — your input domain never leaves your machine
• Optional SSDEEP hashing (--ssdeep) compares HTTP responses from candidates against the legitimate site's fuzzy hash, detecting content that's actually been copied

Weaknesses

• Brand-prefix concatenation is out of scope — you need to feed it a keyword list to catch login-brand.com patterns
• No continuous monitoring — you run it once and you're done. Next week's new registrations are invisible.
• Scaling across brands — if you're protecting 10 brands you run 10 separate scans and reconcile the reports by hand

dnstwist is a superb candidate generator but a poor continuous-monitoring system. That's its real position in the toolchain.

Method 2 — Certificate Transparency log monitoring

Overview

Certificate Transparency is the Google-led public log of TLS certificates. Every publicly trusted CA is required to log every certificate it issues. The implication for typosquat detection: the moment an attacker gets a Let's Encrypt cert issued for a lookalike domain, that domain shows up in the CT logs.

The logs are searchable via crt.sh, Facebook's CT monitoring, or Censys. RSS and API subscriptions are supported.

Strengths

• Near-real-time — certificates hit the log within seconds to minutes of issuance
• TLS issuance ≈ imminent weaponization — when an attacker bothers to get a cert, they're about to flip the phishing page live. This is a higher-precision signal than raw registrations.
• Free — crt.sh is open to everyone

Weaknesses

• Noise volume — if you monitor every cert containing "openbait", you'll match every *.openbait.com subdomain your own team stands up. Filtering is mandatory.
• You only see it after the attacker moved — CT log monitoring is detection, not prevention
• API rate limits — crt.sh will time out under aggressive polling. You'll end up building a local cache + diff pipeline if you run this seriously.

In practice CT monitoring is run as a daily (or finer) batch feeding into a triage queue.

Method 3 — Newly Registered Domain (NRD) feeds

Overview

The domain-industry analog of a CT feed — daily bundles of all newly registered gTLDs. Commercial sources include WhoisXML API and DomainTools. Open sources like OpenPhish and urlscan.io publish overlapping (but narrower) intelligence.

Strengths

• Captures domains that never get a TLS cert — CT monitoring misses parked-but-unissued registrations. NRD feeds don't.
• Typically 1–7 days earlier than CT — detection happens at registration, not at certificate issuance
• TLD-level filtering cuts noise fast — focus on .top, .shop, .xyz and you'll slash the search space without losing the majority of abusive registrations

Weaknesses

• Commercial tier is pricey — full-gTLD daily feeds run thousands to tens of thousands of USD/year
• Brand matching is on you — the feed is "all new domains", not "domains that look like yours". You pipe it through your dnstwist candidate list to extract matches.
• Legitimate vs illegitimate is ambiguous at registration time — if openbait-jp.com gets registered, is that a reseller, a partner, or an attacker? You can't tell from WHOIS alone.

Method 4 — Registrar bulk / zone-file data

Overview

The .com and .net zone files are available through ICANN's Centralized Zone Data Service (CZDS) for security and research purposes. Once approved you get a daily snapshot of every single registered domain in that TLD — hundreds of millions of entries.

Strengths

• Diffing consecutive days reveals every new registration — cheap, complete, authoritative
• Free (pending approval with a valid use-case description)
• Goes back to the source — you're reading the registry's own data, not a reseller's

Weaknesses

• Volume — the .com zone is a few GB compressed, tens of GB expanded. Storage and memory planning is a prerequisite.
• Per-TLD approval — you apply separately for .com, .net, .jp, and so on. Some ccTLD registries (JPRS for .jp) have stricter approval criteria.
• Ongoing maintenance — running daily diffs reliably across several TLDs is a small data-engineering project

For most mid-market teams this is too heavy to run in-house. Most teams get it through a platform that handles it for them.

Method 5 — Search engine + social signal monitoring

Overview

Run scheduled queries like "yourbrand login", "yourbrand support", "yourbrand billing" against Google / Bing / Baidu. Anything in the top results that isn't your own domain gets surfaced for review. Pair with username + ad-copy monitoring on X (Twitter), Instagram, TikTok, Facebook.

Strengths

• User-first signal — if a lookalike is ranking on page 1, your users are already being funneled there. Priority of response is obvious.
• Catches social-graph attacks — registrar/CT/NRD monitoring won't surface a TikTok ad campaign impersonating your brand. Social monitoring will.

Weaknesses

• API rate limits + cost — Google Custom Search and Bing Search API free tiers are thin. Running this at scale means commercial quotas.
• Phishing via paid ads bypasses this — if the attacker pays for Google Ads placement they can funnel users without SEO presence, and you'd never see them in organic result monitoring alone.

What 100 high-scoring candidates turned out to be

None of them was a live site impersonating anyone. On July 25, 2026 we audited our own pipeline for the first time: of the 347 candidates it had rated high or critical, we drew 100 at random and probed each one — DNS, HTTP, then RDAP for registration status.

At least five of the dead ones answered with a Cloudflare "Suspected Phishing" interstitial or an HTTP 451, so they had been real and someone had already dealt with them. The detection methods above do find phishing domains. What they find is a registration, and a registration is not an attack: most of these names live for days, and results that were four days old were already 94% dead.

Two lessons came out of it, and they apply to anyone assembling this stack. First, a candidate is not a finding until you have fetched it and it answered — score on what the page does, not on how the name looks. (Ours had rated all 347 "high" while recording a fetch error for every one of them.) Second, naive substring matching on the brand is most of the noise: a name containing "jcb" is usually not about JCB. This is a large part of why OpenBait now starts from the other end — a customer reporting the site they actually landed on — and treats lookalike scanning as a supplement rather than the front door.

Putting it together — how the methods actually combine

Running any one of these in isolation leaves gaps. A realistic combination looks like this:

OpenBait does not run all five. It combines dnstwist-style variant generation (character mutations, brand-prefix concatenation, an IDN homoglyph dictionary), Certificate Transparency logs in real time, the WhoisDS newly-registered-domain list, and Google search. It does not compare zone files. Lookalike checks run every 3 days on the Free plan and daily from Pro up, and Google search is limited by the keyword count of your plan. If you want to take a single snapshot of your brand's exposure, use the free candidate generator. If you need continuous monitoring, start free.

A parting note from the field

Typosquat strategy is not "register everything that matches your brand". Defensive registration costs $10–$100/domain/year. Across a large candidate set, that's a five- or six-figure annual line item nobody authorized.

The candidates you actually act on are the ones meeting at least one of:

1. Active DNS — an attack is either live or staging
2. TLS certificate issued — pre-launch of phishing
3. MX records configured — email-vector attack in play

Everything else goes on a watch list, not a buy list. OpenBait's risk score is only a starting point and doesn't do this sorting for you: in the audit above it rated all 347 candidates high, so a person still has to decide which ones are worth acting on.

Typosquat monitoring is the classic "must-do, under-resourced" job for mid-market security teams. If you want to see what real data looks like, the Free plan covers enough for a meaningful first view.