The “Silent Registrar Lockout”: How Agency-Client Miscommunication Breaks Domain Transfers During Offboarding

Offboarding a digital client should be a clean operational milestone. Deliverables are archived, final invoices are settled, and control of core digital infrastructure (websites, hosting, analytics and primary domain names) is handed back to the client.

One of the most common friction points in these transitions happens quietly, beneath the offboarding workflow. This article calls it the Silent Registrar Lockout.

A Silent Registrar Lockout is not an official industry term. It describes a domain that cannot be moved at the moment an agency or client tries to hand it over. Broken code or missing DNS records are rarely the cause. The usual causes are:

• a registrar-imposed transfer lock that nobody knew about
• registrar account access held by someone who has left
• a contact detail changed at the wrong moment

The result is the same each time: website and email downtime risk, and a strained relationship with a client who is already leaving. This guide explains the mechanisms behind domain locks and gives you a 30-day pre-offboarding checklist to avoid them.

Scope note: ICANN’s Transfer Policy governs generic top-level domains (gTLDs) such as .com, .net and .org. Country-code domains (ccTLDs) such as .uk, .eu or .in follow their own registry rules, so check the relevant registry’s policy before applying anything below to them.

---

What Causes a “Silent Registrar Lockout”?

A registrar-to-registrar transfer looks simple on paper:

1. Unlock the domain.
2. Get the authorization code (also called an Auth code, AuthInfo code or EPP code).
3. Submit it at the receiving registrar.
4. Approve any confirmation requests.

