Registry Lock vs Transfer Lock: Domain Security

When people think about website security, they usually jump straight to SSL certificates, WAF rules or hardened servers. But one critical control point is easy to overlook: your domain name. If someone takes control of your domain, they may be able to change its DNS delegation, hijack email delivery and redirect visitors to phishing pages, even while your real infrastructure remains secure. That is why strong domain security is just as critical as VPS firewalls or application hardening. In this guide, we’ll go deep into registry lock, transfer lock and practical protections against unauthorized changes. We’ll explain what each lock really does at the protocol level, how to check its EPP statuses in RDAP or WHOIS data, and how to combine them with operational best practices so that both your marketing team and your security team can sleep well. The focus is protecting domain control independently of the infrastructure behind it: hosting, VPS, dedicated servers or colocation.

Why Your Domain Can Be a Single Point of Failure

Your domain is the front door key to everything that sits behind it: web servers, email, APIs, admin panels, even VPN or remote desktop endpoints. A strong VPS firewall still protects the server, but it cannot stop an attacker with domain control from redirecting visitors to a different IP.

Consider a team that invests in SSL/TLS, backups and WAF rules but leaves its registrar account with a weak password, no 2FA and no locks enabled. If a phishing email succeeds in compromising that account, an attacker may be able to:

• Change nameservers to redirect web traffic to a malicious server.
• Modify MX records, if DNS access is also compromised, to intercept incoming email, potentially including password resets.
• Transfer the domain to a different registrar, making recovery more difficult.

If you want a broader overview of the whole picture (DNSSEC, WHOIS privacy and account 2FA), you can also read our article Domain Security Best Practices: Registrar Lock, DNSSEC, Whois Privacy and 2FA. In this post, we’ll zoom in specifically on registry lock, transfer lock and preventing unauthorized changes to DNS and contact data.

Understanding Domain Statuses: Where Locks Actually Live

To understand registry lock and transfer lock properly, it helps to know how domains are represented at the protocol level. Almost all generic TLDs (like .com, .net, .org) and many new gTLDs use the EPP (Extensible Provisioning Protocol) between registrars and registries. In EPP, every domain has one or more statuses that control what operations are allowed.

Security-related prohibitions use two prefixes:

• Client-side statuses (prefixed with client): Set by your registrar. Example: clientTransferProhibited.
• Server-side statuses (prefixed with server): Set by the registry directly (the operator of the TLD). Example: serverTransferProhibited.

Common security-related EPP statuses you can check through RDAP, WHOIS where available, or registrar panels include:

• clientTransferProhibited – transfer lock at registrar level (usually called Registrar Lock or Transfer Lock).
• serverTransferProhibited – transfer block at registry level (may be part of a registry lock service).
• clientUpdateProhibited – prevents updates to the domain by client (registrar).
• serverUpdateProhibited – prevents updates at registry level.
• clientDeleteProhibited / serverDeleteProhibited – block deletion of the domain.

When you see both client and server variants together (for example clientTransferProhibited and serverTransferProhibited), it effectively means both your registrar and the registry itself are refusing to allow that operation. These flags describe restrictions; they do not by themselves confirm enrollment in a registry lock service or its verification procedures.

What Is Transfer Lock (Registrar Lock) and How Does It Work?

The Basics

Transfer lock – often called Registrar Lock – is the most common domain security setting. At the EPP level, this is usually the status clientTransferProhibited. It is controlled by the registrar and is often exposed in control panels as a simple on/off toggle like “Domain lock: Enabled”.

When transfer lock is enabled:

• Your domain cannot be transferred to another registrar using a standard EPP code (AuthInfo/EPP key).
• Any transfer request will be rejected while the status remains active.

When transfer lock is disabled:

• The domain may become transferable to another registrar if no other transfer restrictions apply and the applicable authorization and transfer-policy requirements are met.
• Attackers who have gained access to your registrar account may be able to unlock it and initiate an unauthorized transfer.

We explain the transfer flow and EPP code details step-by-step in our article How to Transfer a Domain Without Downtime: EPP Code, Transfer Lock, and a Smooth Migration Plan. Here, the key takeaway is simple: transfer lock should be enabled by default, always, and only disabled briefly for planned, authorized transfers.

Checking Transfer Lock in RDAP or WHOIS

Check your domain’s registration-data status using RDAP for gTLDs, or WHOIS where available. A WHOIS response for a domain with a registrar transfer lock may contain a line similar to:

Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited

