Domain Lock, Explained: The One Setting That Stops Unauthorised Transfers

A registrar dashboard shows a domain's status as a short, technical-looking string of words — clientTransferProhibited being one of the most common — and most owners scroll straight past it without a second thought. That string is actually one of the more useful protections a domain owner has, and understanding what it does takes about two minutes. Anyone who has recently read about a domain being stolen, or who has simply noticed a “Domain Lock” toggle sitting in their account and wondered what happens if they touch it, is really asking the same underlying question: what is this setting actually for, and is it safe to leave alone?

What “domain lock” actually is

Domain lock — also called registrar lock or transfer lock — is a status a registrar sets on a domain that blocks it from being transferred to a different registrar until someone deliberately switches that status off. The technical name for it, visible in most registrar dashboards and in a domain's public WHOIS record, is clientTransferProhibited: an EPP status code (EPP is the protocol registrars use to talk to domain registries) meaning the registrar applied the lock at the account holder's request, rather than the central registry restricting the domain for some other reason.

It's worth being precise about what the lock actually blocks, because it's easy to assume it does more than it does. Domain lock only affects outbound transfer requests — an attempt to move the domain to another registrar. It has no effect on renewing the domain, updating its nameservers or DNS records, changing contact details, or running a website or email on it through the current registrar account. A locked domain works exactly the same as an unlocked one for every normal task; the only door it closes is the transfer-out door.

How domain hijacking actually happens

Losing a domain to an unauthorised transfer sounds like it should require serious technical skill, but in practice almost every real case comes down to one of three much more ordinary things. Understanding which one actually matters most — the compromised account, not the domain's own code or the registry's systems — is what makes it clear why a setting as simple as domain lock closes off so much of the real risk.

• A compromised registrar account. This is the most common path, and it usually traces back to a compromised or reused email address rather than the registrar's own systems being broken into. If an attacker can read or reset the email tied to a registrar account, they can usually reset the account's password too, and from there unlock and transfer a domain like any legitimate owner would.
• Social engineering. An attacker impersonates the domain owner convincingly enough — over a phone call, a support ticket, or a forged document — to talk a registrar's support team, or the owner themselves, into unlocking a domain or approving a transfer that was never actually requested. Fake domain renewal emails are one well-documented version of this trick, designed to get an owner to unlock a domain or hand over login details without realising what they've actually done; that pattern is covered in our guide to spotting fake domain renewal scam emails.
• A domain caught unlocked. Sometimes it's simpler still — a domain left unlocked after a previous transfer, an overlooked reminder to re-lock it, or a moment of forgetting, right when a transfer request happens to come through, legitimate or not.

None of these three paths involves anyone breaking into the domain registry system itself, which is exactly why domain lock — a setting entirely within an owner's control — is such an effective defence against all three.

Why domain lock should almost always stay switched on

Given that domain lock has no downside, the sensible default is simple: leave it switched on permanently, and only turn it off for the few minutes a genuine transfer actually needs.

There's no cost to keeping it on — a locked domain renews normally, its DNS and email keep working without interruption, and nothing about running a website changes. The only situation lock ever gets in the way of is precisely the one it's meant to get in the way of: someone, including an attacker, trying to move the domain to a different registrar without going through the proper unlock step first.

The one moment you need to turn it off

The single legitimate reason to switch domain lock off is transferring the domain to a different registrar on purpose. The general sequence looks similar across most registrars: log into the current registrar's account directly, find the domain's status or transfer settings, switch the lock off, and request the transfer authorisation code — often called an EPP code or auth code — that the new registrar will ask for to start the move.

That unlock window should stay as short as possible. Unlock it, retrieve the code, start the transfer at the new registrar promptly, and treat the domain as more exposed than usual for however long it takes to complete. Most registrars automatically re-lock a domain once a transfer finishes, but it's worth logging in afterwards to confirm the new registrar shows the lock switched back on rather than assuming it happened.

Domain lock doesn't help if the account itself is compromised

It's important to be clear about what domain lock can't do, because relying on it alone creates a false sense of security. Domain lock is a setting on the domain, not on the account — anyone already logged into the registrar account, legitimately or otherwise, can simply switch the lock off themselves before attempting a transfer. It cannot stop someone who already has the keys to the account from turning it off.

That's why the account's own security matters more than the lock setting itself. The email address a registrar account is tied to is effectively the master key: whoever controls that inbox can usually reset the account password and get in. Keeping that email account secure with a strong, unique password, and turning on two-factor authentication wherever the registrar or the email provider offers it, does more to prevent hijacking than the lock setting alone ever could — the two protections work together, not as substitutes for each other.

