Managing a Domain Name

What you actually hold when a domain is registered

A domain name is not bought. It is a right of use, granted for a fixed term, recorded in that extension's registry database and administered on your behalf by a registrar. Terms run in one-year increments at most registries, to a ten-year maximum on the total unexpired term.

So a domain has one date that matters more than any other. The website, the mail flow, the single sign-on that authenticates against a hostname, the SPF records that let other systems send mail in your name — all of it hangs off one database record with an expiration timestamp. When that timestamp passes without payment, those things do not fail one at a time. They fail together.

A first-year price and a renewal price are independent variables and only the second recurs, so an introductory discount tells you nothing about year two. Restoring a deleted domain is not a renewal but a separate registry operation with its own fee, and it is the largest routine charge in the lifecycle. ICANN requires registrars and resellers to publish all three figures; look them up now.

Registry, registrar, DNS host: three parties, three different outages

Almost every question that begins "my domain is broken" resolves to a confusion between three roles.

The registry operates the extension, running the nameservers for the top-level zone and holding the master record of every domain under it. The registrar is the retailer and the party you contract with, controlling who is listed as registrant, which nameservers are delegated, whether the domain is locked, whether it auto-renews, and the DS record that anchors DNSSEC. The DNS host answers queries for your zone — the servers holding your A, MX and TXT records — and is often not your registrar. Many registrars bundle basic DNS and set their own nameservers by default, which is why so many owners believe the registrar is the DNS.

• The domain expired, moved without permission, or carries a registrar-set status: registrar problem.
• The site resolves to the wrong address, or mail stops arriving: DNS host problem.
• The record carries a registry-set status, or the extension itself has an incident: registry problem.

One failure deserves naming on its own. Edit A records in your registrar's DNS panel while the domain's nameservers are delegated elsewhere and nothing you change has any effect: you are editing a zone no resolver reads. That is not a bug, and it generates more support tickets than anything else in domains.

Expiry is a sequence of states, not a single event

At the expiry date the registry auto-renews a gTLD domain and bills the registrar, so the record can look renewed while the registrant has paid nothing. Standard practice puts that grace window at 45 days, bounded by ICANN's rule requiring deletion within 45 days of the agreement terminating. But the registrar chooses when inside it to send the delete command. Forty-five days is an outer bound, not a promise made to you.

Resolution is a separate question from recoverability. ICANN requires it to be interrupted for at least the final eight consecutive days in which renewal remains available. So a name may go dark on day one or keep working for weeks, but it is dark before it is deleted, and mail breaks at the same instant as the site.

When the delete command is sent, the registry applies the 30-day redemption period ICANN mandates for gTLDs. Transfers are barred, and recovery is no longer a renewal but a restore: a registry operation only the sponsoring registrar can request, carrying a restore fee, the registrar's margin, and a renewal term. After 30 days the name moves to pending delete, typically five days as registry operational policy rather than ICANN mandate, during which nothing can be done at all. That is the point of no return.

Two clocks run here: the 45 days is a maximum for the registrar, and the 30 plus 5 only begins once it deletes. None of this carries over to country-code extensions, which set their own lifecycles — a lapsed .uk stays fully operational for its first 30 days, and .de has no fixed-expiry model at all.

Auto-renew is a billing preference, not a guarantee

The most durable bad advice in domains is that auto-renew makes expiry a solved problem. The auto-renewal at the registry is an accounting state rather than a protection: it bills the registrar and gives it a window in which deleting the name earns a credit back. Your actual protection is the registrar-level setting, and that depends on a payment succeeding on a particular day.

The failure modes are mundane. A card expires, or is reissued after a fraud replacement. Renewal notices and failed-payment warnings go to a mailbox nobody has read since the person who set it up left. A domain arrives at a new registrar after a transfer with auto-renew switched off, because settings do not travel with the registration.

One more belief needs correcting. Locks do not prevent expiry: a delete-prohibited status or a registry lock refuses a deletion command, but neither pays an invoice. What works is redundancy that does not run through the registrar — a payment method more than one person monitors, notices reaching a role address on a different domain, and a calendar reminder independent of anything the registrar sends.

What a transfer moves, and what it leaves where it was

An inter-registrar transfer changes one thing: which registrar sponsors the registration. It does not move your DNS, your zone records, your hosting, or your mailboxes. Nameservers delegated to a third-party DNS host keep pointing there, and resolution is untouched.