If this status is missing, do not assume the domain is transferable: a registry-side prohibition or other restriction may still apply. Review the lock settings with your registrar and enable the available registrar transfer lock unless you are preparing an authorized transfer.

What Transfer Lock Does Not Protect Against

Transfer lock is powerful, but limited. It usually does not prevent:

• Changes to nameservers (NS records) at the registrar level.
• Changes to DNS records if you’re using the registrar’s DNS service.
• Changes to contact information (registrant/admin email, address, etc.).
• Deletion of the domain (unless delete-prohibited flags are set separately).

That means a transfer lock alone does not stop an attacker with registrar access—and DNS panel access where needed—from attempting to:

• Point your nameservers to their own DNS.
• Modify A, MX, TXT and other records if they have DNS panel access.
• Change contact email to take over future verification and reset flows.

To protect against these scenarios, you need more than just a transfer lock.

What Is Registry Lock and Why It’s Much Harder to Bypass

Registry vs Registrar: Who Holds the Keys?

A registry lock adds protection at the registry (TLD operator) level, rather than relying only on registrar controls. Availability and procedures vary by registry and registrar. These services can:

• Set one or more server-side EPP statuses, such as serverTransferProhibited, serverUpdateProhibited and serverDeleteProhibited.
• Require out-of-band, high-assurance procedures to change or remove (manual verification, security tokens, phone callbacks, pre-approved contacts, etc.).

While a registrar lock can be toggled from your control panel, a registry lock usually cannot be changed by simply logging into the account. That’s the main security benefit: operations covered by the lock should require the registry’s additional unlock process, rather than registrar login credentials alone. The protection depends on which operations are locked and how that process is secured.

Typical Operations Blocked by Registry Lock

A well-configured registry lock often protects against:

• Unauthorized transfers – a server-side transfer prohibition blocks registrar transfers; a client-side prohibition may also be set.
• Unauthorized DNS changes at the registry level – nameserver updates can be blocked. This does not lock A, MX or other records in the existing DNS provider’s zone.
• Unauthorized deletions – serverDeleteProhibited blocks delete operations.
• Sometimes contact changes or other updates may require manual approval as well.

For high-value domains (brand primary .com, key ccTLDs, critical SaaS platform domains), evaluate registry lock based on the impact of compromise, availability and the approval process for changes.

How Registry Lock Appears in Registration Data

Check registration data through RDAP, or WHOIS where available. Registry-lock restrictions are represented by server-side statuses; the EPP names below may be displayed with spaces in RDAP tools:

• serverTransferProhibited
• serverUpdateProhibited
• serverDeleteProhibited

You may also see the client-side equivalents, indicating restrictions at both registrar and registry levels. These statuses restrict the corresponding operations, not just unauthorized requests. Confirm registry-lock enrollment and its unlock procedure with your registrar; statuses alone do not establish the approval process.

When Is Registry Lock Overkill?

Registry lock usually comes with additional cost and operational friction. You typically need to:

• Submit change requests through verified contacts or support channels.
• Wait for manual approval for updates that would otherwise be one-click.

For secondary project domains, test environments, or marketing campaign domains that need frequent registry-level updates, this can slow your team down. Editing records within an existing DNS zone is distinct from changing the registry’s nameserver delegation. We generally recommend:

• Use transfer lock + strong operational security for normal domains.
• Reserve registry lock for domains where a compromise would have serious financial, legal or brand impact.

Preventing Unauthorized DNS and Contact Changes

Even with transfer and registry locks, protect the registrar account, DNS-provider accounts and connected email inboxes. Think of your domain management like root access on a production server: tightly controlled, monitored and audited.

1. Harden Your Registrar Account

At a minimum, you should:

• Use a strong, unique password generated by a password manager.
• Enable 2FA (preferably TOTP or hardware keys, not just SMS if you can avoid it).
• Restrict login email to a well-protected mailbox, ideally on an internal or hardened domain.
• Audit authorized users and remove old or unused logins regularly.

Password reuse and weak account protections create avoidable risks. Keep registrar credentials unique, protect the devices and browser profiles that can access them, and require 2FA.

2. Protect the Email Addresses That Control Your Domain

Email inboxes may receive password-reset links, change confirmations and security alerts. Review which addresses your registrar uses and what additional approvals it requires. Depending on those controls, an attacker who hijacks the mailbox used for your registrar login or registrant contact may be able to:

• Reset your registrar password.
• Approve transfers or contact changes without touching your actual infrastructure.

Make sure these inboxes:

