How to Find Fake Domains Impersonating Your Brand
Somebody registered `acme-support.com` yesterday. Somebody else registered `acmе.com` — with a Cyrillic `е` that looks identical to the Latin one in every major font. Both are shadow domains: lookalikes of your brand, registered days or weeks before the phishing campaign that will use them. This guide shows you how to find them before the campaign launches. Start free on EdgeDNS — 200 requests/month, no credit card required.
First: what shadow domains actually are
A shadow domain is a domain that an attacker has registered specifically to impersonate a real brand. The attacker's goal is simple: get a victim to type or click on the shadow, believing it's the real thing, and either hand over credentials or money or click a malicious download. Every piece of sophisticated phishing infrastructure starts with a shadow-domain registration. The domain comes first. The campaign comes weeks or days later.
The patterns have been studied extensively. The APWG Phishing Activity Trends reports publish quarterly data on the volume and type of attacker-registered domains. The ICANN SSR2 final report documents the structural issues in domain registration that make shadow-domain abuse cheap and easy. Palo Alto's Unit 42 research dissects specific campaigns and their infrastructure choices. Together, they paint a consistent picture: shadow-domain registration is a professionalized industry, run at scale, and the gap between "domain registered" and "phishing email sent" is the window where brand-protection teams can actually win.
That window exists because registering a domain is fast, but setting up a convincing phishing operation around it is slow. The attacker has to configure DNS, get an HTTPS certificate, build the fake site, set up email infrastructure that passes SPF/DKIM checks, and warm up the sending IPs. That setup usually takes one to three weeks. A brand that catches the registration on day one has that entire window to act. A brand that catches the registration at the same time as the first phishing complaint is already in incident-response mode.
The threat in one paragraph
Shadow-domain monitoring is the practice of enumerating every plausible lookalike of your brand domain — typos, TLD variants, hyphenation tricks, homographs — and checking continuously which ones have been registered, which are actively hosting content, and which are set up to send email. The goal is to find hostile registrations during the setup window (days or weeks before the phishing campaign launches) rather than during the campaign itself.
The single best brand-protection investment most companies haven't made is continuous shadow-domain monitoring. It's cheap, it's automatable, and catching a hostile registration before the campaign launches is worth more than any post-incident response.
Why catching shadows early beats catching phishing late
The economics of brand protection strongly favor early detection. Three reasons it matters:
First, the damage scales with time. A phishing campaign that runs for three hours before the brand team notices affects a small number of customers. The same campaign running for three weeks affects orders of magnitude more. Catching the underlying registration on day one and filing a takedown within 24 hours can prevent the campaign from ever reaching customers in meaningful volume.
Second, the takedown process is slow — so start it early. Filing a UDRP (Uniform Domain-Name Dispute-Resolution Policy) complaint, getting a registrar to suspend a domain, or getting browser-based blocklists (Google Safe Browsing, Microsoft SmartScreen) to flag a shadow all take days or weeks. Starting the clock on day one of the registration means the takedown can happen before the campaign goes live. Starting the clock after the first phishing email means you're playing catch-up while customers are being targeted.
Third, early detection supports legal defense. When a brand has to demonstrate that it actively monitored for impersonation and took prompt action, the documented timeline matters. "We detected the registration on day one, filed UDRP on day three, got it suspended on day twelve" is a defensible record. "A customer complained and we investigated" is not.
Picture this in real life. A financial-services brand ran shadow-domain monitoring for the first time in early 2024. Within the first week, the system surfaced 40 registered lookalikes of the brand's primary domain. Most were dormant speculator squats. Two had active MX records and TLS certificates — infrastructure consistent with imminent phishing. The brand filed UDRP on both, got one suspended within two weeks, and a full phishing campaign that had been in preparation was never sent. The total cost of the monitoring was far less than the customer-service cost of handling a single successful phishing incident.
Three questions a shadow-domain check answers. If you care about brand protection, these are the questions that matter:
Which permutations of my brand domain are currently registered?
Which of those are weaponized (active hosting, TLS cert, MX records) versus merely speculatively squatted?
Is anyone registering a new permutation right now that I should preemptively buy, file UDRP on, or report?
For any of these, a one-time scan is a snapshot. What you want is continuous monitoring.
The six ways attackers generate lookalike names
Good monitoring systematically covers the full permutation space. The six main categories are:
1. Character-level typosquats. Edit-distance-of-one variants: `gogle.com` (deletion), `googlle.com` (insertion), `goolge.com` (transposition), `goojle.com` (substitution). A comprehensive scan generates all single-character edits of each letter in the brand name. For a ten-character brand, that's roughly 250 candidates.
2. TLD variants. The same name across every significant TLD: `.com`, `.net`, `.org`, `.co`, `.io`, `.app`, country-code TLDs (`.co.uk`, `.ca`, `.de`), and the new-gTLD long tail (`.xyz`, `.top`, `.click`, `.support`). The new-gTLD space is where most high-volume phishing registrations happen — ICANN's CCT metrics data shows consistent concentration of abuse in a handful of permissive new-gTLD registrars.
3. Homograph attacks. Unicode characters from Cyrillic, Greek, or other scripts that look visually identical to Latin characters. The most infamous are Cyrillic `а` (U+0430) substituting for Latin `a` (U+0061), Cyrillic `е` (U+0435) substituting for Latin `e` (U+0065), and Greek `ο` (U+03BF) substituting for Latin `o` (U+006F). In most fonts, `аpple.com` with a Cyrillic `а` is visually indistinguishable from `apple.com`. Modern browsers detect some of these and show punycode in the address bar, but not all, and not consistently.
4. Hyphenation and prefix/suffix tricks. `brand-login.com`, `secure-brand.com`, `brand-support.com`, `mybrand.net`, `brandhq.com`. These look legitimate because many real brands do use hyphenated subdomains or multi-word variants. The attacker is betting on the victim not scrutinizing the exact URL.
5. Subdomain spoofing under attacker-controlled domains. `brand.attacker-site.com` or `brand.com.attacker-site.com` — the victim skims the URL, sees `brand.com`, and clicks. This isn't technically a shadow-domain registration (the attacker is using their own domain) but it shows up in brand-abuse reports and should be tracked alongside the registration-based patterns.
6. Semantic variants. `acmesupport.com`, `acmehelp.com`, `acmebilling.com`, `acme-customerservice.com` — plausible-sounding additions that victims accept because they describe plausible corporate functions. These are harder to enumerate programmatically because they depend on the brand's industry and vocabulary, but they're worth generating by hand for high-risk brands.
How to monitor the permutation space
There are three ways to monitor, from easiest to most thorough.
Fastest (recommended): run the EdgeDNS shadow-domain endpoint against your brand domain. It generates the full permutation space, checks registration status for each, fetches DNS configuration for registered ones, and returns a ranked list with risk grades.
Easier still (if you're using AI): ask your AI assistant, connected via the EdgeDNS MCP server: "Find every lookalike registration of acme.com and rank them by phishing risk." The AI runs the check, reads the output, and explains the findings in plain language — flagging the high-risk ones and suggesting next steps.
Nerdy way (command line): fetch the findings via the REST API and feed them into your brand-protection workflow.
# Get the shadow-domain findings for a brand
curl -s "https://api.edgedns.dev/v1/domain/shadow-domains?domain=acme.com" \
-H "Authorization: Bearer YOUR_API_KEY" | jq '.data.findings[] | {name, registered, mx, tls, risk_grade}'
# Filter to only the high-risk findings
curl -s "https://api.edgedns.dev/v1/domain/shadow-domains?domain=acme.com" \
-H "Authorization: Bearer YOUR_API_KEY" \
| jq '.data.findings[] | select(.risk_grade == "high")'Monitoring shadow domains from Python
If you're running daily shadow-domain monitoring on a schedule, here's a minimal Python example. It pulls the current findings, diffs them against the previous run, and surfaces only the new high-risk registrations — exactly the alert payload most brand-protection workflows actually need.
import json
import os
from pathlib import Path
import requests
API_KEY = os.environ['EDGEDNS_API_KEY']
STATE_FILE = Path('shadow-domains.state.json')
def fetch_findings(brand: str) -> list[dict]:
r = requests.get(
'https://api.edgedns.dev/v1/domain/shadow-domains',
params={'domain': brand},
headers={'Authorization': f'Bearer {API_KEY}'},
timeout=60,
)
r.raise_for_status()
return r.json()['data'].get('findings', [])
def load_previous() -> set[str]:
if not STATE_FILE.exists():
return set()
return set(json.loads(STATE_FILE.read_text()))
def save_current(names: set[str]) -> None:
STATE_FILE.write_text(json.dumps(sorted(names)))
def alert_on_new(brand: str) -> list[dict]:
findings = fetch_findings(brand)
current = {f['name'] for f in findings}
previous = load_previous()
new_names = current - previous
save_current(current)
return [f for f in findings if f['name'] in new_names and f.get('risk_grade') == 'high']
new_high_risk = alert_on_new('acme.com')
for f in new_high_risk:
print(f"NEW HIGH-RISK: {f['name']} (mx={f.get('mx')}, tls={f.get('tls')})")Triaging findings — which shadows to act on
A scan of a well-known brand will typically surface dozens to hundreds of registered permutations. You can't file UDRP against all of them. Triage is about identifying which registrations actually look weaponized versus merely speculative.
Highest priority: active infrastructure. A shadow that has an active HTTPS certificate (check CT logs), responding MX records, and a live web server is the closest to "weaponized." This is infrastructure consistent with imminent or active phishing. Start the takedown clock immediately.
High priority: recent registrations with DNS configured. A domain registered in the last 30 days with MX records pointing at Google Workspace or a throwaway mail service — even if no TLS cert yet — is in the setup phase of a campaign. Document the finding and pre-position a UDRP filing.
Medium priority: long-registered speculative squats. A lookalike registered five years ago that resolves to a parking page hosted by the registrar is almost certainly a domain-speculation squat. Someone is holding it hoping you'll buy it. These are annoying but rarely imminent threats. Consider buying the ones adjacent to important domains; otherwise, monitor for status changes.
Low priority: unregistered permutations. Names in your permutation list that nobody has registered yet. The triage question is whether to preemptively register any of them yourself. For brands in phishing-heavy industries (finance, healthcare, crypto), buying a few dozen obvious permutations is cheap insurance. For other brands, the cost usually isn't worth it.
The triage pipeline is the difference between "here are 200 findings, figure it out" and "here are the 4 findings you need to act on today." Good monitoring systems do the triage automatically; your job is to review the high-priority list and execute the takedowns.
What to actually do about a hostile registration
Once you've triaged a high-priority finding, the action playbook has three parallel tracks.
Track 1: file UDRP or URS. The Uniform Domain-Name Dispute-Resolution Policy (UDRP) is the legal framework for taking back a domain that infringes your trademark. It's administered by WIPO, the Forum, and a few other arbitration providers. The process takes 4–8 weeks on average but produces a binding decision — the domain is transferred to you or suspended. The Uniform Rapid Suspension (URS) is a faster, cheaper variant available for new-gTLDs (`.xyz`, `.top`, etc.) that produces suspension rather than transfer, typically within 3–5 weeks.
Track 2: report to browser blocklists. Google Safe Browsing and Microsoft SmartScreen both accept reports of phishing and malware sites. Getting a hostile lookalike onto these blocklists means Chrome, Firefox, Safari, and Edge all show a full-page warning when users try to visit it — blunting the campaign's effectiveness while the UDRP process plays out.
Track 3: notify the registrar and hosting provider. Most registrars have abuse-reporting processes for clear phishing cases. The big providers (GoDaddy, Namecheap, Cloudflare Registrar) typically suspend clearly-abusive domains within 24–48 hours of a well-documented abuse report. The provider serving the HTTPS cert (usually Let's Encrypt or Cloudflare) can also revoke the cert, which breaks the phishing page's trust chain.
The three tracks are complementary. Running them in parallel maximizes the pressure on the hostile infrastructure and minimizes the window during which victims can be targeted. Good brand-protection tooling automates as much of this as possible — automated UDRP filing, automated blocklist reporting, automated abuse-report submission.
Running this on a schedule
A one-time shadow-domain scan tells you what exists right now. Continuous monitoring tells you what changes — and the changes are where the value is. New registrations that didn't exist yesterday are the signal you actually need.
Daily is the right cadence for most brands. Phishing-campaign setup windows are measured in days to weeks, not months. A weekly scan might miss a fast-moving campaign; a monthly scan will definitely miss most of them. Daily scanning with alerting on any new registration keeps you inside the setup window.
Alert on three events: (1) a new permutation appears in the registered set; (2) an existing registration gains new infrastructure (MX, TLS cert, live web content); (3) an existing registration changes hosting or nameservers (suggests the speculator sold it to an operator).
Subscribe the brand domain to monitoring with an alert destination that actually reaches the right people — typically the brand-protection team, not a generic security alias that nobody reads. The difference between "we caught the campaign before launch" and "we responded after the first phishing emails hit" is often the alert-delivery pipeline rather than the detection itself.
Or — if you've connected the EdgeDNS MCP server to your AI assistant — run a simple daily prompt: "Check for any new lookalike registrations of acme.com since yesterday and flag anything weaponized." The AI fetches the current findings, compares to stored history, and surfaces only the new risks.
Words you might be wondering about
Shadow domain — a domain registered by an attacker to impersonate a real brand for phishing, malware distribution, or credential theft.
Typosquat — a shadow domain that exploits common typos in the brand name. `gogle.com` is a classic typosquat of `google.com`.
Homograph attack — a shadow using Unicode characters that look visually identical to Latin letters. `аpple.com` with a Cyrillic `а` is a homograph of `apple.com`.
UDRP (Uniform Domain-Name Dispute-Resolution Policy) — the legal framework administered by WIPO and others for recovering trademark-infringing domains. Typically takes 4–8 weeks.
URS (Uniform Rapid Suspension) — a faster, cheaper UDRP variant for new-gTLDs. Produces suspension rather than transfer, but takes only 3–5 weeks.
new-gTLD — a top-level domain introduced after 2013 (like `.xyz`, `.top`, `.click`). Historically the highest-abuse segment of the TLD space.
Brand protection — the organizational function responsible for monitoring and responding to impersonation, counterfeiting, and brand abuse across channels including domain registrations, social media, marketplaces, and app stores.
Punycode — the ASCII encoding used to represent internationalized domain names (IDNs) in DNS. `аpple.com` with a Cyrillic `а` encodes to `xn--pple-43d.com` in punycode. Modern browsers show punycode for suspicious mixed-script domains to reveal the homograph.
MCP (Model Context Protocol) — the open standard that lets AI assistants call EdgeDNS tools directly and run shadow-domain checks conversationally.
Related Guides
How to Check Your DMARC Record
If you have ever wondered why some emails land in the inbox and others end up in spam, you have run into the world of email authentication. DMARC is the rulebook that ties it all together. This guide explains it without jargon, shows you how to check yours, and walks you through rolling it out safely.
MCP for DNS: How to Talk to Your Domains
Imagine asking Claude, "hey, is my email setup working correctly?" — and getting a real, accurate answer back, instantly. That's what the EdgeDNS MCP server does. This guide explains what MCP is, why it's a big deal, and how to connect it in about a minute.
How to Detect Subdomain Takeover (Before an Attacker Does)
A subdomain takeover is the vulnerability almost every big brand has at some point: a forgotten CNAME points at a deprovisioned SaaS service, an attacker registers that service's free name, and suddenly they're serving content at a real subdomain of the real brand — with a valid HTTPS certificate. This guide shows you how to find these before anyone else does. Start free on EdgeDNS — 200 requests/month, no credit card required.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.