Typosquatting.ai
THE BASICS

How to Protect Your Domain From Impersonation and Hijacking

Protecting a name is four different jobs that are frequently sold as one product, and the product most people buy first does the smallest of them. Illustrative lookalikes in this guide use the reserved .test ending, so that no real registration is named.

by Andrew Maged16 September 2026updated 23 September 202610 min read

Protecting a domain from impersonation means securing the names you hold, registering the few variants whose absence would cost you, monitoring the rest, and having a response ready for the day a lookalike turns out to be real.

This guide covers the four parts of domain protection, what the registrar add-on does and does not do, a checklist for securing the names you hold, what monitoring covers, how mail impersonation differs, how a response is organised, and which risks none of it addresses.

Four jobs, not one

Domain protection is used loosely enough that two people can agree on the phrase and mean different things. In practice it covers four jobs that are bought separately, run by different people, and fail in different ways.

Own
Registering the names whose absence would cost you: the endings your customers assume, the typos closest to your name, the names you print on physical material.
Secure
Protecting the names you already hold, which is registrar-level work: registry locks, two-factor authentication on the registrar account, renewal governance, and control of the nameservers.
Watch
Monitoring the names you did not register, so you learn early which ones exist and what they are carrying.
Respond
Deciding what happens when a finding is real, from confirming it is not yours through to a report or a formal dispute.

Is the registrar's domain protection add-on enough?

Search for domain protection and most of the first page is registrars selling an add-on by that name. The bundle varies but usually contains three things: privacy, so that your contact details are withheld from the public registration record; a transfer lock, so that the name cannot be moved to another registrar without an extra step; and some form of verification, so that a change to the registration or the nameservers needs a code or a call before it goes through. Some bundles add a period after expiry in which the name is held for you rather than released.

Those are worth having, and several of them are now the default rather than an extra. Registrant contact details are commonly redacted in the public record whether or not you pay for privacy. ICANN's transfer policy already requires a registrar to impose a 60-day inter-registrar transfer lock after a change of registrant, and a registrar may deny a transfer requested within 60 days of the creation date. The lock the add-on sets is the registrar-level status clientTransferProhibited, which tells the registry to reject requests to transfer the domain to another registrar.

What the add-on does nothing about is every name you do not own. It cannot see example-login.test, exmaple.test or example.net, and it will not tell you when one of them acquires a certificate and a mail server. Impersonation rarely starts with your name being taken from you. It starts with a name near yours being taken by somebody else, and no registrar product addresses that, because the registrar of that name is not yours.

Owning is the smallest part of the problem

Defensive registration is where most budgets start and where they deliver the least per pound after the first handful of names. One six-letter domain generates around 3,001 plausible candidates under about twenty pattern families, and the keyword families that dominate that space are effectively unbounded.

That does not make registration worthless. It makes it a short, deliberate list rather than a programme: the endings a customer would guess, the one or two typos nearest your name on a keyboard, and anything a machine resolves without a human reading it. Buy those, and stop. The defensive registration guide in this cluster works through the arithmetic.

Securing what you hold: the checklist

The most damaging domain incidents are not lookalikes at all. They are losing control of the real name: a registrar account compromised, a renewal missed, a nameserver changed by somebody who should not have been able to change it. This work is unglamorous and costs little, and an organisation that has not done it is paying for lookalike monitoring while the front door is unlocked.

  1. Registrar lock on every name that matters. This sets the client status codes that tell the registry to reject transfer, update and delete requests. It is set by the registrar and can be removed by anyone who controls the registrar account, which is its limit.
  2. Registry lock on the names you cannot afford to lose. This is a separate service, set by the registry rather than the registrar, and it applies server-level status codes that take precedence over the registrar's. At Verisign, for example, an unlock requires an authorised person at the registrar to submit a request and then give an individual security phrase to Verisign over the phone. A compromised registrar account is not enough.
  3. Multi-factor authentication on the registrar account, with hardware keys where the registrar supports them, and a short list of named people who hold access.
  4. A role mailbox as the registrant and administrative contact, owned by the organisation and monitored, so that renewal and transfer notices do not go to somebody who left.
  5. DNSSEC on the zones that matter. DNSSEC provides origin authentication of DNS data, so a validating resolver can tell that an answer for your name was signed by you and not substituted on the way.
  6. Nameserver change control: a written record of who can change nameservers and DNS records, and an alert when they change. Most hijacks become visible first as a nameserver change.
  7. Expiry alerts of your own. ICANN's expired registration policy requires registrars to send at least two renewal notices, one approximately a month and one approximately a week before expiry, but those go to the contact on file, which is why the role mailbox matters. Add a calendar of your own and auto-renew against a payment method that outlives any individual.
  8. Transfer lock awareness. A change of registrant triggers a 60-day transfer lock under ICANN policy. Plan registrar moves around it rather than discovering it during one.

