Was My Domain Transferred Without My Permission?

How to confirm whether a domain actually changed hands, what to do in the first hour, and why the registrar field in the public record is the fact that settles it.

September 9, 20266 min readTransfers · Security · Registrars

Domain hijacking is rare, and when it happens it is expensive in a way few other account compromises are. Your website goes somewhere else. Your email stops arriving, or worse, arrives to someone else. Password resets for every service tied to that domain start flowing to an address you no longer control.

The first problem is usually not knowing. People discover it from a customer, days later.

This guide covers how to confirm it, what to do first, and how to make sure you find out early next time.

Confirm it from the public record, not from your account

Start with the fact that settles the question: the registrar of record.

Every domain's registry record names the registrar currently sponsoring it. If that name is not the company you bought the domain from, the domain moved. It does not matter what your old registrar's control panel shows, because once a transfer completes, the domain leaves that account and the panel may simply show nothing.

Look up the domain and check three fields:

  • Registrar. Different from the one you expect? The domain was transferred.
  • Updated date, or last changed. A recent timestamp on a domain you have not touched is a signal in itself.
  • Nameservers. Changed nameservers with the same registrar is a different, less severe event: someone got into your account but did not move the domain.

That distinction matters for what you do next.

What you seeWhat happenedWhere the problem is
Registrar changedAn inter-registrar transfer completedBoth registrars, and your email or account security
Nameservers changed, registrar unchangedDNS was redirected from inside your accountYour registrar account
Registrant contact changed, registrar unchangedOwnership record altered in placeYour registrar account
Nothing changedThe problem is elsewhere, likely hosting or DNS at your providerYour host

What actually happens in a hijack

Understanding the sequence tells you where to cut it off.

A transfer requires two things: the domain must be unlocked, and the attacker must obtain the authorization code. Both are usually available to anyone who controls the email address on the account, because that is where account recovery and the auth code are sent.

So a domain hijack is almost always an email compromise first. The domain is the second step, not the first. This is why the single most effective protection is not a domain setting at all: it is that the email address on your registrar account should be one that does not depend on the domain it protects, and should have its own strong authentication.

Once a valid request is submitted, your losing registrar has a limited window to act, and if nobody responds, the transfer completes automatically. That policy exists to stop registrars trapping domains, but it also means silence works in an attacker's favour. A notification email that lands in spam while you are away is all the cover a transfer needs.

The first hour

Move quickly. Recovery gets harder the longer the domain sits with the new registrar, and much harder if it is sold on to a third party who may claim to have bought in good faith.

  1. Secure the email account first. If you skip this, everything else you fix can be undone. Change the password, revoke sessions, check forwarding rules and recovery addresses, enable two-factor authentication.
  2. Contact your original registrar. They have transfer logs, they know which registrar it went to, and their abuse or security team is the correct entry point. Use a phone number if they publish one.
  3. Contact the gaining registrar. Their abuse contact is published in the domain's own registry record, so you can find it even if their website is unhelpful. State plainly that the transfer was unauthorised and ask them to freeze the domain pending investigation.
  4. Write everything down. Timestamps, screenshots of the record before and after, every message. If this becomes a formal dispute, contemporaneous evidence is what carries it.
  5. Escalate to ICANN if either registrar is unresponsive. ICANN operates a public complaint process for transfer problems, and there is a formal Transfer Dispute Resolution Policy, though that mechanism runs between registrars rather than being something you file personally.

If the domain is commercially significant, involve a lawyer early rather than after the informal route fails. Recovery routes that exist on day one narrow considerably by week three.

Why you probably will not read this on a registrar's website

Registrars publish excellent guides on how to transfer a domain to them. They publish very little on how to tell whether one left without permission, and the reason is structural rather than sinister: the gaining registrar in a hijack is a customer-facing business that processed a request which looked valid, and the losing registrar is explaining a failure. Neither has an incentive to write the page.

The information is all public regardless. The registrar of record, the abuse contact, the status codes and the last-changed date are published by the registry for every domain, and reading them yourself does not require anyone's cooperation.

Making sure you find out in hours, not weeks

Everything above is easier if you catch it early, and catching it early is a monitoring problem rather than a security one.

The two signals that matter:

  • The registrar field changing. This is unambiguous. A domain does not change registrar by accident, and if you did not initiate it, something is wrong.
  • Nameservers changing. Less conclusive, since legitimate migrations do this too, but on a domain you have not touched it is the earliest visible sign that someone has access.

Domain Hub watches both on every domain you add. A registrar change is recorded as a critical event with the previous value beside the new one, so the record shows what it was and what it became rather than only that something happened. Nameserver changes are recorded separately from ordinary DNS edits, because they mean something different.

Worth monitoring domains you do not own, too. A registrar change on a name you are tracking tells you it sold or moved, which is useful information for entirely non-adversarial reasons.

Prevention that is worth the effort

  • Leave clientTransferProhibited on. It is the default at most registrars and it is the single most effective barrier. Turn it off only for the hours you are actually transferring. Our guide to why transfers get blocked explains the codes.
  • Use an account email that does not depend on the domain. If your registrar login is [email protected] and the domain is taken, you lose your recovery path at the same moment you need it.
  • Two-factor authentication on the registrar account and on that email. Both, not one.
  • Registry lock for anything valuable. For a domain your business genuinely depends on, a registry-level lock adds out-of-band verification before anything can change. It is deliberately inconvenient, which is the point.
  • Keep the contact details current. A transfer notice sent to an address you abandoned two years ago is a notice you never received.

The uncomfortable truth is that the automatic-approval rule means a domain can move while you are on holiday, and the record is the only place that says so. Reading it takes seconds, and knowing within a day instead of a fortnight is most of the difference between an annoying week and a permanent loss.

Put the research to work.

Check your shortlist across the extensions that matter, then save the strongest names to a project.

Check a domain

ImprintPrivacy