• Use strong passwords and 2FA.
• Are hosted on a platform you control and understand.
• Use a domain with properly configured SPF, DKIM and DMARC to help receivers identify unauthorized use of that domain in email. These controls do not secure mailbox logins or stop all phishing. (If you need a refresher, see our guide SPF, DKIM and DMARC Explained for cPanel and VPS Email.)

3. Restrict Who Can Touch Domains and DNS

In many organizations, “whoever handles websites” has full access to domains, DNS, hosting and email. That might be one person today and completely different a year from now. From a security perspective, that’s too much power in too many hands.

Instead, aim for:

• Clear separation between people who manage domains / DNS and people who manage application code.
• Per-user logins instead of shared credentials; choose management interfaces that support individual access and appropriate permissions.
• Documented change workflows: who can request, approve and implement DNS or domain changes.

If you’re an agency managing many client domains, we also recommend reading DNS and Domain Access Management for Agencies for a more structured way to assign permissions and avoid risky shared accounts.

4. Monitor Domain Status and DNS Changes

You can’t react to attacks you don’t see. For critical domains, set up:

• Domain status monitoring: periodic RDAP checks, or WHOIS where available, to detect changes to lock-related statuses.
• DNS monitoring: detect unexpected changes to NS, A, MX, TXT or CNAME records.
• Uptime monitoring: availability checks can alert you if a DNS change makes the monitored service unavailable, but may miss redirection to a working unauthorized endpoint. Our guide Website Uptime Monitoring and Alerting Guide for Small Businesses covers practical options.

For large portfolios, domain monitoring can be integrated into your general infrastructure observability stack, alongside VPS metrics and application logs.

5. Understand What Your DNS Records Actually Do

Unauthorized changes can go unnoticed if nobody recognises that a new TXT or CNAME record is suspicious. Spend time educating your team about common DNS record types and their impact. Our guide DNS Records Explained Like a Friend: A, AAAA, CNAME, MX, TXT, SRV, CAA is a good starting point.

Understanding that MX changes can redirect incoming email, and that CAA records identify certificate authorities authorized to issue certificates for your domain, makes it easier to spot malicious or mistaken changes. CAA changes do not revoke existing certificates.

Putting It Together: A Practical Domain Security Playbook

Let’s turn all of this into a clear, repeatable process you can apply across your domains.

Step 1: Classify Your Domains by Criticality

Not every domain needs the same additional controls. Classify domains by the actual impact of compromise; the examples below are starting points, not fixed assignments:

• Tier 1 – Business critical: primary brand domain, production SaaS domains, main email domain.
• Tier 2 – Important: regional/country versions, key campaign domains, support portals.
• Tier 3 – Low risk: test/staging domains, experimental projects or parked names only where compromise would have limited impact and no sensitive dependencies.

For each tier, define a minimum security level:

• Tier 1: registry lock where supported by the registry and registrar + transfer lock + DNSSEC where supported + 2FA + strict access control + monitoring.
• Tier 2: transfer lock + DNSSEC where supported + 2FA + good operational hygiene.
• Tier 3: transfer lock + unique passwords + 2FA + protected recovery accounts.

Step 2: Enable Locks and DNSSEC

For each domain:

• Verify transfer lock (clientTransferProhibited) is enabled.
• For Tier 1 domains, evaluate and enable registry lock if your registry and registrar support it, with a documented unlock and relock process.
• Enable DNSSEC where your DNS stack supports it, with correctly signed records and a valid chain of trust to the validating resolver’s trusted anchor. For those records, validation can detect forged or altered answers; signing alone does not protect a resolution path that does not validate. DNSSEC does not secure registrar accounts or approve DNS-management changes: a malicious change accepted and signed by the authoritative provider can still validate. If you’re new to DNSSEC, see our practical setup guide What Is DNSSEC and When Should You Enable It?

After registrar or registry changes, check lock-related registration statuses through RDAP, or WHOIS where available; confirm registry-lock enrollment and its unlock procedure with the registrar. Verify DNSSEC separately: query the authoritative parent zone for the published DS record and match its parameters and digest to the child zone’s DNSKEY set. Then use a DNSSEC-validating resolver or diagnostic tool to validate the DS/DNSKEY/RRSIG chain from a trusted anchor to the records you rely on.

A DS entry in a registration lookup, or a DS record by itself, does not prove that validation succeeds. Record the validation result; do not treat an insecure, bogus or indeterminate result as secure. For a domain intended to validate as secure, investigate missing or mismatched DS data, key changes and invalid or expired signatures.