Watching covers what you cannot buy

Monitoring is what addresses the part of the space registration cannot reach. It turns the question from which names could exist into which names now do, and it attaches the evidence that lets you sort them: registration age, the registrar, whether anything resolves, whether mail is configured, whether a certificate has been issued.

The useful output is small. After the first pass settles which findings are your own, later runs are read as a difference: what is new, what changed priority, what disappeared. The alert threshold should sit where you will believe it, limited to new findings above a priority you chose, with a record of what the rules withheld.

A checker of the kind this site runs reads those public records without connecting to the suspect site: registry RDAP, DNS over HTTPS, certificate transparency logs and passive urlscan.io search. On the Pro plan the candidates are re-checked daily and the certificate logs are searched every 30 minutes.

Mail impersonation is a separate job with the same name

Much of what is called domain impersonation is mail. A message arrives with your name in the From line, and the domain in the address is either yours and spoofed, or a lookalike of yours. The first case is addressed by mail authentication on your own domain: SPF lists the servers allowed to send as you, DKIM signs what they send, and DMARC tells receivers what to do when neither checks out and sends you reports about who tried. The UK National Cyber Security Centre puts it plainly: setting up DMARC stops phishers from spoofing your domain, that is, making their emails look like they come from your organisation.

The second case is the lookalike, and no record on your domain touches it, because the message is authenticated for the domain it actually came from. That is the case monitoring exists for. Publish the records on the names you own, including the defensive ones that send nothing, and watch the names you do not.

Responding is where the value is realised

Detection without a response is a list. The decisions worth making in advance are who confirms a finding is not yours, who preserves the evidence, who contacts the registrar or hosting provider, and who decides whether a formal dispute is worth its cost and delay.

Most findings stop at the first step. The ones that do not divide into two routes with different standards of proof: an abuse report, which is operational and asks a provider to act on what a name is doing now, and a dispute, which is legal and argues about the registrant's rights and intent. The abuse report is faster and costs nothing but time. The dispute can transfer the name to you, which the report cannot.

What none of it covers

Domain protection does not address impersonation that uses no domain at all: a display name in an email client, a social media account, a paid search advertisement, or an application in a store. Those need their own monitoring and their own reporting routes.

It also does not make a similar name illegitimate. Short words collide across industries and countries, and an unrelated business may hold a name that looks like yours with an equal claim to it. Evidence establishes what a name is doing. It does not establish who deserves it.

Where to start

The order matters less than starting, but a reasonable sequence is to inventory what you own, secure the registrar account and lock the names that matter, run a check on the primary name and settle which findings are your own, register the short list, put the rest on a daily re-check, and write down the response before you need it. The practical domain protection checklist in the blog walks through each of those steps with the questions to ask at each one.

Common questions

What is the difference between domain privacy and domain protection?
Domain privacy withholds your contact details from the public registration record, and most registries now redact them anyway. Domain protection, as registrars sell it, adds a transfer lock and verification on changes. Neither does anything about names you do not own.
Does an SSL certificate protect my domain from impersonation?
No. A certificate proves that the site you reached controls the name in the address bar. Anyone can obtain a certificate for a lookalike name they registered, and most impersonation sites have one. The padlock says the connection is encrypted, not that the name is yours.
Is domain protection worth paying for?
The registrar add-on is cheap and worth having if it adds a lock and verification you would not otherwise set. The larger value is in work that costs little: registry lock, multi-factor authentication, a role mailbox and DNSSEC. Paying for lookalike monitoring makes sense once those are done.
What is the difference between registrar lock and registry lock?
A registrar lock is a client status set by your registrar and removable by anyone who controls your registrar account. A registry lock is set by the registry itself, takes precedence over the registrar's codes, and at Verisign needs a phone call and a security phrase to lift.
How do I stop someone spoofing my email domain?
Publish SPF, DKIM and DMARC on your domain, move DMARC to a reject policy once the reports show your legitimate senders are covered, and publish records that refuse mail on every domain you own that does not send. Lookalike domains need monitoring, because your records do not apply to them.

Sources and further reading

  1. ICANN: EPP status codes
  2. ICANN: Transfer Policy
  3. Verisign: Registry Lock service
  4. ICANN: Expired Registration Recovery Policy
  5. RFC 9364: DNS Security Extensions (DNSSEC)
  6. UK National Cyber Security Centre: Phishing attacks: defending your organisation
  7. ICANN: Launching RDAP; Sunsetting WHOIS
  8. Typosquatting.ai: methodology and data sources

Keep reading in Domain protection