Managing a domain means keeping four things in working order: the renewal and the payment behind it, the contact details your registrar holds, the DNS records that send visitors and email to the right place, and the lock and code that control whether the name can move. If you rent a domain for a shop, a blog or a club site and someone else set it up, the first job is to find out which account holds the name and which panel holds the records. Disputes over who is entitled to a name are a different subject; for those, go to your registrar and the relevant dispute bodies.
Who holds what: registrant, registrar and registry
You are the registrant, the party renting the name. The registrar is the accredited company whose control panel you log in to. The registry is the organisation that keeps the records for a whole extension such as .com. Day-to-day requests go to the registrar, which passes them on. You do not write to the registry yourself.
ICANN lists what registrants can expect and what they owe on its Registrants' Benefits and Responsibilities (Opens in a new tab) page. On the rights side, the page says your registration must be covered by a registration agreement with an ICANN-accredited registrar, that you may review and save a copy of it, and that you are entitled to information about transferring, renewing and restoring your registrations and about how to raise concerns and resolve disputes with the registrar. It also says registrars may not use deceptive notices or hidden fees. On the duty side, the page makes you solely responsible for the registration and use of the name.
Whose name is on the account
If an agency or freelancer registered the domain for you, check the registrant field. Practical suggestion: put the organisation's own name and an address the organisation controls on the account. If the contact is a personal mailbox that later closes, renewal notices and transfer approvals go nowhere.
Decisions that come before management
Choosing an extension is covered in the piece on .com.tr or .com for SEO, and checking whether a name collides with other brands in search is covered in choosing a brand name for SEO. Management starts once the name is registered. Country extensions can have registration rules of their own; those are outside this topic, so check the extension's official documents and your registrar's agreement.
Where each job is done
Table: Management jobs, the place they are done and what a lapse costs.
| Job | Where it is done | What a lapse costs |
|---|---|---|
| Renewal and payment | Registrar panel | The name enters its expiry stages and site and email can stop |
| Contact details | Registrar panel | Notices and verification messages never arrive |
| DNS records | Registrar or a separate DNS or hosting service | Site or email points to the wrong place |
| Transfer lock and code | Registrar panel | A move is blocked, or an unwanted move becomes possible |
Many owners edit records in a panel that no longer controls them. If a hosting company or DNS service runs the name servers, the registrar only stores the names of those servers. Edits made at the registrar do nothing in that case. Learn which panel is authoritative before touching anything.
Roles in practice
Table: Which party to approach for which request.
| Party | What it does | When you deal with it |
|---|---|---|
| Registrant (you) | Rents the name, keeps details accurate | At every renewal and every contact change |
| Registrar | Files the registration, runs the panel and support | Renewal, restoration, lock and code requests |
| Registry | Keeps the extension's records | Not directly; your registrar acts for you |
Renewal, payment and the duties ICANN lists
The same ICANN page lists duties that map to routine upkeep. You must follow the terms your registrar posts and the applicable registrar, registry and ICANN policies, and you must review the current registration agreement and its updates. You must give accurate information for publication in directories such as WHOIS and update it promptly when it changes. You must respond to registrar inquiries within fifteen days and keep your account data current. If you choose automatic renewal, you must also keep your payment information current.
The fifteen-day window has a practical edge. If a registrar asks you to confirm contact details and the mailbox on file is unread, the duty has lapsed on your side without anyone noticing. The page does not describe the stages after expiry; those belong to the registrar's own documentation and to the registry's rules.
A three-layer renewal safety net
- Switch automatic renewal on and check the payment method once a year.
- Send reminders to a mailbox that at least two people read.
- Read the expiry date from the registrar panel and put a check date in a calendar before it.
When a renewal payment fails
Practical suggestion: on the day you see a failed payment, read the name's status and expiry date in the panel, update the card, start the renewal by hand, and confirm the new expiry date afterwards. If it still fails, send support the domain name and the exact error message. Also test the site and email separately, because a name that looks active in the panel can still point to the wrong servers.
What follows when someone else lets a name lapse and you consider buying it is a separate risk, covered in the article on expired domain backlinks, risks and checks. Here the concern is the reverse: losing your own name.
What the registry grace states mean
A name that is not renewed does not turn public overnight. RFC 3915 (Opens in a new tab), written for the EPP protocol that registries and registrars use, defines named states. It states that the length of each grace period is a matter of registry operational policy and is not set by the document, so a number of days quoted elsewhere may not apply to your extension. Table: States defined in RFC 3915.
| State | Meaning in RFC 3915 |
|---|---|
| addPeriod | Follows the initial registration; a deletion by the registrar in this period earns a credit for the registration cost |
| autoRenewPeriod | Follows an expiry where the registry renewed the name automatically; a deletion earns a credit for the renewal cost |
| renewPeriod | Follows an explicit renewal by the registrar |
| transferPeriod | Follows a successful transfer to a new registrar |
| redemptionPeriod | Follows a processed delete but precedes the purge; the name can still be restored |
| pendingRestore | A restore is in progress after the redemption period began |
| pendingDelete | The redemption period has ended and the name is being purged |
Only the registrar that sponsors the name can send a restore request, followed by a report in a window the registry defines. If no restore request arrives before the redemption period ends, the name moves to pendingDelete, is purged and then becomes available for registration again. For you, the lesson is that the days right after expiry are the cheapest time to act, because later stages go through the registrar and may carry extra fees. Fees and timing are set in your registrar's agreement.
DNS: the layer that joins a name to a server
MDN (Opens in a new tab) defines DNS as a hierarchical and decentralized naming system that keeps a list of domain names and the resources, such as IP addresses, associated with them. Its best-known job is translating a human-friendly name into a numeric IP address, a step called a DNS lookup. The browser has to complete that step first, so a wrong record can make a healthy server unreachable. The record table that follows keeps to what a manager needs.
Table: Four record types, their job and the management point.
| Record | Job | Management point |
|---|---|---|
| A | Joins a name to an IP address | Changes when the hosting address changes |
| CNAME | Makes one name an alias of another | The target name must be right |
| MX | Points to the mail server | Deleting it by mistake stops incoming email |
| TXT | Carries verification and sender text | Removing a verification record can break ownership checks |
Name servers are not records
Name servers are the machines that hold your records. The registrar stores only their names. Changing name servers hands the whole record list to another place. If the new place lacks the old records, the site and the mailbox lose their routing. Practical suggestion: treat a name server change as its own project. Export the list first, then test the site, the email and every verification record afterwards.
Changing hosts: caching and TTL
Google's Site moves without URL changes (Opens in a new tab) page says DNS settings are cached by ISPs according to the Time to Live value. It suggests lowering the TTL to a conservative value, for example a few hours, at least a week before the move so that new settings spread sooner. The move itself starts when DNS records are pointed at the new host, and the old server should stay up until traffic to it reaches zero. A temporary drop in Googlebot's crawl rate right after launch is described as normal, followed by a steady increase over a few days. Google's guidance can change, so check the current page before you act.
Keeping Search Console verified
A domain property in Search Console is verified through a DNS record. Google's Verify your site ownership (Opens in a new tab) page says not to remove the DNS record from your provider, even after verification succeeds, if you want to stay verified. If verification can no longer be confirmed, you are notified, and permissions on the property expire after a grace period if the problem is not fixed. A manually added record can take two or three days before the provider serves it. During a DNS cleanup, never delete a TXT record you cannot explain. The difference between the two property types is covered in Search Console domain versus URL-prefix property.
Moving a name to another registrar
Two controls decide whether a move can start: the registrar lock and the authorization code. The ICANN Transfer Policy (Opens in a new tab) page says that if a registrar does not give the name holder tools to generate and manage their own authorization code and to remove the ClientTransferProhibited status, it must provide the code within five calendar days of the holder's initial request.
The policy limits when a registrar may deny a transfer: evidence of fraud, a reasonable dispute over the identity of the holder or administrative contact, non-payment for the previous or current registration period, an express objection by the authorized transfer contact, a request within sixty days of the name's creation, and a request within sixty days after a prior transfer. Separate rules require denial during pending UDRP or URS proceedings, court orders, TDRP disputes, and the sixty-day lock after a change of registrant. The page notes that an updated version of the policy was published in February 2024, so read the current text before you rely on it.
Changing the registrant
Under the policy, a material change to the registrant's name, organisation or email address triggers a confirmation from both the prior and the new registrant through a secure mechanism, notifications to both, and processing within one day of the confirmations. A sixty-day inter-registrar transfer lock follows. The registrar may allow the holder to opt out of that lock, but only before the change request. The policy also advises the prior registrant to request an inter-registrar transfer before the change of registrant so the lock is not triggered. Handing a site from an agency to a client is the case where this order matters.
Guarding the code
The authorization code works like a key to the name. Do not leave it in a chat thread, a shared document or a screenshot. When the move is finished, confirm in the panel that the lock is on again at the new registrar. DNS continuity during the move follows the logic in changing web hosts: DNS cutover checklist.
One account or several: a decision rule
When the domain, hosting and email sit with one company, upkeep is simple but one account carries everything. When they sit with three companies, each account needs its own recovery path. Practical suggestion: keeping the domain registration apart from the host leaves you in control of the name if the host fails. A very small team that cannot track several accounts may be safer with one. Either way, the registrant should be the organisation, and at least two people should have a recovery route. Table: Situation and suggested move.
| Situation | Suggested move |
|---|---|
| One person runs everything | Keep one account and add a second administrator |
| Host is with an agency, domain is yours | Request DNS changes in writing and keep your own record list |
| Domain sits in the agency's account | Ask for access or a transfer into the organisation's account |
| A hosting switch is coming | Lower the TTL and export the records |
Example scenario: a neighbourhood cinema club
Example scenario: A volunteer-run cinema club has a site for its screening calendar and membership form. A volunteer who left two years ago registered the domain with a personal email. Renewal notices go to that dead mailbox, and the card on file is the volunteer's.
The recovery order is clear. First, contact the former volunteer and ask for access to the registrar account or for the name to be moved into the club's account. Second, update the registrant details to the club, after asking the registrar whether this triggers a sixty-day lock. Third, set up automatic renewal with the club's payment method and route reminders to two committee members. Last, copy the DNS record list into the club's shared notes.
What the scenario shows
The failure was about ownership and contact, not about servers. The membership form worked until the day it did not, and nobody in the club knew where to look.
Triage by symptom
Domain problems look alike from the outside. Going to the right layer first prevents a wrong edit that makes things worse. Table: Symptom, first place to look and second step.
| Symptom | First place to look | Second step |
|---|---|---|
| Site will not load | Expiry and status in the registrar panel | A record and name servers |
| Email stops | MX records | Was a name server changed |
| Search Console verification dropped | TXT or CNAME verification record | Deleted, or edited in the wrong panel |
| Transfer will not start | Registrar lock | Authorization code and recent registrant change |
| No renewal notices | Contact address on file | Spam folder and domain filters |
The site does not load
Confirm in the panel that the name is still in your account and not expired. If it has expired, ask the registrar about renewal or restoration first. If the term is fine, check whether the A record points to the right address and whether the name servers belong to the provider you expect. Only after both answers should you contact the host.
Email stops arriving
MX records point to the mail server. They disappear when someone cleans the zone carelessly or when name servers change and the new provider never received the old records. Before any name server change, list every record, not only the ones for the website.
You cannot log in
Follow the registrar's own account-recovery process; it differs between companies and is documented by each. Practical suggestion: add a second administrator and test the recovery route once a year.
A record changed and nobody admits it
Compare the record list with your last saved copy. If a colleague or agency made the edit, ask for the reason in writing. If nobody did, change the account password, switch on two-step verification and tell the registrar's support. A lock removed, a code requested or registrant details altered are more serious signs, so secure the account and the lock first.
Handover notes and a checklist
Good upkeep lives on paper, not in one person's head. A single page is enough: registrar name and login address, the account owner and the second administrator, the expiry date, the name server list, what each DNS record is for, the verification records that must not be deleted, and the date of the last check. Add a dated line whenever something changes. When the work moves to an agency, a new hire or a buyer, hand that page over.
Two-person rule for DNS edits
Practical suggestion: let one person apply a DNS or name server change and a second person compare the record list before and after. In a small club, that can be the treasurer and the volunteer who runs the site.
Yearly calendar
Table: Yearly upkeep calendar. Adjust the dates to your own expiry.
| When | Check |
|---|---|
| About two months before expiry | Confirm the payment method and automatic renewal |
| One month before expiry | Confirm that reminder emails reach the right people |
| After renewal | Read the new expiry date from the panel |
| Every six months | Review contacts, lock status and the DNS record list |
| Before a host or email provider change | Lower the TTL and export the records |
Checklist
- The registrant field names the organisation.
- Reminders go to a mailbox that two people read.
- Automatic renewal is on and the payment method is current.
- The expiry date was read from the panel and is in the calendar.
- The transfer lock is on and the authorization code is stored safely.
- You know which panel holds the DNS records and the list is exported.
- The verification records that must stay are written down.
- The TTL is lowered if a host change is planned.
Read the whole list once a year, ahead of the expiry date. If even one item cannot be ticked, write down who will close it and by when, in the same notes file. A list with gaps only shows its value when something has already gone wrong.
Frequently Asked Questions
Should I buy a domain from a registrar or from my hosting company?
Either works. What matters is that the registrant is your organisation and that renewal notices reach a mailbox you read. Keeping the two apart gives you more freedom if the host fails, while a single company is simpler to track.
If automatic renewal is on, is there anything else to do?
Yes. ICANN's page says you must keep payment information current if you choose automatic renewal. Confirm in the panel that the renewal went through and read the new expiry date.
Why do my contact details matter?
ICANN's page expects accurate information in directories such as WHOIS, prompt updates when it changes and answers to registrar inquiries within fifteen days. Notices and verification messages go to those addresses.
How do I know where to change a DNS record?
Look at which name servers the registrar lists for the domain. If they belong to your host, edit the records there. If they belong to the registrar, edit them in the registrar panel.
How long is the grace period after expiry?
RFC 3915 leaves the length of grace periods to each registry's operational policy. Your registrar's agreement and the extension's rules decide the real figure.
Does domain management affect SEO?
If the site becomes unreachable, DNS is wrong or verification records are deleted, visitor access and Search Console ownership checks can suffer. That is an availability condition, not a ranking promise.
Conclusion
Domain management comes down to knowing who holds the name, keeping renewal and contact details alive, knowing where the DNS records are kept, and protecting the lock and the code. None of it is a one-off task; a yearly routine turns surprises into scheduled checks. The three fastest improvements are to put the organisation's name on the registrant record, route reminders to two people and export the DNS records. Expiry stages, transfer rules and DNS details differ by registrar and extension, so confirm them in your own agreement.
Once the name is settled and you are ready to publish, our guest post service can place articles that introduce your site in context.
Post a comment
Please log in to leave a comment. Login