Lookalike domains

Domains built to be mistaken for a brand come in three shapes. They are found differently and they defeat different checks, but they are triaged the same way.

Reputable owners register lookalikes of their own names, so a lookalike is not malicious by being one. The question each time is whether the brand controls it.

Finding candidates

Misspellings and homoglyphs

datapulse_dns_searchlabels searches the corpus’s labels, the part of a registrable domain below its public suffix (example in example.com):

datapulse_dns_searchlabels(search_term="example")

Its fuzzy matching finds homoglyph and IDN lookalikes (examp1e, xn-- labels). It does not systematically find plain typos (omission, duplication, adjacent keys, transposition, added or removed hyphens; the observation is in datapulse_help(topic="searchlabels")). Typo variants are generated by hand and searched exactly, one per call:

datapulse_dns_searchlabels(search_term="exmple", filter=["exact"])
datapulse_dns_searchlabels(search_term="exmaple", filter=["exact"])
datapulse_dns_searchlabels(search_term="examole", filter=["exact"])

A label’s tlds are the TLDs where it is listed (active names only), not every TLD where it is registered; datapulse_live_rdap settles whether a gap is unregistered.

IDN variants. datapulse_idn_variants lists the allocatable and blocked variants of a label under ICANN’s Root Zone Label Generation Rules (simplified and traditional Chinese forms, Cyrillic and Latin lookalikes), registered or not. See datapulse_help(topic="idn_variants").

Brand + word names

These are spelled correctly, so there is no misspelling to detect. A substring search finds them:

datapulse_dns_searchlabels(search_term="example", filter=["substring"])

A common brand string fills the result limit; the reply then carries complete: false, and a longer search term (exampledrive) narrows it. See datapulse_help(topic="searchlabels").

This shape matters because it defeats the three checks triage usually stops at: such a domain is frequently old, opens the brand’s real website under a valid certificate, and publishes an MX that names the brand’s mail platform. All three can be true of a domain the brand does not control (see What the easy checks prove).

Cloaked hostnames

The attacker controls the real registered domain and arranges the hostname so the brand comes first: driveezmd.com-pqsx.win reads as driveezmd.com, but the registered domain is com-pqsx.win. TLD-like fragments (com-, gov-, uk-, de-, ca-, org-) are inserted to fake a boundary. Reading right to left finds the control point:

The brand sits in a subdomain, and the corpus holds registrable domains, not hostnames, so a label search for the brand does not find cloaked hostnames. The pivots that work start from the registered domain:

• Its label construction. datapulse_dns_searchlabels(search_term="com-", filter=["substring"]) returns a capped sample (complete: false) of labels sharing the fake-boundary construction; a longer fragment (com-pq) narrows it.
• Its infrastructure. datapulse_dns_dptechsim(domain="com-pqsx.win", similarity=0.90) widens to names on the same nameserver, mail and hosting stack.
• Its registration. datapulse_live_rdap(query="com-pqsx.win") gives the registrar and date; datapulse_dns_regclusters with that registrar’s ID and date lists the same-day registrations at that registrar (see datapulse_help(topic="infrastructure")).

RDAP and history lookups go to the registered domain (com-pqsx.win); DNS and scrape lookups take the full hostname. Campaigns of this shape are common in SMS phishing (toll-road fines, carrier reward points, account resets), and one reported hostname usually belongs to a larger automated set.

What the easy checks prove

Age proves the name is old, not who owns it

registrationdate measures how long the string has existed. Lookalike names are often registered early, held dormant, and activated or resold later: a 2012 registration date on a name activated in 2026 describes 2012. The operational history (datapulse_dns_dphistory) separates a long registration on stable infrastructure from one with a short or churning record.

A redirect hands over the destination’s identity

When a domain redirects to the brand’s real site, the page rendered and the TLS certificate validated belong to the destination: they are evidence about the brand’s property, not about the domain under investigation. In datapulse_domain_overview or a scrape result:

A genuine brand property normally presents a certificate whose subject is the domain itself. The origin of the redirect is the question. The domain’s own A/AAAA records name the network that issued it, and datapulse_live_rdap(query="<ip>") names that network’s holder (organization, network_name). A redirect to the brand from the brand’s own edge network is consistent with brand control; the identical redirect from a general-purpose VPS is a third party pointing at the brand. The destination looks the same in both cases.

An MX record is a claim, not a credential

Anyone may publish an MX naming any platform. Whether the platform accepts the domain, and whether SPF and DMARC protect it outbound, are separate questions answered in datapulse_help(topic="email_security").

What resolves control

Lock depth, against a domain the brand certainly owns

