Brand Protection for Domains: A Strategy That Fits
The worst time to decide how you handle a lookalike domain is the morning you find one.
Brand protection for domains is a written set of decisions about which names are in scope, which are worth registering, which are only worth watching, and who does what on the day a finding turns out to be real.
This guide is the hub for the brand protection cluster. It covers setting scope, the register-or-watch decision in summary, the trademark prerequisite for disputes, the categories of tooling, ownership of the response, triage, judging whether the programme works, and what a strategy cannot settle.
Why decide any of this in advance?
The first check an organisation runs against its own name usually returns more than anybody expected. Somebody forwards the list to the security team, the security team asks who owns the third row, nobody knows, and three weeks later the list is still open in a browser tab. The findings were never the hard part. The hard part was that no decision had been written down about what any of them meant or who was supposed to do anything.
A strategy here is four decisions, made when nothing is on fire, that turn a list into work: what is in scope, what you will own, what you will merely watch, and who acts when something is real. It also sets the standard of proof. The most useful sentence in a brand protection programme is the one saying a finding is a name to review under a published rule, not an accusation. Teams that have not agreed that in advance end up either treating every variation as an attack, which exhausts the reviewers, or treating none of them as anything, which is the same as not looking.
What belongs in scope?
Scope is the list of names an attacker could plausibly borrow, which is wider than the list your legal team registered. Write it once and revisit it when the product or the market changes.
A useful test for each candidate is whether a customer, seeing that name in a message, would assume it was you. If the answer is yes, it belongs in scope whether or not you own it.
- The primary domain, and every ending you already operate on.
- Product and service names that customers type or search for independently of the company name.
- Abbreviations and short forms your own customers use, including the ones your marketing team dislikes.
- Words that make a name look official: login, support, account, secure, billing, verify, help.
- The endings customers assume you use, which is rarely the same set as the endings you bought.
- Public hosting platforms, where a project name on somebody else's infrastructure carries your brand.
- Names associated with a campaign, an acquisition or a launch, which attract registrations around the announcement.
- Executive and finance-team names, where they appear in domains used for mail rather than websites.
Register, watch or ignore?
No registration strategy solves this, because the space of confusable names is larger than any budget, and the families that dominate the count are keyword combinations and alternative endings rather than typing mistakes, which are exactly the ones nobody would think to register. The question is which small set is genuinely dangerous, and how you find out about everything else early enough to matter. In short: register the endings customers assume you use and the one or two typos closest on a keyboard, because those are small sets that remove a mistake permanently for the price of a renewal. Inventory the names you already hold first, because a large share of first-check findings turn out to be the organisation's own property.
Watch, rather than buy, the keyword combinations, the hosting platform names and the lookalike character variants, because they are too numerous to own and registering one does nothing about the next. Record and leave the names held by unrelated legitimate businesses, because short words collide across industries and pursuing them costs goodwill. The full decision table, with the reasoning for each row and the cost model behind it, now lives in the defensive domain registration guide in the domain protection section, which is the page to hand to whoever holds the budget.
Do you need a trademark first?
It depends which response you expect to use, and this is worth settling before the first finding. The two dispute routes are built on a mark. A UDRP complaint must show that the name is identical or confusingly similar to a trademark or service mark in which you have rights, that the registrant has no rights or legitimate interests, and that the name was registered and is being used in bad faith, and the only remedies are cancellation or transfer. The faster URS procedure is narrower still: it requires a word mark with a valid national or regional registration that is in current use, the burden of proof is clear and convincing evidence, and the result is suspension for the balance of the registration period rather than transfer. Without a registered mark, neither route is open.
Everything else in this guide works without one. Defensive registration needs a card, not a certificate. Abuse reports to registrars, hosts and blocklists are about conduct, and a registrar will not adjudicate trademark rights in any case. Monitoring needs nothing but a scope list. So a brand without a registered mark can run most of the programme today, and should treat the mark as the item that unlocks the last rung of the ladder, the only rung that ends with the name in your hands.
What categories of tooling exist?
The market is easier to navigate once you see that the products are doing different jobs, and that most organisations need two or three of these rather than one.
Permutation checkers generate candidate names from a seed domain and tell you which of them exist. Their quality depends on the breadth of the pattern families and endings they cover and on whether they resolve the candidates or merely list them. Registration feeds and brand watch services work from the other direction, watching newly registered names for a string you care about; they catch names no permutation engine would have produced, and they generate a great deal of noise for short or common brand strings.
Certificate transparency monitoring watches the public logs for names matching your brand, and is the earliest of the public signals because a certificate is usually issued while a site is being prepared. Passive scanning data, gathered by third parties that visit hosts routinely, tells you what a name looked like when somebody else observed it, without opening it yourself. Managed brand protection services sit on top of all of the above and add analysts and response: evidence packaging, reporting to intermediaries and takedown work, at a service price. Mail authentication reporting is the category teams forget: aggregate DMARC reports from your own records tell you who is sending as you, which is a complementary signal to anything domain-shaped.
Who owns the response?
Most programmes fail here rather than at detection. A finding arrives, it is genuinely concerning, and it stalls because five separate people each need to do something and none of them have been told so. Assign these by role before you need them, and write down who covers each one when that person is away.
- Who confirms whether the name is already yours. This is the first question on almost every finding and it is answered from a registration inventory, not from memory.
- Who preserves the evidence, with timestamps, on the day the finding appears. Registrants change things quickly and nothing here can be recreated later.
- Who writes and sends the report to the hosting provider, the registrar and the blocklists, and who tracks the references that come back. The reporting guide in this cluster has the addresses and a template.
- Who decides whether a dispute is worth its cost. This needs a budget, a registered mark and access to counsel, and it is slower than the others.
- Who tells support, sales and the social accounts, so that the first customer who asks does not get a shrug.
- Who records the disposition, so the same name is not investigated from scratch by somebody else later.
How do you triage a finding?
Triage is about ordering attention, not about deciding guilt, and it works best as a fixed sequence that anybody on the rota can follow identically.
Ask first whether the name is yours, because a meaningful proportion of findings on a first check are the organisation's own defensive registrations. Then ask whether it resolves at all, because a registered name that points nowhere is a different problem from one serving a page. Then look at what is configured: mail records are a considered act rather than a side effect of registration, and a recent certificate means somebody prepared to serve a page over HTTPS. Then look at age, because a name created last week behaves very differently from one that has sat unused for years. Then look at the pattern family, because a keyword combination aimed at a login page is a different proposition from an alternative ending on an unrelated business.
This site's checker orders its rows in exactly that shape, from registry RDAP, DNS over HTTPS, certificate transparency logs and passive urlscan.io search, without ever connecting to a suspect site, and every rule behind every priority label is published on the methodology page. That matters because a reviewer who disagrees with a priority needs to see why it was assigned, and because a report that quotes a published rule is more persuasive than one that quotes a number. Write the disposition down every time, including for the names you decide to leave. The second check then produces a much shorter list, because most of what it finds has already been judged.
How do you tell whether the programme is working?
Resist the temptation to measure this in volume. The number of findings tells you about the generator rather than about your exposure, and a programme optimised for findings will produce them whether or not anything is wrong.
The measures that mean something are structural. Does the scope list still match what the business sells. How long does it take, from a name first appearing in a public record, for somebody here to know about it. What proportion of findings turn out to be your own property, and is that proportion falling as the inventory improves. Does every finding have a recorded disposition, or do some simply stop being mentioned. When a real one arrived, did the response run as written or did it get improvised. And when a finding was reported, did anybody look at the name afterwards to see what changed. Programmes that report and never re-check are measuring their own effort rather than any outcome.
What a strategy cannot settle
A strategy decides what you will do with evidence. It cannot improve the evidence, and the evidence has hard limits. Public records show that a name exists, when it was created, where it points, what certificates exist for it and whether it is configured for mail. They do not show who controls it, what its pages contain, or what anybody intended. Similarity is never proof of intent, and a finding is a name to review under a published rule, not a finding of phishing. Nor is silence reassurance: a candidate set generated from pattern families is not exhaustive, and a registry that returns no record has only declined to answer.
The honest framing for a board is that this is a routine rather than a solution. It reduces the chance that an expensive impersonation runs for weeks before anybody notices, it gives the response somewhere to start, and it produces a dated record that a dispute or a report can be built on. It does not make a brand unimpersonable.
Common questions
- What is brand protection for domains?
- It is the set of decisions and routines that keep lookalike registrations from being used against your customers: deciding which names are in scope, registering a small set, watching the rest, and having a written response for the day one turns out to be real. It is a routine, not a purchase.
- Do I need a registered trademark to protect my brand's domain?
- Not for most of it. Defensive registration, monitoring and abuse reports need no mark. The UDRP and URS dispute routes do: UDRP needs rights in a mark, and URS needs a word mark with a valid national or regional registration in current use.
- Should I register every typo of my domain?
- No. Register the endings customers assume you use and the one or two closest keyboard typos, and watch the rest. Keyword combinations and character variants are too numerous to own, and buying one does nothing about the next.
- Who should own domain brand protection in a company?
- Split it by role rather than by team: one person confirms ownership from the inventory, one preserves evidence, one sends reports, one decides on disputes with a budget and counsel, one tells customer-facing staff, and one records the outcome. Write down the cover for each.
- How often should you check for lookalike domains?
- Often enough that a name appearing in a public record is noticed before customers do. Quarterly suits a one-off assessment; a daily re-check with certificate log monitoring suits an operating brand, with the frequency raised around launches and campaigns.
Sources and further reading
- ICANN: Registration Data Access Protocol (RDAP)
- Public Suffix List
- ICANN: Uniform Domain-Name Dispute-Resolution Policy (the policy text)
- ICANN: UDRP overview
- ICANN: Uniform Rapid Suspension (URS)
- ICANN: URS procedure (redline, 21 February 2024)
- WIPO Arbitration and Mediation Center: domain name disputes
- WIPO: schedule of fees for UDRP cases
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 6962: Certificate Transparency
- ICANN: 2013 Registrar Accreditation Agreement, section 3.18
- UK National Cyber Security Centre: Phishing attacks: defending your organisation
- Typosquatting.ai: methodology and data sources