# When a lookalike name reaches your customers
> A response procedure for the brand protection lead: triage, evidence, the support script, internal messages, which platforms to notify and what to avoid.
Source: https://hush.partners/when-a-lookalike-name-reaches-your-customers
Category: Brand protection
Published by Hush Partners.
---
The report usually arrives sideways. A customer writes to support asking whether a payment name is really yours. A community manager forwards a screenshot. Someone in sales mentions that a partner received an odd message. Nobody has declared an incident yet, and the first person who understands what the report means is often the brand protection lead.
This article is the response procedure for that day. It assumes an onchain name that imitates your brand is already in front of customers, and that you have to decide what to do in the next hours with incomplete information. It does not explain how lookalike names are built or how to spot them in advance: those are separate subjects, and the less a response document says about construction, the better.
The procedure has one priority order that holds throughout: protect customers first, preserve evidence second, notify the parties who can limit the name's reach third, and consider legal and commercial options last. Teams that reverse the order tend to spend the first day drafting a letter while customers keep asking support a question nobody has been told how to answer.
## What a customer report tells you, and what it leaves open
A first report gives you three things: a string of characters, a place where the customer saw it, and the customer's own reading of what happened. Each one needs handling with care.
The string may be retyped, cropped in a screenshot or auto-corrected by a phone. Ask for it as copied text and as an image, both. Small differences decide whether you are looking at a name under a suffix that many people share, at a name under a TLD that itself resembles your brand, or at something that is not an onchain name at all, such as an ordinary DNS domain or a social account. Each of those leads to different contacts.
The place matters more than teams expect. An onchain name is recorded as a token on a blockchain, held in a wallet. The ICANN DNS root does not carry it, and a browser shows nothing for it until some supporting software is in place. So the name reached your customer through something: a wallet app that resolves it, a browser extension, a message on a social platform, a payment request, a link to a site published under the name. That channel is where the harm travels, and it is often where you can act fastest.
The customer's reading is the least reliable part. People report a name as a fraud when it is a coincidence, and as a curiosity when they have already sent money to it. Do not classify the incident from the tone of the first message.
What the report leaves open is everything you most want to know: who holds the name, what they intend, and how many other people have seen it. A block explorer shows the public registry record to anyone who looks, so you can see which wallet holds the name and when it was created. You cannot see the person behind that wallet, and the first day should not be spent trying.
## Triage for the brand protection lead: four grades of lookalike incident
Triage answers one question: how much of the organization needs to move, and how fast. Grade the incident on what the name is being used for, not on how close the resemblance is. A near-perfect imitation that sits unused is a monitoring matter. A clumsy one that collects payments is an emergency.
| Grade | What you observe | Who is engaged | First deadline |
| --- | --- | --- | --- |
| 1. Dormant | Name exists, no records set, no content, no messages | Brand protection only | Log and watch |
| 2. Visible | Name shown in public, resolves to a page or a profile | Brand protection, support, communications | Same working day |
| 3. Soliciting | Name used to ask customers for payment, credentials or contact | Add security, legal, fraud or risk | Within the hour |
| 4. Loss reported | At least one customer says funds or data went to it | Add executive sponsor, regulators as counsel advises | Immediately |
Three questions place almost any incident in the table. Is the name asking anyone to do something? Is it being pushed to people, or does someone have to go looking for it? Has anyone reported a loss?
Record the grade, the time and the person who set it. The grade will change during the day, usually upward as more reports arrive, sometimes downward when a frightening screenshot turns out to be a parked name. A written grade with a timestamp is what lets you explain later why you did or did not wake the general counsel.
## The first-day sequence, in order
The steps below are written for an incident at grade 2 or above. For a grade 1 incident, only the first four apply.
First day of a lookalike incident
Open one incident recordOne document, one owner, one channel. Every report, screenshot and decision goes there with its time. Close any parallel threads that have started in chat.
Confirm what the name isEstablish the exact string, the registry that recorded it, the wallet that holds it and where it resolves. Use a clean device and do not connect a company wallet to any page under the name.
Set the gradeApply the triage table. If a customer reports a loss, go straight to grade 4 and bring in security and legal before doing anything else.
Capture evidenceRecord the name, its public record and every place it appears before notifying anyone. Content that is reported tends to change or disappear.
Brief supportGive support the approved script and a single place to route reports. Support needs this before the public statement, not after.
Notify the channelsSend a factual report to each platform through which the name reaches customers, in order of reach. Keep each acknowledgment in the incident record.
Tell the companySend the internal note described below, with the one sentence staff may repeat and the instruction not to engage with the name.
Decide on a public noticeWith communications and legal, decide whether customers at large need to be told, and where. Not every incident needs one.
Step eight deserves a real decision and not a reflex. A public notice protects customers who would otherwise meet the name unprepared. It also tells a much larger audience that the name exists. At grade 2, where the name is visible but passive, a notice can do more to spread it than the name was doing alone. At grades 3 and 4, where people are being asked to act, silence is hard to defend.
## Building the evidence file while the name is still live
Evidence serves three later uses: a platform report that gets acted on, a legal step if counsel chooses one, and your own review. All three need the same thing, which is a record of what a customer would have seen, when, and through which software.
Collect in this order, because the earlier items change least and the later ones can vanish.
**The public record.** The name, the registry, the token identifier, the holding wallet's public address, the creation date and any transfers since. This is on a public blockchain and will not be edited away, but a dated copy with the explorer page saved is still worth keeping, because it fixes what the record said on the day you looked.
**The records set on the name.** An onchain name can carry records, such as payment addresses for several blockchains or a pointer to a website. Note each one. Records can be changed by the holder at any time, so the state on the day of the report is evidence that only exists if you save it.
**The content.** If the name points to a website, save the pages as rendered and as source, with full-page screenshots that include the address bar and the device clock. A site reached through an onchain name is often stored on IPFS, a network that addresses a file by a fingerprint of its content. Record that content identifier: it stays the same for as long as the content stays the same, which makes it a precise way to tell a host or a gateway what you are reporting.
**The distribution.** Every message, post, advertisement or profile that put the name in front of customers, with its address, the account that published it and the time. Ask the reporting customers to forward originals, not descriptions.
**The effect.** Customer reports as received, with consent to use them, and any transaction a customer says they made. A transaction on a public blockchain has an identifier that anyone can look up. Record it as the customer gives it and do not characterize it.
Three rules keep the file usable. Note who captured each item, on which device and at what time. Store originals unedited and work on copies. Keep the file factual: write that the page displayed your logo and asked for a wallet connection, not that the page was a scam. Characterization is counsel's work, and an evidence file full of adjectives is weaker than one without.
Rules on what makes evidence admissible, and on whether a formal capture by a sworn officer or a specialist service is worth having, vary by country. Ask counsel on the first day whether the incident warrants it, because that kind of capture cannot be done after the content is gone.
## What customer support says, and what it never asks for
Support will be the most frequent point of contact with the incident, and usually the least briefed. The script has to be short enough to use under pressure and accurate enough that it does not need retracting.
The opening lines carry four messages and nothing else:
- Thank you for telling us. The name you saw is not operated by us.
- These are the only names and addresses we use, and this is where we publish them.
- Please do not send funds, connect a wallet or enter details through that name.
- If you have already done so, tell us now and we will pass you to the team that handles it.
Then the script branches on the customer's answer.
For a customer who only saw the name, support thanks them, asks them to forward what they received, and closes. The forwarded original goes into the incident record.
For a customer who interacted but lost nothing they can identify, support routes them to security guidance prepared by your own security team. The content of that guidance is theirs to write. Support does not improvise technical instructions.
For a customer who reports a loss, support moves the conversation to a named person, records the customer's account of events in their own words, and says plainly what is true: a transfer on a public blockchain is generally not reversible by you, by the registry or by a wallet provider, and you will not promise recovery. Support may explain how the customer can report the matter to the police or the relevant consumer authority in their country. Whether your organization owes the customer anything is a legal question that depends on the facts and the jurisdiction, and support does not answer it.
Two things stay out of the script. Support does not repeat the lookalike name in writing more than is needed to identify it, and never as a clickable link. And support does not speculate about who is behind it. A customer who is told that a particular party is responsible will repeat it in public, and you will own the statement.
## Telling the rest of the company without starting a rumor
Inside the organization, a lookalike incident spreads faster than the facts do. Within an hour someone in marketing has looked the name up, someone in engineering has opened the page from a work laptop, and a well-meaning executive has replied to the account that was promoting it. The internal note exists to stop all three.
Send one note, from one sender, to the groups that face customers or the public: support, sales, account management, communications, community, social media, and the executives whose names are publicly associated with the brand. It contains five items.
1. What happened, in two sentences, with the grade.
2. The sentence staff may say if asked: the name is not ours, and here is where our real names are published.
3. Where to send any report or question: one address inside your own ticketing or chat system.
4. What not to do: do not visit the name, do not contact its holder, do not post about it.
5. When the next update will come.
Keep the note free of theory. It does not say who you think is responsible, how the imitation was constructed, or what legal steps are under consideration. Internal notes are forwarded, and in some legal systems they can later be requested by the other side in a dispute. Counsel will tell you how privilege works where you operate. Until then, write every internal message as if the holder of the name will read it.
## Which platforms to notify about a lookalike name, and what each can do
No single party can remove an onchain name from the world. This is the main structural difference from the DNS, and it should be stated honestly to everyone involved. A DNS domain sits under a registrar and a registry with contractual abuse procedures, and a trademark owner has the UDRP, a dispute policy that binds registrants of ICANN domains through their registration agreements. That policy does not reach names recorded outside the ICANN system. For this kind of incident, the DNS is simply better equipped.
What you can do onchain is narrow the name's reach. The token may remain in the holder's wallet while the name stops being displayed, resolved, promoted or hosted in the places where customers meet it. Each platform controls one of those functions and none of the others.
| Party to notify | What it controls | What to ask |
| --- | --- | --- |
| The naming registry | Its own terms, resolver and services | Review under its published terms |
| Wallets and extensions that resolve the name | Whether the name is displayed or warned about in that app | Review under the provider's safety or phishing process |
| Social and messaging platforms | Accounts and posts promoting the name | Removal under impersonation or trademark policy |
| Hosts and gateways serving the content | Access to the content through that service | Removal of the identified content from that service |
Order the notifications by reach, not by ease. If customers met the name through a post on one social platform, that platform comes first, because removing the post stops new exposure within that channel. If they met it inside a wallet app, the wallet provider comes first. The registry is always on the list, but it is rarely the fastest lever on the first day.
On the registry: each one publishes its own terms, and what it can or will do about a name already issued differs from one registry to another and from one case to the next. Do not assume the registry can withdraw a name, and do not tell colleagues or customers that it will. Ask, with evidence, and record the answer.
On wallets: resolution of onchain names is partial and varies by app. Take names recorded on Freename: Bitcoin.com Wallet resolves them, MetaMask does so by way of Freename's resolver, and a desktop browser does once the Freename Web3 extension is installed. That coverage changes over time. For your incident, the relevant question is narrower: in which apps did your customers see the name? Notify those. The page on [names that resolve in wallets](/onchain-tld-wallets) describes how that display works, which helps when writing to a provider.
A good platform report has the same five parts whatever the recipient: who you are and your authority to act for the brand; the exact name and where it appears on their service; the right you rely on, such as a registered trademark, with its registration details; what customers have experienced, stated factually; and the specific action you request under the policy you cite. Attach evidence. Leave out threats, deadlines you cannot enforce and anything you would not want published.
## What a response team should not do while the name is live
Most of the damage a response team does to its own position happens in the first day, through actions that feel proactive.
The first two need explanation, because they are the ones executives propose. Contact from an identifiable employee tells the holder that the name has reached you and that you care, which affects every later conversation. It also creates a written record, made in haste, that counsel then has to work around. An offer of money made during an active incident can be read as a response to pressure and invites more of it, from this holder and from others watching.
## Closing the incident and what the review should change
An incident is closed when exposure has stopped, not when the name has disappeared. In many cases the token will remain in the holder's wallet indefinitely. Define closure in terms you control:
- No new customer reports for a period you set in advance.
- Every notified platform has answered, or has been chased and logged as silent.
- The evidence file is complete, stored and access-restricted.
- Customers who reported a loss have a named contact and know what happens next.
- The name has been added to ongoing monitoring.
Then hold a review within two weeks, while people remember. Keep it to an hour and to questions that change something.
How long did it take from the first customer report to the brand protection lead hearing about it? This is usually the longest delay in the whole incident and the cheapest to fix, by giving support a tag and a route.
Did customers know which names are yours? If the honest answer is that you had never published them, the incident has shown you the gap. A page on your own DNS site that states the names you use, and that you use no others, gives support something to point to and gives platforms something to verify against. The [capabilities that work now](/whats-live) are a reasonable guide to which names are worth publishing and which would only confuse.
Did you already know the name existed? If it had been sitting dormant for months, the question is whether you could have seen it. Continuous monitoring of the names that resemble your marks, of the kind described under [namespace watch](/namespace-watch), turns a grade 3 surprise into a grade 1 log entry you had already assessed.
## A one-page runbook to write before the next report
Everything above works better if it has been decided in advance. The concrete next step is a single page, agreed with support, security, legal and communications, and stored where the person on duty will find it.
The page holds seven things: the triage table with your own names in the third column; the location of the incident record template; the approved support script; the internal note with blanks; the contact route for abuse or safety reports at each platform your customers use, checked and current; the name of the lawyer who decides on formal evidence capture; and the published page that states your real names.
Then test it. Take a harmless hypothetical, a name such as `support.yourbrand` appearing in a customer message, and walk the page through with the people named on it. Half an hour is enough to find the missing contact, the script line legal will not approve and the colleague who did not know they were on the page.
If you do not yet know how exposed your marks are, the [Namespace Exposure Score](/namespace-exposure-score) gives a first structured reading, and the overview for [general counsel and brand protection teams](/brands-and-legal-teams) sets out the wider questions.
One part of this sits with Hush Partners. Where a review concludes that a TLD should be acquired and not merely watched, we find and approach its holder under mandate, with a mutual NDA over every exchange. That work is described under [brand namespace recovery](/brand-namespace-recovery). It belongs after an incident is closed, and it is not a substitute for any step of the response. A question about a specific situation can be sent through the [contact form](/contact).
## Questions people ask
### Should we register the similar names ourselves so that nobody else can?
Defensive registration has a place, but it cannot be complete: the number of possible variations across suffixes and naming systems is too large to cover. Most teams do better registering the few names they will actually publish, monitoring the rest, and keeping a tested response procedure for what monitoring finds.
### Does our cyber or crime insurance cover losses from a lookalike name?
It depends entirely on the policy wording, and on whether the loss is yours or your customer's. Many policies require prompt notification of circumstances that might lead to a claim. Ask your broker or counsel on the first day of a grade 3 or grade 4 incident, not at the end.
### Do we have to notify a regulator?
Notification duties generally attach to events such as a breach of personal data you hold or a failure of a regulated service, and a third party imitating your name is not, by itself, either of those. The rules differ by country and by sector, and regulated firms may have reporting expectations of their own. Counsel decides, and the decision goes into the incident record with its reasoning.