Comparing the RDAP status arrays of the candidate and a known-good brand domain is strong comparative evidence when the brand’s portfolio is consistent:

datapulse_live_rdap(query="exampledrive.com")
datapulse_live_rdap(query="example.com")        # known-good reference

Lock depth is a configuration the owner chose; a registrar name is a shortcut that misreads acquisitions, regional offices and legacy registrations. Neither is decisive alone: not every legitimate owner arranges registry locks, so a missing lock is a difference from the reference, not a verdict. datapulse_live_rdap can answer from a cached summary (source says which: cache, datapulse, live); force=true gives a fresh registry answer when the posture may have changed. More on status codes: datapulse_help(topic="rdap").

Registrant hidden versus named

GDPR redaction is applied by the registrar to everyone and says nothing about the registrant. A named privacy-proxy service is different: the registrant selected and paid for it, and since attribution is the purpose of a defensive registration, a purchased proxy on a brand-carrying name cuts against brand ownership. These tools return registrar data, not registrant fields, so this signal needs a raw RDAP or WHOIS record from another source (see datapulse_help(topic="rdap") on registrant data).

Nameserver and hosting history

datapulse_dns_dphistory(domain="exampledrive.com")
datapulse_dns_rdap_history(domain="exampledrive.com")

The hosting history records nameserver and MX hostnames with their ASNs (numbers, no operator names) and the web-hosting ASN, mostly at month granularity. Brand portfolios sit on one DNS provider for years. It shows:

• Provider rotation: moves between unrelated nameserver operators
• Hosting churn: a sequence of unrelated hosting ASNs over a short window
• Delegation mismatch: ReportedNS (what the parent delegates) disagreeing with OperationalNS (what answers), which usually means control changed at one layer

The registration history adds registrar transfers and abuse-contact changes over time. See datapulse_help(topic="history").

What does not discriminate

• Shared CDN or parking addresses. “Same infrastructure” means the candidate’s own A/AAAA records on the brand’s own network. A shared CDN, cloud or parking address is common to millions of unrelated names and is not evidence either way.
• Registrar name alone. A registrar is a weak proxy for the configuration lock depth shows directly; an enterprise registrar on the candidate is not proof of brand ownership, and a retail one is not proof against it.
• DNSSEC. Large genuine brand domains are routinely unsigned; signing status answers DNSSEC questions, not ownership ones.
• Infrastructure similarity. A high datapulse_dns_dptechsim score means a similar hosting stack, not a common operator.
• Redirect destination. The origin carries the information, as above.

Triage chain

The same sequence serves all three shapes. For a cloaked hostname, the registered domain takes the place of the candidate in steps 2–4.

# 1. Profile the candidate and a known-good brand domain
datapulse_domain_overview(domain="exampledrive.com")
datapulse_domain_overview(domain="example.com")

# 2. Registration posture: lock depth, registrar IANA ID, dates (force=true for a fresh answer)
datapulse_live_rdap(query="exampledrive.com", force=true)
datapulse_live_rdap(query="example.com")

# 3. Operational and registration history
datapulse_dns_dphistory(domain="exampledrive.com")
datapulse_dns_rdap_history(domain="exampledrive.com")

# 4. Mail posture in its own right (see email_security)
datapulse_live_domain_health(domain="exampledrive.com")

# 5. Widen around a suspicious candidate to names on the same stack
datapulse_dns_dptechsim(domain="exampledrive.com", similarity=0.90)

datapulse_dns_dptechsim defaults to 0.95 (the same hosting setup). Widening around one suspicious seed uses 0.90, which admits names that share major components; the score bands are in datapulse_help(topic="infrastructure"). Either way the matches are infrastructure siblings to examine, not attributions.

Risk matrix

Stating the conclusion

This evidence supports a specific, defensible claim: the domain is not demonstrably under the brand’s control, and is configured in a way that suggests otherwise, together with what the configuration would enable (receiving misdirected mail, sending as the brand, hosting a lookalike page). It does not establish a campaign or intent: no tool here returns intent, and the configuration shows a capability, not a purpose.

Related topics

• datapulse_help(topic="email_security") - SPF, DKIM, DMARC and reading an MX against its tenant
• datapulse_help(topic="searchlabels") - label search: match types, scores, the tlds column
• datapulse_help(topic="rdap") - EPP status codes, lock depth, registrant data
• datapulse_help(topic="history") - reading the hosting and registration histories
• datapulse_help(topic="infrastructure") - similarity scores, registration clusters, registrars
• datapulse_help(topic="malicious_bulk_regs") - campaign-scale triage from registration clusters
• datapulse_help(topic="reconnaissance") - a full single-domain investigation