The EPP authorization code — the per-domain secret, also called an auth code, that proves control of the registration — must be unique per domain, and the registrar must supply it within five calendar days of your request. A payment dispute is not grounds to withhold it, and getting it may not be made harder than changing your nameservers. Once the transfer is placed, the losing registrar has five calendar days to respond, and silence counts as approval — the origin of the familiar five-day wait.

A completed gTLD transfer adds a year to the existing expiration date rather than restarting from the transfer date, subject to the ten-year cap, and the gaining registrar bills for that year: you are buying registration time, not paying an administrative fee.

Transfers fail for a short, predictable list of reasons: a lock left on, a stale or mistyped code, a confirmation email nobody reads. Above all they fail on the three separate 60-day locks. A registrar may deny a transfer within 60 days of the creation date, and may deny one within 60 days of a previous transfer. But it must impose one after a change of registrant — a material change to the registrant name, organization, or email address — and that lock cannot be lifted retrospectively. Transfer first, change registrant details second. And with DNSSEC enabled, a transfer that leaves the DS record out of step with the signed zone takes the domain off the internet for every validating resolver.

Reading the status codes on your own record

Every gTLD domain carries EPP status codes — EPP being the protocol registrars use to talk to registries — and those are the "Domain Status" lines in a WHOIS or RDAP lookup. The prefix is the whole story. A code beginning client was set by your registrar and can be changed by it, usually by you. A code beginning server was set by the registry and the registrar cannot remove it.

• ok means no prohibitions and no pending operations: healthy, with no protection turned on. It cannot appear alongside any other status, which is why a locked domain never shows it.
• clientTransferProhibited alone is the standard registrar lock: normal and desirable. Adding delete and update prohibitions gives a well-secured domain.
• inactive means no nameservers are associated with the domain: a configuration gap, not a policy action. clientHold and serverHold mean the domain is switched off at the delegation, which looks like a DNS fault and is not one; only the party named in the prefix can lift it.
• autoRenewPeriod means it expired and is still cheap to fix. redemptionPeriod means it was deleted and can only be restored, at cost, through the sponsoring registrar. pendingDelete on a gTLD means it is gone, though .uk uses that status name for a phase where renewal is still possible.

RDAP, the successor to legacy WHOIS, renames these into spaced lower-case forms, so ok reads as active.

The contact record is the recovery channel

The registrant and account email address is not administrative trivia. It is the reset channel for the registrar account, and the registrar account is the control channel for the domain. Whoever reads that mailbox can reset the password and take the name. A dead address on a contact record is the most expensive piece of neglect in domain management: it disables your recovery path and hands it to whoever notices first.

ICANN's Security and Stability Advisory Committee has documented both halves of the failure. It is not safe to send credential recovery instructions for a domain to an address inside that same domain, because an attacker who has already redirected your MX records receives your own password reset. And mailboxes lapse with the domain they sit on, after which someone else can claim the address and run the forgotten-password process against your registrar.

The right arrangement is unglamorous: a role address rather than an individual's mailbox, on a different domain, with its own two-factor authentication. Fix it while you have time, because changing a registrant email is a change of registrant, and that triggers the mandatory 60-day transfer lock.

A maintenance routine that survives staff turnover

Domain management is not continuous work. It is a few checks on a schedule, plus a record that outlives the person who set everything up — a copy of the zone file and an offline note of the registrar account and registrant of record, kept outside the vendor that holds them.

• Verify the expiration date and status codes at the registry with a WHOIS or RDAP lookup, not just the registrar's dashboard.
• Send a test message to the registrant and account email to confirm someone still reads it.
• Check that the payment method has not expired or been tied to one individual, and that auto-renew is still on after any transfer.
• Keep two-factor authentication on the registrar account and on the recovery mailbox, preferring an authenticator app or hardware key to codes sent by text message.
• Keep the registrar transfer lock on by default, add delete and update prohibitions to anything whose failure would matter, and consider a registry lock for names you cannot operate without.

Underneath the checklist is one decision worth making deliberately: how much to consolidate. Registration, DNS, hosting and mail with one vendor is simpler, and one well-run vendor can beat three badly run ones. It also means a single compromised account takes all four at once, including the mailbox you would use to recover. The independent recovery mailbox is the part that is not negotiable.