No: an ordinary renewable domain registration does not buy a name forever. You obtain use for a defined registration period and must renew it to keep that use. A seller’s “lifetime” promise needs a separate contract check. Ask 5 questions: which naming system, which registered holder, what expiry, who renews and what happens when the seller stops operating?
What does a “forever domain” offer actually give you?
ICANN’s renewal guidance describes registration for a specified period, typically between one and ten years, followed by renewal if the holder wants to continue. “Typically” matters. It is not a verified maximum for every extension, and this guidance does not establish the current rules for a particular .zm registration. Read the applicable registry and registrar terms before making that claim.
The practical distinction is between the registration itself and a seller’s additional service. If a seller undertakes to arrange future renewals, ask to see that undertaking in writing. It does not make the current registry expiry disappear. A checkout label, payment receipt or impressive account badge cannot independently establish a perpetual right in the domain name.
Start with the exact spelling and ending. A promise about one name is not evidence about a similar name under another extension. Keep the domain identifier separate from a website package, email account or brand name. A business can receive useful design work without receiving the registration control it expected. The purchase decision should identify those deliverables individually.
Then identify the party providing the promise. ICANN’s registrant benefits and responsibilities say registrants are entitled to information about the accredited registrar and the registration agreement. A reseller may be your commercial contact while another organisation performs the registrar role. Record both roles rather than assuming the business name on an invoice answers every operational question.
Treat a product using another naming system as a separate proposition. Ask the seller to demonstrate the exact browsing, email and recovery requirements you need, and obtain the relevant system’s documentation. This article has not verified a permanent-name product or its compatibility. A similar-looking label does not establish that it can replace the renewable domain used by your present website and email.
Automatic renewal is another distinct arrangement. ICANN’s renewal and expiration FAQ notes that most registrars offer it, while payment information still needs to remain current. Enabling a setting is not proof that a future renewal has completed. A seller funding renewals, a registrant funding renewals and a registry granting a current registration period are different facts.
How can you assess the promise before committing?
Compare the words with the evidence
Use this original offer-decoding table when reading a proposal. The descriptions are hypothetical arrangements, not endorsements of a provider or statements about a live account.
| Wording in an offer | Evidence to request | What remains unresolved |
|---|---|---|
| “Domain included with your website” | Exact domain, registration agreement and holder details | Whether registration continues if the website package ends |
| “Lifetime renewals managed for you” | Renewal undertaking, duration definition and exit provisions | Who performs and funds the next renewal if the seller cannot |
| “Register several years ahead” | Registrar confirmation of the resulting expiry | Renewal after that date and ongoing account control |
| “One-time purchase of a name” | Naming-system documentation and demonstrated required uses | Whether it is the same kind of domain your services require |
Do not fill an evidence gap with a reassuring interpretation. Ask the seller to rewrite ambiguous wording into an observable obligation: identify the name, the party responsible and the event showing completion. If the answer merely repeats “lifetime”, the central question is still unanswered. Keep promotional copy and contractual commitments in separate columns.
Worked example: decode three fictional offers
Imagine a small consultancy, Example Practice, wants one address for its website and business email. It receives three fictional proposals. Offer A includes registration while an associated website subscription remains active. Offer B promises to arrange renewals indefinitely. Offer C offers a defined multi-year registration and places renewal responsibility with the consultancy. No real company, domain account or transaction is represented by this example.
For A, the decisive question is what happens when the consultancy changes its website provider. Ask whether it can retain the name, manage renewal and authorise a registrar transfer without keeping the old website package. A functioning website on the first day answers none of those exit questions. Record the seller’s actual contractual response rather than assuming either a lock-in or an unrestricted exit.
For B, ask what “indefinitely” means when the provider closes, changes ownership or stops offering the service. Who can instruct the registrar then? Which party receives reminders? Is an alternate renewal route documented? These are proposed due-diligence questions, not a legal conclusion that the promise is valid or invalid. The point is to identify reliance on the seller before describing the name as secured forever.
For C, the defined expiry makes the future task visible. The consultancy must still confirm who holds the registration and who controls the relevant account. A transparent expiry is useful evidence, but it does not make every other term suitable. Compare the whole arrangement against the actual business need rather than selecting the proposal with the longest-sounding duration.
The completed example has a clear conclusion: none of the three descriptions alone proves permanent registration. A and B need their continuing-service promises examined; C openly requires another renewal decision. The decision record should say which dependency the consultancy accepts, instead of awarding a vague “forever” tick.
Keep a short acceptance record
Create a record headed “registration rights and seller obligations”. Enter the exact name, the registrar, the contracting seller, the registered holder, the confirmed expiry and the renewal undertaking. Add a source for each entry: agreement section, registrar record or written response. Leave unknown fields visibly unresolved. Do not put passwords, recovery codes or payment details into the record.
ICANN’s rights page supports retaining the agreement and explains responsibilities for accurate information and current account details. Use that material within its applicable scope. It does not prove the correct holder for your account or settle ownership disputes. If an agency is helping, request an authorised management arrangement that the business understands; do not solve shared access by circulating the owner’s password.
Read transfer conditions before treating a future move as an escape plan. ICANN’s transfer FAQ explains authorisation and situations where transfers can be restricted. Changing a service supplier is not evidence that a domain transfer will be immediate. For a country-code domain, obtain the relevant registry’s procedure rather than importing generic-domain rules by analogy.
If registration is already close to expiry, address that actual status with the registrar. Do not let a discussion about a lifetime package delay an existing renewal. ICANN’s expiration FAQ explains that renewal and recovery options vary, and that a name in redemption must be restored before transfer. There is no guaranteed rescue window established here for every extension or every account.
This article owns the permanence question and the seller-promise test. For the mechanics of choosing a longer term, use the separate long-term registration guide; for the wider service, see domains. To discuss the domain requirement in a website brief, get started with the exact name and the written terms. No registration, renewal or account change has been made for this article.
By Spout Team. AI-assisted drafting by Codex using the linked primary ICANN material.