Picture this. Your company owns paypal.com. Somewhere, someone just registered paypa1.com, swapping the letter L for the number 1. At a glance, in most fonts, nobody can tell the difference. That new domain isn't live yet. Maybe it never will be. Or maybe in three weeks it's hosting a fake login page, harvesting your customers' passwords, and quietly ruining your brand's reputation.
This happens constantly, and most companies never know it's happening until a customer complains, or worse, until it shows up in the news.
Why this keeps happening
Registering a lookalike domain costs almost nothing, often less than the price of a coffee. Attackers use a few common tricks:
-
Character typos: swapping, dropping, or duplicating a letter (
gooogle.com,googel.com) - Keyboard slips: substituting a letter with the one next to it on a QWERTY layout
- Homoglyphs: using characters that look nearly identical, like a capital "I" instead of a lowercase "l"
-
Compound squats: adding a word to the brand name, like
yourbrand-login.comoryourbrand-support.net
Any one of these can be used for phishing, credential theft, fake customer support pages, or straight-up brand impersonation. And here's the part most teams miss: even if you know typosquatting exists, actually finding which lookalike domains are currently registered against your brand is a different problem entirely, and knowing whether a domain you found is actually dangerous is a third problem on top of that.
Problem 1: Finding the fake domains in the first place
You can't manually guess every possible misspelling of your brand across 1,500+ domain extensions. Free permutation tools exist, but most of them work by generating typo candidates locally and then resolving each one with a DNS lookup from your own machine. That misses compound squats, wildcard patterns, and anything the generator didn't think to produce. It also means you're the one running potentially thousands of DNS queries just to check.
A more direct approach is to search the domains that are actually registered, instead of generating guesses and hoping one resolves. WhoisFreaks' Domain Typosquats API works this way. You send it a brand keyword, and it searches across 931 million plus registered domains and 1,529+ TLDs for fuzzy matches.
curl --location 'https://api.whoisfreaks.com/v3.0/domain/typos?keyword=yourbrand&apiKey=YOUR_API_KEY'
The response comes back with every matching registered domain, along with its creation date, expiry date, and when it was last seen active. Here's a trimmed version, the real response also includes pagination fields for stepping through large result sets:
{
"status": true,
"totalRecords": 42,
"domains": [
{
"domainName": "y0urbrand.com",
"createDate": "2026-06-02",
"expiryDate": "2027-06-02",
"lastSeen": "2026-08-01",
"isDropped": false
}
]
}
You can also search with a wildcard pattern instead of a plain keyword, which catches prefix, suffix, and hyphenated variants that a simple typo match would miss, things like yourbrand-support.com or login-yourbrand.net.
Problem 2: Not every lookalike domain is actually dangerous
Here's the catch. Once you run a scan, you'll likely get back a list of dozens, sometimes hundreds, of matching domains. Most of them are harmless. Some are parked and doing nothing. Some belong to unrelated small businesses that happen to share a similar name. A handful might be actively serving a phishing page right now.
Treating every result the same way, either ignoring all of them or trying to escalate all of them, isn't practical. What you actually need is a way to separate "genuinely dangerous" from "just similar looking."
This is where a second check comes in. WhoisFreaks' Domain Reputation API takes a single domain and returns a risk verdict, a trust score from 0 to 100, and the evidence behind it. Under the hood, it runs live WHOIS, DNS, SSL, and page content checks, plus a match against WhoisFreaks' own threat intelligence feeds, all in one request.
curl --location 'https://api.whoisfreaks.com/v1/domain/security?domainName=y0urbrand.com&apiKey=YOUR_API_KEY'
A simplified version of what comes back:
{
"risk_category": {
"verdict": "suspicious",
"severity": "high",
"primary_threat": "phishing"
},
"trust_signals": {
"trust_score": 12,
"trust_band": "low",
"indicators": {
"is_newly_registered": true,
"has_dmarc": false,
"uses_free_ssl": true,
"domain_age_days": 24
}
},
"intelligence": {
"recommended_action": "block"
}
}
A domain that's a few weeks old, has no email authentication set up, is running on a free SSL certificate, and redirects somewhere unexpected checks almost every box that real phishing infrastructure tends to check. A trust score in the low band plus a "block" recommendation tells you this one deserves immediate attention, unlike a similar-looking domain that's been sitting parked and unused for three years.
Putting both checks together
Used separately, each API answers half a question. Used together, they form a simple, repeatable workflow:
Brand keyword
↓
Typosquats API → list of registered lookalike domains
↓
Domain Reputation API → trust score + verdict for each one
↓
Result: block, monitor, or ignore
In practice, this means running a keyword or pattern scan against your brand on a schedule (daily or weekly works for most teams), then automatically feeding every new result through a reputation check. Anything that comes back with a low trust score or a "malicious" verdict gets flagged for your security team immediately. Everything else can wait for a routine review, or get ignored entirely if it's clearly unrelated or parked.
This is a small amount of glue code, a scheduled job and two API calls, but it replaces what used to require someone manually checking a list of domains one at a time.
Who actually needs this
This workflow is most useful for:
- SaaS companies, where a fake login page can lead directly to account takeover
- Banks and fintech, where impersonation directly threatens customer trust and money
- E-commerce, where fake storefronts scam customers out of payment details
- SOC and security teams, who need this fed into existing SIEM or SOAR pipelines rather than checked by hand
- MSSPs and anti-phishing vendors, who need to offer this kind of detection as a feature to their own clients
The bigger point
Most companies never check for this until something already went wrong, a customer forwards a suspicious email, or a fake site gets reported after it's already scammed people. Finding lookalike domains early, before they turn into active phishing infrastructure, is the difference between a quiet defensive registration and a real incident response.
The two checks aren't complicated on their own. What makes the difference is running them consistently, and actually acting on what they tell you.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.