Domain lock vs the other settings it gets confused with

Domain lock is often mentioned in the same breath as a handful of other domain settings, which makes it easy to assume one covers for another. Each actually protects against a different risk.

None of these four substitute for each other, which is why a well-protected domain normally has all of them switched on at once rather than treating any single one as sufficient on its own. Think of them as covering four separate doors: one for an unauthorised transfer, one for public exposure of personal details, one for a guessed password, and one for a forgotten renewal date — closing three of the four still leaves the fourth wide open.

How to check and change your domain's lock status

The exact screen differs by registrar, but the pattern is consistent: log into the registrar account directly (never through a link in an email), open the specific domain's management page, and look for a status field or a toggle labelled "Transfer Lock" or "Domain Lock." If the status field instead shows a raw EPP code, clientTransferProhibited means it's locked and clientTransferProhibited absent (or a status like "Active" with no lock code shown) means it isn't. A public WHOIS lookup on the domain shows the same status without needing to log in at all, which is a quick way to confirm the setting from outside the account if there's ever doubt about what the dashboard is showing.

What happens if you try to transfer a locked domain

A transfer request submitted against a locked domain is rejected immediately at the losing registrar, before an authorisation code is even generated in most systems — this is domain lock doing exactly its job, not a fault to troubleshoot. The fix is simply to unlock the domain first, then request the transfer again; our guide to transferring a domain to a new registrar walks through the full sequence, including the other things worth checking before starting. There's no need to contact support about a rejected transfer caused by lock status alone — it will succeed as soon as the domain is unlocked.

This is also why a genuine transfer can feel slower than expected if the lock status isn't checked first: a rejected attempt has to be corrected and resubmitted rather than automatically retried, so confirming the domain shows unlocked before requesting the authorisation code saves a round trip.

A short checklist

None of this requires any technical background to act on:

• Check the domain's current status and confirm it shows locked (clientTransferProhibited) right now, not just at some point in the past.
• Use a strong, unique password for the registrar account — never one reused from another site.
• Turn on two-factor authentication on the registrar account, and on the email account it's tied to, wherever either offers it.
• Treat the account's email address as the real security boundary, since whoever controls it can usually reset everything else.
• Only unlock a domain immediately before a genuine transfer, and confirm it's locked again once that transfer has actually completed.

Common mistakes

• Unlocking a domain "just in case" before it's actually needed. Every extra day unlocked is an extra day exposed to a transfer attempt with no benefit to show for it.
• Assuming domain lock protects against expiry. It only blocks transfers; a locked domain still lapses on schedule if a renewal payment fails.
• Treating lock as a substitute for account security. Anyone already logged into the account can switch it off, so a weak password or no two-factor authentication undermines it entirely.
• Unlocking a domain because an email asked for it. A request to unlock, arriving by email rather than initiated by the owner inside the account, is a known social-engineering pattern.
• Forgetting to confirm re-lock after a transfer. Not every registrar re-locks automatically; check the new registrar's dashboard rather than assuming.
• Confusing domain lock with WHOIS privacy. The two solve unrelated problems and neither covers for the other.

Where Gotka Technologies fits

Domain lock is included as standard with every domain registered through Gotka's domain registration service, alongside free transfer in and WHOIS privacy protection, from RM10 a year — so the protection described above is active from the moment a domain is registered, without needing to request it separately. Recognising a fake renewal or transfer-related scam email in the first place, often the first step toward getting a domain unlocked under false pretences, is covered in our related guide on spotting fake domain renewal scam emails.

Key terms used in this guide

• Domain lock: a registrar-level status that blocks a domain from being transferred to another registrar until switched off.
• clientTransferProhibited: the technical EPP status code shown when domain lock is active, set by the registrar at the owner's request.
• EPP: the protocol registrars use to communicate with domain registries; EPP status codes describe a domain's current restrictions.
• WHOIS: the public record of a domain's registration details, which privacy protection can mask but domain lock has no effect on.
• Social engineering: tricking a person or support team into taking an action, such as unlocking a domain, through deception rather than a technical exploit.
• Two-factor authentication: a login step beyond a password, such as a code from an app, that stops account access with a stolen password alone.
• Registrar account: the login through which a domain's settings, including lock status, are managed; its own security matters more than any single domain-level setting.