A domain expiry date looks precise, which makes it tempting to treat it as a countdown to deletion. It is not. The date marks the end of the current registration term in a registry record. What happens next depends on the registry, the registrar's customer agreement, whether the registry auto-renews the object, and whether the registrar deletes, renews, auctions, or otherwise handles the expired registration. A domain can stop resolving before registry deletion, remain renewable after expiry, or never reach a public drop at all.
The safest way to read a lifecycle is as evidence from three layers. The registry holds the domain object and its protocol statuses. The registrar manages the customer relationship and sends commands to the registry. The registrant manages the account, payment, contacts, and renewal choices. Public RDAP or WHOIS can show dates and statuses from the registration system, but it does not show every registrar decision and cannot prove who controls the account or legally owns a business asset.
Quick path: Use Domain Lifecycle for a normalized current view, RDAP Lookup for the underlying public registration object, and the registrar account for any decision about renewal, transfer, or recovery. Add important domains to Domain Monitor, then keep separate DNS and certificate controls where outages at those layers matter.
There is no universal seven-stage lifecycle
ICANN publishes a typical gTLD lifecycle, but even that page warns that registrar activity after expiration may not appear in the chart. ICANN's consensus policies bind contracted gTLD registries and accredited registrars. They do not make every registrar use the same customer grace window, and they do not govern country-code registries in the same way. The useful model is a sequence of possible registry states with policy conditions, not seven guaranteed stops on fixed days.
Availability is also more complicated than the absence of a registered object. A registry may reserve a label, price it under a premium program, restrict eligibility, or block it for policy reasons. An RDAP not-found response can be relevant evidence, but a successful create command from a registrar is what establishes that the name can actually be registered through that channel. Price, eligibility, and release rules belong to the TLD and registrar, not to a universal lifecycle table.
The gTLD baseline
Registered and active are not synonyms
A registered domain has a record at the registry. It may resolve normally, have no nameservers, or be removed from the zone because of a hold. EPP statuses such as `ok`, `clientTransferProhibited`, `serverHold`, or `pendingTransfer` describe operations or conditions on that object. The ICANN EPP status list is useful here. A registered domain with `clientHold` can stop resolving while remaining registered, so DNS failure does not by itself mean expiration or availability.
The expiration event is the end of the recorded term, not proof that the customer failed to pay. Registries commonly auto-renew gTLD objects at expiry and place them in `autoRenewPeriod`, giving the sponsoring registrar a period in which certain delete or transfer operations can reverse registry billing. The public expiry date may move forward even while the registrar still considers the customer account unpaid. An extended date in RDAP is therefore not a receipt for a completed customer renewal.
Registrar handling after expiration
The Expired Registration Recovery Policy requires two pre-expiration notices for covered gTLD registrations, approximately one month and one week before expiry. If the name is neither renewed nor deleted, the registrar must send another notice within five days after expiration. These notices reduce risk, but they do not replace account ownership, working payment, or an independent reminder.
ERRP allows a registrar to delete an expired registration at any time after expiration, subject to the policy's renewal and DNS-interruption rules. If deletion happens eight or more days after expiry, the existing DNS path must be interrupted for at least the final eight consecutive days during which the Registrant at Expiration can still renew, where the registry permits interruption. A registrar may point web traffic to an expiration page, but that page must identify the expiration and provide renewal instructions. Email and other services may fail during the same period.
This is why a phrase such as '45-day registrar grace period' is unsafe as a universal promise. A registry's auto-renew grace period is primarily a registry-registrar transaction window. A registrar can offer a customer renewal window within it, shorten customer handling under its agreement, or run an expired-domain auction while the registry object remains registered. Read the registrar's deletion and auto-renewal policy before expiry. ERRP requires renewal, post-expiration renewal, and restore fees to be disclosed, but ICANN does not set one universal price.
Redemption after registry deletion
If a registrar deletes a gTLD registration outside an applicable add-grace exception, the next important state is usually the Redemption Grace Period. ERRP requires all gTLD registries except sponsored gTLD registries to offer a 30-day RGP immediately after deletion. During RGP, the registry disables DNS resolution and prohibits ordinary transfer attempts. The Registrant at Expiration must request restoration through the registrar that deleted the domain. Public RDAP should indicate the redemption state.
RFC 3915 defines the EPP grace-period extension used for `redemptionPeriod`, `pendingRestore`, and grace-related `pendingDelete` states. A restore is a registry operation, not a new registration. The registrar submits the request and any required restore report. Contact the registrar immediately because support hours, identity checks, payment clearance, and registry deadlines all consume time inside the fixed RGP. Do not wait for the last day because a request that has not reached the registry is not a completed restore.
Pending delete and release
If the RGP ends without a completed restore, many gTLD registries move the domain into a final `pendingDelete` state. ICANN's typical chart and many registry policies use five days for this stage. In that final state, ordinary renewal, restore, update, and transfer are no longer available. After purge, the old registration object is gone. The registry may then make the label available according to its own release, reservation, premium, or allocation rules.
A predicted purge day is not a guarantee that a particular buyer will acquire the name. Registries can process releases in batches or publish their own drop schedules. Registrars and specialized services can compete for a released label, and the previous registrar may have handled the registration through an auction before registry deletion. Avoid claims about exact milliseconds, guaranteed catches, standard backorder fees, or a universal release hour. The only defensible result is the registration outcome returned by the registry through a registrar.
Grace-period labels do not all create customer rights
EPP exposes add, renew, auto-renew, transfer, and redemption grace statuses. The first four often describe whether a registry transaction may be reversed for registrar credit. They do not automatically give the customer a refund, a cancellation right, or a guaranteed number of days to act. The registrar agreement can define customer handling within the registry boundary. RGP is different because ERRP gives the Registrant at Expiration a defined restore path for covered deleted gTLD registrations.
- `addPeriod` follows a new registration at registries that offer an Add Grace Period. Deletion during it can avoid the normal RGP path.
- `renewPeriod` can follow an explicit renewal and mainly describes registry transaction handling.
- `autoRenewPeriod` can appear after registry auto-renewal at expiry; it does not prove the registrar's customer has paid.
- `transferPeriod` can follow an inter-registrar transfer and concerns registry billing treatment.
- `redemptionPeriod` means the registration has been deleted and is in the restore window offered by the registry.
- `pendingRestore` means a restore process has started but may still require completion.
- A final `pendingDelete` state means restoration is no longer available under the normal lifecycle.
Transfers near expiry need extra care
Do not plan an important registrar transfer for the final days before expiry. The authorization code, transfer lock, account approval, gaining-registrar checks, and registry processing all need time. The ICANN Transfer Policy permits denial within 60 days of initial creation and within 60 days after a previous inter-registrar transfer, among other listed reasons. A registrar lock must be removed through the account before a normal transfer can proceed.
Expiration itself does not create one simple transfer rule. ICANN has clarified that a registrar cannot deny a transfer solely for nonpayment of a pending or future renewal period during auto-renew grace when past registration fees are paid. Past unpaid fees can be different under the Transfer Policy. A transfer after registry auto-renewal can also affect which renewal year remains in the term and how registrars settle billing. Confirm the displayed expiry after completion and keep invoices from both registrars.
A change of registrant can trigger a separate registrar lock under the Transfer Policy, with opt-out rules that must be handled before the change. That can matter during an acquisition or internal reorganization close to expiry. Public registration data is not enough to establish who may approve the transfer. Use the authenticated registrar account, current transfer contact, contracts, and transaction records. Renew first when necessary, then transfer with enough time to resolve a denial.
Country-code registries set their own clocks
ICANN's gTLD consensus policies do not become ccTLD policy merely because a registrar sells both types in the same control panel. IANA's Root Zone Database identifies the TLD type and manager. It classifies `.io` as a country-code top-level domain, not a new gTLD. The registry and registrar policies applicable to .io therefore need to be checked directly rather than copied from a .com lifecycle diagram. Marketing language does not change the IANA classification.
Current .uk policy provides a useful contrast. Nominet's renewal procedure says an unrenewed .uk domain remains renewable until precisely 90 days after its expiry timestamp and drops at expiry plus 95 days. Its current process includes an initial operational period, suspension, then a final cancellation window. Those numbers describe .uk under Nominet's present rules. They do not describe .com, .io, .eu, or another ccTLD.
EURid provides another useful contrast. Its current .eu rules describe registration terms from one to ten years with tacit one-year renewal, along with eligibility, blocked-name, and reserved-name rules specific to the namespace. Those conditions affect whether a label can be registered or renewed and are not part of the .com lifecycle. For deletion and recovery, use EURid's current policy repository and the sponsoring registrar rather than a generic gTLD calendar.
For any TLD, record the source of the rule and the date you checked it. Registry policies change. Some namespaces impose local-presence or eligibility rules, some use auctions or scheduled lists, and some allow direct registrant recovery that gTLD workflows route through registrars. A lifecycle system should attach TLD-specific policy to its alert rather than calculate a drop date from a global constant.
Renewal safeguards that survive staff and payment changes
Auto-renew is useful, but it is only one control. It can fail because the payment method, account balance, tax record, eligibility evidence, or registrar account needs attention. Keep critical domains in an organization-controlled registrar account with strong authentication and recovery methods. Use a shared operational mailbox for registrar notices, plus an escalation contact outside that mailbox in case the domain's own mail stops working. Never make the expiring domain the only route for recovering its registrar account.
- Assign a named business owner and a separate technical operator for each critical domain.
- Verify auto-renew state, payment validity, account recovery, and registrar contact details on a regular schedule.
- Renew high-impact domains well before expiry instead of relying on a post-expiration customer grace window.
- Use registrar lock and stronger registry-lock services where the risk justifies them, while remembering that a transfer lock does not renew a domain.
- Keep an inventory of registrar, account, expiry observation, renewal evidence, TLD policy, and recovery instructions.
- Test notifications and escalation outside the domain being protected.
- After any renewal or transfer, verify the registrar account and public registration event rather than assuming the displayed date updated correctly.
For acquisitions and divestitures, list domains explicitly in the transaction documents and transfer them through registrar accounts. A public WHOIS or RDAP organization field can be redacted, name a privacy provider, or reflect a stale public value. ICANN's Registration Data Policy governs publication and disclosure for covered gTLD data, not proof of asset title. Account control, contractual assignment, payment records, and transfer completion are stronger evidence.
How DomScan represents lifecycle data
The Domain Lifecycle tool and `GET /v1/lifecycle` summarize current registration evidence. The API costs 2 credits and can return registration, expiration, update, and transfer events; age and days-to-expiry calculations; a derived phase; and status flags. Current phases are `available`, `active`, `expiring`, `deleting`, `reserved`, and `unknown`. In this endpoint, `expiring` is derived from redemption or restore statuses. A registered name approaching its ordinary expiry date can remain in the `active` phase while `expires_in_days` counts down.
The endpoint prefers RDAP for most TLDs, uses traditional WHOIS for selected namespaces or as a fallback, and can derive limited flags from DNS activity after some upstream failures. Its response metadata currently identifies the serving edge and worker version, not a complete provenance chain. Treat a result with no registration events or dates as limited evidence. DNS activity cannot prove registration availability, and absence of DNS is common for registered domains. Confirm any purchase, recovery, or deletion decision with the registry or registrar.
Domain Monitor has a narrower scheduled scope. It watches registration availability, expiry, and status for domains in the account. A reported expiry within 90 days can be classified as `expiring_soon`, and configured notifications can follow relevant status or threshold changes. Domain Monitor does not automatically compare DNS RRsets, certificate chains, mail authentication, uptime, or lookalike registrations on every run. Use separate systems or DomScan's on-demand tools for those layers.
An availability or expiry alert should trigger verification, not an irreversible action. Upstream RDAP can be missing an expiration event, a registrar can have customer renewal state that has not reached the public record, and a ccTLD can use a lifecycle DomScan's generic phase does not represent exactly. The registrar account is the operational source for renewal. The registry's published policy controls the namespace. DomScan supplies a repeatable observation and an earlier reason to check both.
Watching a domain you do not control
An expiry date on another party's domain is not a promise that it will become available. The registrant can renew, the registrar can retain or auction the registration under its agreement, the registry can reserve the label after deletion, or a competing request can register it first. A backorder is a service request, not a guarantee. Avoid building budgets or brand-response deadlines around a calculated drop day unless the relevant registry publishes one.
For an abusive or brand-adjacent domain, expiration does not prove that the threat ended. DNS can stop while credentials, redirects, certificates, or campaign infrastructure remain active elsewhere. A later registrant may use the name differently. Preserve evidence and follow the legal, registrar-abuse, hosting, and law-enforcement paths appropriate to the incident. If defensive registration becomes possible and is lawful, confirm trademark and eligibility issues before registering.
For a domain you must keep, the decision is much simpler: renew before policy becomes relevant. Record the successful renewal in the registrar account, confirm the new term in public registration data after it propagates, and investigate any mismatch. Grace and redemption periods are recovery mechanisms for failures. They are poor operating targets for assets that carry production traffic, email, authentication, or customer trust.