Typosquatting Is a Domain Game You Cannot Win

Typosquatting is the registration of domains that imitate a real one, usually to harvest credentials or deliver malware to someone who mistyped or misread a link. Almost every defense on the market fights it at the domain layer, buying variants and subscribing to reputation feeds, which is a race against an attacker who can register a new name for a few dollars in a few minutes. dope.security treats it as an egress problem instead: the agent inspects the session on the device, so a lookalike domain gets judged by what is being submitted to it, not by whether anyone has seen the name before.

The defense everyone buys is a subscription to yesterday's list

Ask a security team how they handle typosquatting and you will hear a version of the same three answers. They registered the obvious variants of the company domain. They pay for a monitoring service that watches new registrations and certificate transparency logs. And they feed a blocklist into whatever web filter they run.

All three are reasonable. All three are reactive by construction. A blocklist can only contain names somebody already reported, and the median lifespan of a credential-harvesting domain is measured in hours, not weeks. By the time reputation catches up, the campaign has moved. That is why the durable part of a defense has to sit somewhere other than the name, and it is worth understanding what your current filter can actually see: our comparison of URL filtering tools lays out which products judge a hostname and which ones inspect the request.

The uncomfortable math is that the attacker's cost per attempt is near zero and yours is not. Defensive registration of every plausible variant of a real brand runs into hundreds of names once you include homoglyphs, hyphen insertions, alternate TLDs, and subdomain tricks like login-yourcompany.support-portal.com, which is not a variant of your domain at all. It is somebody else's domain wearing your name in the path.

What typosquatting actually looks like in 2026

The category has drifted well past mistyped URLs. The common patterns now show up in email, in search ads, in QR codes, and in chat messages, and none of them require the user to fumble the keyboard.

• Character substitution: rn for m, l for I, or a Cyrillic character that renders identically in most fonts.
• TLD swaps: the real name on .co, .cm, .io, or a new gTLD that looks plausible for the industry.
• Combosquatting: the real brand plus a helpful word, like yourcompany-payroll.com or yourcompany-vpn.net, which reads as legitimate infrastructure.
• Subdomain masquerade: your brand as a subdomain or path on a domain the attacker fully controls, which defeats anyone scanning for registrations that contain your name.
• Paid placement: a lookalike bought as a search ad above the real result, so the user never typed anything wrong at all.

Notice what these have in common. In every case, at the moment of harm, the browser has a valid TLS certificate, a padlock, and a page that renders correctly. The only signal that something is wrong is the content of what the user is about to send.

Why DNS-layer filtering structurally misses this

A DNS control resolves a name and either answers or refuses. That is a genuinely useful primitive, and against a known-bad domain it works. Against a domain registered an hour ago it has nothing to check against, because reputation is a lagging indicator by definition.

It also cannot see the part that matters. Roughly 95 percent of web traffic is encrypted, so a resolver has no visibility into the URL path, the form fields, or the credential being posted. Cisco's own documentation is explicit about the boundary here: doing anything payload-aware requires the intelligent proxy with SSL decryption and a root certificate installed, not the DNS tier. We covered that split in detail in our explainer on the difference between URL filtering and DNS filtering.

Encrypted Client Hello makes this worse for anyone relying on names in transit, because the server name that used to leak in plaintext during the handshake stops leaking. If your control depends on reading a hostname off the wire, it is reading less every year, which we walked through in our piece on what Encrypted Client Hello does to web filtering.

The control that survives: judge the submission, not the name

Flip the question. Instead of asking whether this domain is known bad, ask what is being sent to it. That reframing is what makes the problem tractable, because the attacker controls the name and you control the data.

A credential-harvest page succeeds only if a corporate password reaches it. A fake invoice portal succeeds only if a document reaches it. An interception page succeeds only if a session token reaches it. All three are egress events on a managed device, and all three are inspectable at the point where the TLS session terminates. If that termination happens in an agent on the endpoint, you get the plaintext of the submission without a detour and without waiting for anyone else to categorize the domain.

How the approaches compare

Here is the same threat run through four common control points, paired against what an on-device agent does with it.

• Reputation and blocklists: block domains that have been reported, which means a first-hour campaign passes; dope.security inspects the session regardless of whether the domain has ever been seen.
• DNS filtering: answers or refuses a name and cannot read the URL path or the form post; dope.security decrypts on the device and sees the actual request, including what is being submitted.
• Email gateways: catch the message but not the click that arrives by chat, QR code, or search ad; dope.security enforces at the browser regardless of how the user got to the page.
• Cloud proxies: can inspect payloads but only after backhauling the session to a point of presence and back, adding a detour to every request; dope.security inspects locally, with no PoP in the path.
• Browser extensions: see the page but not thick clients, IDEs, or CLI traffic, and can be disabled by the user; dope.endpoint runs at the OS level and covers all egress from the device.

