How to point your domain at Hostworld

If your domain is registered with GoDaddy, 123 Reg, Namecheap, IONOS or anyone else, and your hosting is with Hostworld, you point the domain at us by changing its nameservers at the registrar to ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk and ns4.serverworld.uk. That single change hands control of the domain's DNS over to Hostworld. Everything else in this guide is about doing it without taking your website or your email offline while it happens.

What changing nameservers actually does

A domain's nameservers tell the internet which servers hold the authoritative answers for that domain: the A record for the website, the MX records for mail, the TXT records for SPF and DKIM, and everything else. That collection of records is called the zone.

When you change the nameservers, you are not redirecting the website. You are moving the whole zone. GoDaddy describes this plainly in its own documentation: with its nameservers, the zone file lives in your GoDaddy account, and with someone else's nameservers it lives in that company's account instead. 123 Reg says the same thing from the other side: once you delegate away, you can no longer configure DNS for that domain in its control panel.

So after you point the domain at ns1 to ns4.serverworld.uk, the records that matter are the ones in your Hostworld account, not the ones you have been editing at the registrar. If your mail is on Microsoft 365 or Google Workspace, and those MX records only exist at the old registrar, your mail stops working the moment delegation lands. That is the single most common way this goes wrong, and Steps 2, 5 and 6 exist to prevent it.

One point of confusion worth clearing up now: the domain's nameservers, set at the registrar, are not the same thing as the NS records inside a zone. Editing an NS record in a DNS panel does not change the delegation. They are separate operations.

Before you start

• Your hosting must be ready. Files uploaded, database restored, the site working. If you delegate before the new home is ready, visitors get whatever your Hostworld account is currently serving, which is usually a default page.
• You need a full copy of your current DNS records. Every A, CNAME, MX and TXT record, with its value and TTL. Screenshots are fine. Without this, rebuilding the zone is guesswork.
• You need to know whether DNSSEC is switched on. This is the one that takes a domain completely offline rather than partially. See Step 3.
• The domain may need unlocking. Some registrars, 123 Reg among them, require the domain to be unlocked before a nameserver change. Registrar lock behaviour is not consistent between companies: some block nameserver edits, some only block transfers. Check yours rather than assuming.
• Expect a window where things are inconsistent. A nameserver change commonly takes effect within an hour but can take up to 48 hours to reach every resolver worldwide. During that window some visitors reach Hostworld and some reach the old server.
• Certificates may need attention. Depending on how your SSL certificate is issued and validated, moving DNS can mean it needs reissuing, because both HTTP and DNS validation depend on the domain resolving to the right place.

If any of that is unclear for your particular setup, open a support ticket before you touch the registrar rather than after.

Step 1: Get the Hostworld side ready

On shared, reseller and WordPress hosting, that means the site is in place in your Hostworld cPanel account and the domain exists on that account. If the domain is not the primary domain of the cPanel account, add it as an addon domain first. Otherwise delegation succeeds and visitors land on a default page or the wrong site, and you spend an afternoon blaming DNS for something that is not DNS.

If your hosting is a Hostworld VPS, the shape of this is different depending on whether you are running your own DNS on the server or using ours. Virtualizor manages the VPS itself, not your DNS zone. If you are not certain which applies to your VPS, ask us on a ticket before delegating.

Step 2: Write down every DNS record you currently have

Open the DNS management screen at your current registrar and record everything. Pay particular attention to:

• MX records, and their priority values.
• TXT records: SPF, DKIM selectors, DMARC, and any domain verification strings for services like Microsoft 365, Google Workspace or a CRM.
• CNAMEs used by mail providers (autodiscover, and DKIM selector CNAMEs in particular).
• Subdomain A records for anything that does not live on your main hosting.

These do not travel with the delegation. Nothing is copied across automatically. A host that publishes default records in its zone will start answering with those the moment the change lands, which is exactly why external mail breaks.

Step 3: Check DNSSEC, and disable it before you do anything else

DNSSEC signs your DNS answers cryptographically. Your registrar publishes a DS record in the parent zone that says, in effect, "answers for this domain must be signed with this key". If you move the domain to nameservers that do not hold that key, validating resolvers do not fall back gracefully. They return SERVFAIL. The website and the mail both vanish for anyone behind a validating resolver, which includes most large consumer ISPs and the public resolvers.

