Can You Transfer a Domain After It Has Expired?

Yes while it is only expired, no once it has been deleted

Usually yes: a domain past its expiration date can normally still move to another registrar, provided the registrar of record has not yet deleted it and you settle the outstanding renewal first. Once it has been deleted and the registry places it in redemptionPeriod, the answer is no. Transfers are prohibited at the registry, and the only route back is a restore through the registrar you were trying to leave.

Which of those two situations you are in is decided by the domain's registry status, not by the number of days since expiry. Three days, ten days and thirty days can each describe a name that is comfortably recoverable, and each can describe one that has already been deleted, because the delete date is the registrar's own commercial decision rather than a fixed point in the calendar. Answering this question by counting days is guessing.

What follows is how to read that status yourself, what your registrar may and may not do while the renewal is unpaid, and why the sequence that works is renew first, transfer second.

Read the status yourself before you ask anyone

Every generic domain carries EPP status codes, the state flags the registry publishes in the public registration record. You can read them in a WHOIS lookup or, for generic extensions, in RDAP. Four of them settle the transfer question on sight.

• autoRenewPeriod - the registry auto-renewed the name at expiry and billed your registrar. The domain is expired but not deleted, and a transfer is still conceivable.
• clientHold - your registrar has pulled the delegation out of the DNS, which is why the site and mail are down. It is a registrar setting rather than a deletion, and does not by itself block a transfer.
• redemptionPeriod, usually alongside serverTransferProhibited - the delete command has been issued and the transfer question is closed until the name is restored.
• pendingDelete - the redemption window has run out. Nothing can be renewed, restored, transferred or updated.

One detail trips people up more than any other. During the auto-renew grace period the record often shows an expiry date a year ahead, because the registry really has renewed the registration at the registrar's expense. It looks healthy while the renewal is unpaid and the clock is running. Read the status codes, not the expiry date.

During the grace period, the renewal comes before the release

At expiry the registry auto-renews a generic domain and bills the registrar for a year the registrant has not paid for. Delete within that window and the registrar receives a credit, which is why cheap late renewals exist. The standard length is 45 days - established registry practice reinforced by ICANN's Expired Domain Deletion Policy rather than a mandated grace period length - and the registrar picks its own delete date inside it. Some delete around day twenty, some wait until the end, and some route the name into their own expired-domain auction platform.

That billing position shapes the policy. ICANN's Transfer Policy, the consensus policy governing inter-registrar transfers for generic extensions, lets the registrar of record deny a transfer for non-payment for a previous registration period where the domain is past its expiration date, provided it first places the name in Registrar Hold status. A registrar refusing to release an expired, unpaid name is generally acting within the rules; most will simply tell you to pay the renewal.

Two adjacent rules are misread as guarantees. Your registrar must supply the EPP authorization code, the per-domain secret proving you control the registration, within five calendar days of your request, and it may not withhold that code or keep the transfer lock on solely because of a payment dispute. Holding a valid code is not the same as being entitled to move. The policy is equally clear about what cannot be used against you: non-payment for a pending or future registration period is never a valid ground for denial. The Transfer Policy sets out the denial grounds in full.

Timing matters as well. A Form of Authorization expires on the earliest of several events, one of them the domain's expiration date, so a transfer left half-finished across that date has to be started again.

Redemption closes the question entirely

When the registrar issues the delete command the registry moves the domain into redemptionPeriod for 30 days, a duration genuinely mandated for generic extensions by ICANN's Expired Registration Recovery Policy. Throughout it the registry must disable DNS resolution and prohibit attempted transfers. This is not registrar reluctance that a support ticket might soften; the registry itself rejects the request.

Recovery here is a restore, which differs from a renewal in three ways that matter to anyone trying to change registrars. Only the sponsoring registrar can request it, so you cannot escape a registrar you have lost patience with by approaching the registry directly. The cost is structurally different: a wholesale registry restore fee substantially larger than a renewal, the registrar's margin on top, and a renewal term as well. And a restore is not guaranteed to be a product: some registrars handle it only by manual support ticket, and no ICANN rule requires otherwise.

Only after the restore completes and the associated statuses clear can the name be transferred, by which point you have paid the registrar you wanted to leave far more than a renewal. After 30 days without a restore the registry moves the name to pendingDelete, typically for five days, and nothing retrieves it from there.

The sixty-day locks that ambush people mid-recovery

Two separate sixty-day restrictions strand names that were otherwise recoverable, and registrants usually trigger them while trying to fix the problem.

The first follows a Change of Registrant, which the Transfer Policy defines as a material change to the registrant name, organization or email address; typographical corrections are excluded. This lock sits in the policy's must-deny list rather than its discretionary list, and the only escape is an opt-out agreed before the change. Nothing lifts it afterwards. The trap is plain once stated: the reason many registrants miss a renewal is that the notices went to a mailbox nobody reads, and the first instinct on discovering that is to correct the registrant email. Do it before the transfer and the name cannot move for two months while the expiry clock keeps running.

The second follows a prior transfer. A registrar may deny a transfer requested within 60 days of the name being transferred to it, and although the policy calls that discretionary and allows a shorter period, most apply the full term. Anyone who moved a domain recently, missed the renewal in the confusion, and now wants to move again to a cheaper provider is likely to be told to wait. A comparable restriction applies within 60 days of initial registration.

The rule is one of sequence: renew, transfer, and only then update the registrant details at the new registrar, where the lock costs nothing.

Renew first, then transfer, because the year is not lost

The objection to renewing first is always the same: nobody wants to pay the registrar they are leaving, least of all an expensive one. The arithmetic does not support it.

A completed, holder-authorized transfer of a generic domain adds one year to the existing expiry date rather than restarting the term from the transfer date, subject to the ten-year cap on total unexpired term. Renewing before you transfer forfeits nothing: the year you buy from your current registrar and the year the transfer adds are both still there afterwards. It is also why a transfer and a renewal cost about the same: each buys a year of registration.

Set that against the alternative. A post-expiration renewal may carry a registrar-set late fee, but a restore is a different order of expense, and a dropped name is either gone or has to be bought back from whoever caught it. The transfer is not instant either: the losing registrar has five calendar days to respond to the registry's notification before default approval, and those days can run past the date that registrar planned to delete the name.

The order that works: check the status to establish whether the name has been deleted; renew at the current registrar, whatever you think of their pricing; remove clientTransferProhibited and request the authorization code; place the transfer order; and leave the registrant contact details alone until it completes. ICANN's own guidance starts in the same place, telling registrants to contact the registrar immediately about the renewal options available.

Country-code extensions answer this differently

Everything above describes generic extensions under ICANN contract. The Transfer Policy does not bind country-code registries, and their expiry models diverge enough that the answer can flip.

Nominet keeps an expired .uk fully operational and renewable for the first 30 days, then applies the status name pendingDelete to a period in which renewal is still possible - the same name that is terminal for a generic domain. EURid puts a lapsed .eu into quarantine for 40 days, during which the site and the mail stop working and reactivation depends on why the name was deleted. DENIC does not run .de on a fixed expiry date at all. Read the registry's own lifecycle before assuming any of the generic mechanics apply.