The reason to prefer the endpoint here is not that other controls are useless. It is that a lookalike domain is designed specifically to defeat name-based judgment, so a name-based control is the one layer the attacker has already priced in.

Where Cloud Application Control changes the outcome

The sharpest version of this is tenant control. A lookalike login page is trying to get a corporate credential submitted somewhere it should not go. Cloud Application Control restricts logins to approved tenants, so an authentication attempt against an unapproved destination fails as a matter of policy rather than as a matter of the user noticing the extra letter in the hostname.

That is the same mechanism that lets dope.security allow a corporate ChatGPT account and block a personal one on the same domain: an inspected and injected header inside decrypted TLS, evaluated on the device. DNS cannot do it. A browser-only control cannot do it across thick clients. Most platforms need the proxy plus a data protection add-on plus a higher tier to get close. Related to this, the way attackers borrow a session that is already authenticated is worth reading alongside our post on malicious browser extensions, which run the same play from inside the browser.

A practical program that is not a registry arms race

Keep the monitoring. It is cheap and it occasionally catches something early. Just stop treating it as the control.

• Register the handful of variants that matter for your brand and stop there. The long tail is not winnable and the budget is better spent elsewhere.
• Move inspection to the point of submission, so a first-hour domain gets judged on the credential it is asking for rather than on its reputation score.
• Restrict authentication to approved tenants, which turns a whole class of credential-harvest pages into a policy failure instead of a user judgment call.
• Cover non-browser egress. Thick clients, IDEs, and command-line tools follow links too, and extension-based controls do not see them.
• Instrument the aftermath. If a submission does happen, you want the record of what left, which is a data-in-motion question rather than a domain question.

For teams currently running DNS-layer filtering, the migration is usually less work than expected. Outreach Health, a healthcare organization with 34 offices, secured 99 percent of its devices within one week after replacing a legacy secure web gateway, and saw a 70 percent reduction in web access tickets within 90 days. If you are comparing against Umbrella specifically, our Cisco Umbrella alternatives comparison is the closest match to this decision.

The point

Typosquatting persists because the industry keeps answering it with a list, and a list is always one registration behind. The attacker's advantage lives entirely in the name, so the defense has to live somewhere the name does not matter. Inspect what leaves the device, restrict where credentials can be submitted, and the lookalike domain becomes a page that loads and then fails to accomplish anything.

Want to see what your current filter is actually inspecting? See how Fly Direct works or book a 20-minute demo.

Frequently Asked Questions

What is the difference between typosquatting and combosquatting?

Typosquatting registers a misspelling of a real domain, like yourcompnay.com. Combosquatting keeps the brand spelled correctly and adds a word, like yourcompany-payroll.com, which is harder to spot because nothing looks wrong. Combosquatting is the more common pattern in credential harvesting now, and neither one is reliably caught by reputation feeds in the first hours of a campaign.

Can DNS filtering block typosquatting domains?

It can block the ones already categorized as malicious, which is a real but partial win. It cannot evaluate a domain registered an hour ago, and because most traffic is encrypted it cannot read the URL path or the credential being posted. Cisco's own documentation states that payload-aware control requires the intelligent proxy with SSL decryption rather than the DNS tier.

Should we defensively register every lookalike domain?

Register the small set that maps to your highest-risk workflows, such as payroll, VPN, and single sign-on naming patterns. Beyond that the combinatorics defeat the budget, since homoglyphs, hyphenation, and new TLDs generate hundreds of plausible names. Spend the remainder on a control that does not depend on having predicted the name.

Does certificate transparency monitoring solve this?

It gives you earlier warning than waiting for a report, because a lookalike usually needs a certificate before it can look convincing. It is still detection, not prevention, and it produces a queue somebody has to work. Treat it as an input to threat intelligence rather than as the enforcement layer.

How does dope.security stop a credential submission to a lookalike domain?

The dope.endpoint agent terminates TLS on the device, so it sees the actual request rather than just the hostname. Cloud Application Control restricts logins to approved tenants, so an authentication attempt to an unapproved destination fails on policy, and Dopamine DLP inspects uploads and prompts for sensitive content on the way out. None of that requires the domain to have a reputation yet.

Do we still need email security if we inspect at the endpoint?

Yes. Email gateways remove a large volume of the initial delivery, and there is no reason to give that up. The gap they leave is every other delivery path, including chat messages, QR codes, search ads, and links pasted between colleagues, which is precisely where endpoint egress inspection earns its place.