To check: query the domain for a DS record. If one comes back, DNSSEC is active and this step applies to you. If nothing comes back, carry on to Step 4.

dig DS example.co.uk +short

On Windows without dig installed, you can use:

nslookup -type=DS example.co.uk 1.1.1.1

If DNSSEC is active, the order matters and most of it is waiting rather than clicking:

1. Turn DNSSEC off at the registrar first, so the zone stops being signed. Leave the DS records where they are for now.
2. Wait before you remove anything from the parent zone. Note the TTL the DS records carry and allow at least one full DS TTL, preferably 1.5 times that. Google's DNS documentation is blunter about it: allow 24 hours or longer, depending on registrar, registry and resolver behaviour.
3. Now remove the DS records from the parent zone.
4. Wait again for that removal to clear resolver caches, then re-run the DS query above and confirm nothing comes back.
5. Only then change the nameservers.

Doing steps 1 and 3 together in one sitting is where people get caught, because the DS record can still be cached and treated as valid while the delegation moves underneath it. Some registrars also enable DNSSEC by default on domains they manage, so do not assume you never switched it on. Check.

Step 4: Lower your TTLs a few days ahead

This one is optional and it only helps if you plan in advance. A few days before the move, lower the TTL on your existing records at the old provider. Shorter TTLs mean resolvers hold the old answers for less time, so the change settles faster. Put them back up afterwards.

If you are moving today, skip this. It does nothing retrospectively.

Step 5: Rebuild your DNS records in cPanel before you delegate

Build the zone at Hostworld first and delegate second. A cPanel zone is inert until the domain's nameservers point at us, so you can enter every record now with no effect whatsoever on your live site or your live mail. If you leave this until after the nameserver change, there is a window in which our default records answer for the domain, mail is routed to the wrong place, and the outage this guide is meant to prevent happens anyway.

On web hosting, this happens in your Hostworld cPanel account under Domains and then Zone Editor. Find the domain, click Manage, and you get the full record set with options to add, edit and delete. Work through the list you saved in Step 2 and recreate anything that is not already correct, especially MX and TXT records for external mail.

Three things to know about the Zone Editor before you start typing:

• Trailing dots matter. A record value ending in a full stop is fully qualified. Without it, the zone's own domain gets appended, so mail.example.net becomes mail.example.net.example.net, which resolves to nothing. cPanel displays the trailing dot in the Name column but not always in the Record column, which misleads people.
• Reset Zone is destructive. It deletes records you added and reverts records you changed back to defaults, including a customised MX. Avoid it unless you intend exactly that.
• The zone does nothing until delegation lands. Records here are only used once the domain's nameservers point at us. This is the answer to "I added the A record and nothing happened", and it is also why building the zone early is safe.

Step 6: Set email routing correctly

Do this before the nameserver change as well, for the same reason. If your MX records point at an external mail provider, you must also set cPanel's Email Routing, in the Email section, to Remote Mail Exchanger for that domain. Left on Local Mail Exchanger, the Hostworld server sees mail for the domain, decides it is the destination, and delivers into local mailboxes. The mail never leaves the server and never reaches Microsoft 365 or Google Workspace. Nothing bounces, which makes it harder to spot.

Keep your old mail service active for 48 to 72 hours after you delegate, so anything delivered to the old server during propagation is not lost. Expect inconsistent delivery for the first 4 to 24 hours: some senders still hold cached records and their mail genuinely arrives at the old destination. That split is normal. The wrong response is to keep flipping records back and forth, which extends the confusion. Check, wait, check again.

Step 7: Change the nameservers at your registrar

With the zone built and routing set, this is the step that actually moves the domain. Whatever the panel looks like, you are doing the same three things: find the domain, find the nameserver setting, and replace the registrar's default nameservers with all four of Hostworld's.

ns1.serverworld.uk
ns2.serverworld.uk
ns3.serverworld.uk
ns4.serverworld.uk

Enter all four. Some forms show four slots, some show two and make you add rows.

GoDaddy

Sign in and open your Domain Portfolio, select the individual domain to reach its domain settings, then go to DNS and then Nameservers. Choose the option to use your own nameservers, enter ours, save and then confirm to complete the change.