In practice, several independent controls sit in the way. Each is sensible on its own, but they collide when an offboarding is rushed.

                 [ Offboarding begins ]
                           │
        ┌──────────────────┼───────────────────┐
        ▼                  ▼                   ▼
 [1. Registrar lock]  [2. Registrant      [3. Registrar account
  clientTransfer-      details changed?     access: who can log in,
  Prohibited?          (name/org/email)     pass MFA, approve emails?]
        │                  │                   │
  Toggle it off     60-day lock applies   Account held by ex-employee
  (or ask registrar unless you opted out  or dead mailbox = stuck
  to do it within   BEFORE the change
  5 calendar days)

Three catalysts account for most lockouts.

1. The Change of Registrant 60-Day Lock

Under ICANN’s Transfer Policy, a “Change of Registrant” is a material change to the registrant’s name, organization or email address. A material change is anything that is not a typographical correction.

When one happens, the registrar must impose a 60-day inter-registrar transfer lock. The only exception is a registrar that offers an opt-out, and the registrant must use it before the change request.

• The mistake: Three days before offboarding, an agency “cleans up” the registrant record. It swaps [e-mail] for [e-mail], intending to help. That is a material change to the email address.
• The result: The domain cannot move to another registrar for 60 days, unless the registrar offers an opt-out that was used beforehand. ICANN itself does not place or lift an individual domain’s lock. Some registrars add their own rules for removing the lock, such as extra email confirmation or a waiting period, so ask yours exactly how it handles this.

Two clarifications prevent misdiagnosis:

• The lock is imposed by the registrar, not the registry. ICANN’s policy does not require a specific EPP status code for it. If a registrar uses clientTransferProhibited, it must also prevent the customer from removing that status themselves. The lock may therefore be invisible in a public lookup, so ask the registrar for the date it ends.
• The policy tells registrars to warn the prior registrant. Anyone who intends to move the domain to a different registrar is advised to request the transfer before the Change of Registrant, to avoid triggering the lock.

2. Orphaned Registrar Accounts and Multi-Factor Authentication

Major registrars and DNS providers such as Cloudflare, GoDaddy, Namecheap and AWS support multi-factor authentication (MFA) on their accounts. That is good security. It becomes a problem when the account’s only administrator no longer works for the agency.

• The mistake: The registrar account is tied to a former project manager or developer. It may be tied to a dead alias such as [e-mail], or MFA may live on a departed employee’s phone.
• The result: On handoff day, nobody can unlock the domain, retrieve the Auth code or approve confirmation emails. Account recovery usually means identity and business verification through the registrar’s support team. How long that takes varies by registrar and can run to days or more.

Note who actually has authority over the transfer. Under ICANN’s policy, the Registered Name Holder is the only party with authority to approve or deny a transfer request. If the client is the registered holder but the agency controls the account, the client has a formal path through the registrar’s support process, but the path is slower than a clean handoff.

3. Registrar Locks: clientTransferProhibited and Friends

Registrars set a lock status on domains to prevent unauthorized transfers, and many apply it by default or on request. ICANN’s policy lets a registrar apply clientTransferProhibited only on registration or at the holder’s request, with the terms in the registration agreement.

Two rules matter for offboarding:

• A registrar must let the holder remove the lock. If it offers no self-service toggle, it must remove the lock, and provide the Auth code, within five calendar days of the holder’s request.
• A registrar generally cannot deny a transfer merely because the domain is locked, unless the holder had a reasonable opportunity to unlock it first.
• The mistake: The agency emails the client an Auth code but leaves the domain locked. Or a registry-level hold exists that nobody checked.
• The result: The transfer fails or stalls. Because the failure happens between two registrars, neither the agency nor the client sees an error until someone checks the transfer status.

---

The Technical Anatomy of a Transfer Failure

The Extensible Provisioning Protocol (EPP) defines the status codes registries and registrars use. ICANN’s guidance splits them into two families:

• Client status codes are set by registrars.
• Server status codes are set by registries and take precedence over client codes.

EPP Status	Set by	What it means	How to resolve it
ok	Registry	No pending operations or prohibitions on the record.	A transfer can proceed once you have the Auth code. Also confirm the registrar’s own rules in its dashboard.
clientTransferProhibited	Registrar	The registrar lock is on and transfers are rejected.	Turn off the registrar lock in the dashboard. If there is no toggle, ask the registrar to remove it (policy limit: five calendar days).
clientUpdateProhibited	Registrar	Updates to the domain object, such as nameservers or contact records, are blocked.	Turn off the update lock before changing nameservers or contacts.
serverTransferProhibited	Registry	The registry is blocking transfers.	Needs a conversation with the current registrar. Typical causes include a legal dispute (for example UDRP or a court order) or a paid registry-lock service. Some registries also use it for post-registration or post-transfer locks.

If a transfer is still rejected after you unlock the domain, check for a server-level status first, then for a registrar-imposed Change of Registrant lock. The second one may not appear as a status at all.

Reading the Record Today: RDAP, Not WHOIS

ICANN ended its contractual obligations for gTLD registries and registrars to provide WHOIS (port 43 and web-based WHOIS) on 28 January 2025. The replacement is the Registration Data Access Protocol (RDAP). ICANN provides a lookup at lookup.icann.org.

Two practical points:

• An RDAP lookup reliably shows the registrar, registration dates, nameservers and EPP status codes.
• Registrant identity, including the registrant email, is typically redacted in public results. You usually cannot audit the registrant email from a public lookup, so check it inside the registrar account instead.

Transfer Mechanics Worth Knowing

These timings come from ICANN’s Transfer Policy:

• Five-day default approval. The registry completes a requested transfer unless the current registrar sends a rejection within five calendar days. If the current registrar does nothing, the transfer proceeds. A registrar may deny a transfer only on specific grounds, such as evidence of fraud, a pending UDRP, a court order, or non-payment for a previous registration period on a domain past its expiration date.
• Early-life locks. A registrar may deny a transfer within 60 days of initial registration, or within 60 days after a previous inter-registrar transfer.
• Term extension. A completed transfer adds one year to the existing registration, up to a maximum total of ten years.

---

What Is Changing: ICANN’s 2026 Transfer Policy Overhaul

Part of this guide may soon become outdated. The ICANN Board adopted the Transfer Policy Review working group’s 47 recommendations on 7 June 2026. Registrar and industry reporting describes the main changes as:

• The Change of Registrant 60-day lock is removed.
• The post-registration and post-transfer lock shortens from 60 days to a fixed 30 days.
• The Auth code becomes a one-time Transfer Authorization Code (TAC), described by some registrars as valid for 14 days.

None of this is in force yet. As of late October 2026, registrars report that implementation is pending and ICANN has not announced an effective date. The working group recommended an 18-month implementation window, and registrars expect the changes to be phased in. Until ICANN publishes an effective date, plan for the current rules and check ICANN’s Transfer Policy page before relying on the new ones.

---

The 30-Day Pre-Offboarding Checklist

Start a month before contract end. Discovering a 60-day hold or an access problem in week one still leaves room to work around it. Discovering it on the last day does not.

Stage 1: Assessment and Audit (Day -30 to Day -21)

1. Identify who holds the registrar account.
   • Note where each domain is registered, such as GoDaddy, Namecheap, Cloudflare or AWS.
   • Confirm whether the domain sits in an agency master portfolio or a dedicated client account.
2. Run an RDAP check.
   • Look up the domain at lookup.icann.org or another RDAP client.
   • Record the registrar, the creation date, the last transfer date, the expiry date and the EPP status codes.
   • Confirm the domain is not within 60 days of initial registration or a previous inter-registrar transfer.
3. Audit registrant details inside the registrar account.
   • Check the registrant name, organization and email. These are usually redacted publicly.
   • Do not edit them casually. If a change is needed, first ask the registrar whether it offers an opt-out of the Change of Registrant lock, and use it before submitting the change.
   • If no opt-out exists, the safest sequence is to transfer first and change registrant details at the receiving registrar afterwards, as ICANN’s policy advises.

Stage 2: Access and Governance (Day -20 to Day -10)

1. Verify login and MFA.
   • Test the registrar login now, not on handoff day.
   • Confirm MFA is attached to a shared team vault or a monitored role mailbox, and not to one employee’s personal phone.
2. Document DNS and plan the nameserver strategy.
   • Export all DNS records: A, CNAME, MX, TXT, SPF, DKIM and DMARC.
   • Check whether the registrar also hosts DNS. A registrar transfer does not change DNS by itself, but if DNS lives at the old registrar, plan the move separately.
   • If DNSSEC is enabled, plan the DS record handling before changing DNS providers.
   • Lowering TTLs on critical records to 300 seconds is a common practice before DNS changes, because it speeds up propagation.
3. Check expiry and billing.
   • Make sure the domain is not expired or about to expire, and renew first if needed. Expired domains can run into registrar-specific rules, and non-payment for a prior registration period is one of the policy’s permitted grounds for denial.
   • Clear any pending invoices or payment holds on the registrar account.

Stage 3: Handoff Execution (Day -9 to Day -1)

1. Unlock the domain.
   • Switch off the registrar transfer lock in the dashboard.
   • Confirm with an RDAP lookup that clientTransferProhibited has gone.
2. Generate and pass the Auth code securely.
   • Generate the code as close to the transfer as possible. Under the pending 2026 rules, codes are expected to be short-lived.
   • Send it through a secret-sharing tool or a password manager’s share function, not plain email or chat.
3. Initiate and monitor the transfer.
   • The client, as holder, submits the Auth code at the receiving registrar.
   • Watch the registrant email inbox for confirmation requests and approve them promptly.
   • Remember that the transfer will complete after five calendar days unless the current registrar rejects it.

Stage 4: Post-Offboarding Verification (Day 0 and After)

1. Verify, revoke and archive.
   • Confirm in an RDAP lookup that the registrar has changed.
   • Remove former agency users, API keys and billing profiles from the old account.
   • Archive a sign-off document signed by both parties.

---

Best Practices for Agencies and Clients

For Agencies: Do Not Register Client Domains in Agency Portfolios

The most common root cause of offboarding lockouts is co-mingling. Agencies often register client domains under one agency registrar account because it is quick.

• Best practice: Have the client create their own registrar account, and register the domain with the client as the registrant.
• Use delegated access to manage it. GoDaddy’s delegate access lets an account owner invite others without sharing passwords, and domain-level permissions can be set through folders. On AWS, use IAM roles in the client’s own account.
• Name a role-based, monitored address as the contact, for example [e-mail], and not an individual’s email.

For Clients: Own the Registrant Record

The Registered Name Holder is the party ICANN’s policy recognizes as having authority to approve or deny a transfer. If an agency is listed as the registrant, the agency is the registered holder as far as the registrar is concerned.

• Best practice: Review your domains at least annually in the registrar account. Make sure the registrant is your organization and the contact email is a monitored, non-personal address you control.

If You Are Already Locked: The DNS Workaround

If a 60-day lock has been triggered shortly before offboarding, you do not have to keep the client waiting or leave the website offline.

• The workaround: The 60-day lock restricts inter-registrar transfers. It does not stop the domain from working or prevent the holder from changing nameservers or DNS records.
• Leave the domain at the current registrar for the lock period. Point DNS at the client’s new hosting or DNS provider, such as Cloudflare or Route 53, so the site and email move over now.
• Ask the registrar for the exact date the lock ends, set a reminder, and complete the registrar transfer once it lapses.

---

Conclusion: Turn Offboarding Friction into Professional Trust

A lockout is rarely malicious. It usually comes from a few ordinary, avoidable gaps:

• a registrant field edited at the wrong time
• an account that only one departed person could open
• a lock nobody thought to check

Agencies that audit registrar access early, protect the registrant record and start the process 30 days out turn a high-risk handoff into a routine one. Clients that own their registrar accounts and keep their registrant details current remove the problem at the source.

---

Originally published at https://instarenewal.com/blog/the-silent-registrar-lockout-how-agency-client-miscommunication-breaks-domain