Step 3: Clean Up Access and Credentials

Across your organization (or agency):

• Eliminate shared “info@” logins for domain management where possible.
• Use management tools that support individual accounts with separate permissions per user or team.
• Ensure every account has 2FA enabled and credentials stored in a password manager.
• After staff changes, revoke departed users’ access, rotate credentials they could retain and verify recovery email addresses.

Step 4: Document a Change-Request Workflow

For Tier 1 and Tier 2 domains, define a simple but strict process for:

• Who can request a change (for example, product owner or marketing lead).
• Who must approve the change (for example, technical lead or security owner).
• Who actually implements the change (for example, your designated internal administrator or an authorized service provider).

For critical changes, require approval by someone other than the implementer and restrict access so that the approval cannot simply be bypassed. Recording a request alone does not prevent one person from making an unauthorized change.

Step 5: Test Your Recovery Plan

Assume that at some point, something will go wrong: a compromised account, a social engineering attempt, or a misconfigured DNS change. You should know in advance:

• How quickly you can revert DNS changes or restore previous zone versions.
• Who you contact at your registrar or hosting provider in case of domain compromise.
• How to prove ownership (invoices, company docs, registry contacts) if an attacker has changed contact data.

Combine this with a wider disaster recovery plan that also covers website files, databases and email. If you need to design that broader plan, we recommend our guide How to Design a Backup Strategy: RPO/RTO and Hosting‑Side Best Practices for the backup and restore side.

Common Vulnerabilities and How Locks Help (or Don’t)

Scenario 1: Phishing the Domain Admin

An attacker sends a well-crafted email that looks like a renewal or policy update from the registrar. The domain admin clicks, logs into a fake panel and hands over credentials. The attacker then attempts to log in to the real registrar account; success depends on any additional authentication checks.

What happens next depends on your setup:

• With only transfer lock: attacker may still change nameservers, DNS records and contacts.
• With registry lock: covered transfers, deletions and nameserver updates require removal of the relevant registry restrictions through the registry’s verification process. Confirm the scope and unlock procedure for your TLD and registrar; this does not lock records in your DNS hosting account.
• With account 2FA: a stolen password alone is generally insufficient, but phishing may also capture codes or sessions. Prefer phishing-resistant authentication where supported.

Scenario 2: Compromised Email Account

The mailbox used as registrar login or registrant contact is compromised. The attacker requests a password reset from the registrar. If the registrar’s recovery process allows access using that mailbox alone, the attacker can take over the domain account and attempt to modify records.

Mitigations:

• Use a separate, locked-down mailbox for domain operations, with MFA and protected recovery methods. After a compromise, revoke unauthorized sessions and review recovery settings and forwarding rules.
• Use DMARC to help receivers detect unauthorized use of your domain in the visible From address, and good spam filtering to reduce malicious inbound mail. Neither restores control of an already compromised mailbox.
• Where available, use registry lock for Tier 1 domains and confirm which operations require additional verification. Ensure that verification does not rely solely on the same mailbox.

Scenario 3: Insider or Former Employee

A former contractor or employee still knows the shared registrar password or has their own account left active. They modify DNS or unlock domains as retaliation or by mistake.

Mitigations:

• End shared accounts; move to per-user access with clear offboarding procedures.
• For high-value domains, registry lock plus an enforced internal approval workflow can reduce unilateral changes to covered registry operations; separately restrict access to DNS records.
• Regular audits of access lists and login history.

Integrating Domain Security With Your Hosting Strategy

Domain security and hosting security need coordinated planning, whether you use one provider or several. Your operational plan should aim to:

• Align domain locks and DNSSEC with your actual server and application architecture.
• Coordinate domain/DNS changes with planned server migrations or new deployments.
• Implement consistent access control policies across domains, DNS, hosting panels and VPS servers.

Whether you run a single business website or a portfolio of brands and SaaS products, include these tasks in your domain security review:

• Review the current EPP statuses and lock configuration of your domains.
• Design a realistic classification of critical vs secondary domains.
• Implement DNSSEC and secure nameserver setups, and evaluate registry lock where supported by your TLD and registrar.

Strong domain security isn’t about never changing anything. It’s about making necessary changes while reducing opportunities for attackers and operational mistakes. By combining transfer lock, registry lock, careful access management and clear operational playbooks, you can turn your domains from a silent risk into a quiet, reliable foundation for everything else you build. Start by reviewing the locks and statuses on your key domains and documenting who can authorize changes.