The step people get caught by: if Domain Protection is on the domain, you are asked to verify your identity before the change is accepted. That is a code from SMS or an authenticator app if two-step verification has been enabled for at least 24 hours, otherwise a one-time password sent to the account email address. Have access to that inbox before you start.

123 Reg

Log in to the control panel, scroll to the Domains section on My Products and click Manage on the domain. From the Domain Portfolio page, click DNS and then Nameservers, choose Change Nameservers, select the option to use your own nameservers, enter ours and save.

Some customers are still on a legacy control panel. If your screen does not match, look for Change Nameservers under Advanced Domain Settings instead. If Domain Ownership Protection is enabled you will be asked for two-step verification or a one-time password emailed to the account address. 123 Reg's own documentation states that nameserver changes take 24 to 48 hours to become active, and that the domain must not be locked.

Namecheap

Sign in, open Domain List, click Manage next to the domain, find the Nameservers section and change the drop-down to Custom DNS. The form starts with two rows, so use Add Nameserver twice to get all four of ours in, one per line.

Then click the green tick to save. This is the most missed step on any registrar covered here. Typing the values and navigating away saves nothing at all.

IONOS

Select the domain, open the Name Server option under Actions, choose to use custom name servers, and fill in the fields. The form shows Name Server 1 and 2 as required with 3 and 4 optional: fill all four. There is a reset option that returns the domain to IONOS defaults if you need to back out, and the documentation allows up to 48 hours for the change to take effect everywhere.

Fasthosts, Names.co.uk, Gandi, UK2 and others

The principle does not change. Find the domain in the registrar's control panel, find the nameserver or delegation setting, and replace the defaults with our four hostnames. If you cannot find the setting, the registrar's own support documentation is the right place to look, because only they know their current interface. If you find the setting but are unsure what to put where, open a support ticket and we will confirm the values with you.

Step 8: Verify the change

Do not judge this by loading the website in your own browser. Check what the internet is actually being told.

dig NS example.co.uk +short
dig example.co.uk A +short
dig example.co.uk MX +short

On Windows:

nslookup -type=NS example.co.uk
nslookup -type=MX example.co.uk

A public propagation checker such as whatsmydns.net shows you what resolvers in different countries are returning, which is more useful than a single local answer. If you want to test the site on Hostworld before DNS has settled, a hosts file entry forces your own machine to resolve the domain to the new IP address. Remove it afterwards, because only you see that, and forgetting it causes weeks of confusion later.

If it has not worked

• Registrar shows the new nameservers but DNS still returns the old ones. Normal during propagation. Query the TLD's authoritative servers to confirm the registry has the update, then wait for caches to expire.
• SERVFAIL, or a response with no answer section. That is the signature of DNSSEC validation failing. Go back to Step 3.
• Website loads but mail has stopped. Check the MX records in the Zone Editor and check Email Routing is set to Remote Mail Exchanger.
• Site resolves to Hostworld but shows the wrong content. The domain probably is not attached to the cPanel account as a primary or addon domain.
• Still broken after 48 hours. Open a support ticket with the domain name, the registrar and what you are seeing. We can look at what Hostworld's nameservers are answering for you.

Country-code and registry quirks

A few registries do not process nameserver changes immediately. A .it change is reviewed by the .it registry, which can approve or reject it and can take up to five business days. Namecheap documents others: .cm locks for 28 days after three nameserver changes within 28 days, .is requires at least two nameservers that do not resolve to the same IP address with the zone already configured, and .mx accepts a maximum of five nameservers. If your domain is on an unusual extension and the change appears to do nothing, check the registry's rules before assuming something is faulty.

What next

Once delegation has settled, the DNS for that domain is managed by Hostworld, so your next job is making sure the records are right rather than merely present. SPF, DKIM and DMARC are the ones worth getting correct early, because mail that leaves without them is the mail that ends up in spam folders.

If you are moving a domain onto a VPS rather than shared hosting, our VPS guides cover the server side of the job. For cPanel hosting, our web hosting pages explain what the account includes. And if anything in this guide did not match what you saw on screen, open a support ticket and we will take a look at the domain with you.