Pointing your nameservers, and what propagation really means

A nameserver tells the internet which company holds the authoritative DNS records for your domain. A DNS record then tells that company what to do with a particular kind of traffic: which server serves your website, which server accepts your mail, which service can prove it sent that email. Your site is usually still not showing because those two layers haven't caught up with each other, because a record is missing from the new zone, or because the change genuinely hasn't reached every resolver checking your domain yet. "Wait 24 to 48 hours" doesn't tell you which of those three you're looking at, which is why it's a poor answer on its own.

Before you start

This picks up from having a Hostworld hosting account or VPS ready to receive traffic: web space on cPanel, or a server you've built in Virtualizor. This guide covers pointing an existing domain at that hosting, whether the domain is registered with Hostworld or somewhere else entirely.

• You need access to wherever the domain is registered. If that's Hostworld, that's your account at portal.hostworld.uk. If it's another registrar, you'll need the login for that registrar's own control panel: nameservers can only ever be changed at the domain's registrar of record, not at Hostworld, regardless of where the domain is hosted.
• If you already have email running on the domain, note down every existing DNS record before you change anything, especially MX, SPF, DKIM and any hostnames your mail provider uses. This is the step people skip, and it's the one that causes an outage rather than a delay.
• Know that changing nameservers cannot delete your existing email or website files. Your mailboxes and messages live on the mail server, not in DNS, so repointing a domain is not a data-loss risk. It can, however, cause a genuine interruption if the new zone isn't ready for it, which is what the next few steps are about avoiding.

Step 1: Understand what a nameserver actually does

Think of a nameserver as the address of the office holding your domain's paperwork, not the paperwork itself. When you set a domain's nameservers, you're telling every resolver on the internet "ask this company for the current DNS records," nothing more. Changing nameservers doesn't edit or delete any record sitting in your old zone: it simply stops anyone asking that zone the question. The records themselves, MX, A, TXT and the rest, live inside whichever zone is currently authoritative, and only that zone gets consulted from the moment the new nameservers take effect.

This matters because a new nameserver's zone starts empty unless you've populated it first. It isn't a merge of old and new. It's a handoff. Anything that existed only in the old zone and wasn't copied across effectively stops existing as far as the internet is concerned, even though nothing was actually deleted anywhere.

Step 2: Copy every existing record before you touch the nameservers

Before you go anywhere near the nameserver fields, write down or export what's currently live: the MX records that route your mail, the SPF and DKIM TXT records that prove your mail is legitimate, and any other CNAME or A records a mailbox or third-party service depends on. Most registrar and DNS panels have an export or a simple list view; a screenshot is fine if that's all that's on offer.

Skip this and the failure mode is immediate, not gradual. If the new zone has no MX record the moment the nameservers switch, incoming mail doesn't queue and retry, it bounces straight back to the sender. This is the single most common cause of "my website works but my email's gone" after a nameserver change, and it's entirely avoidable with five minutes of preparation.

Step 3: Build the new zone before you switch

With your existing records written down, recreate them in the DNS zone you'll actually be using once the domain points at Hostworld, before the nameservers change. If your hosting is on cPanel, that's done in the Zone Editor while the domain still uses its old nameservers: you can add records to a zone that isn't live yet without anything breaking, because nothing is reading it until the switch happens.

The rule worth remembering is simple to state even if it takes a little discipline to follow: copy records first, switch second. Do it in that order and there's no outage window at all. Do it the other way round and you're relying on how quickly you can fix things after mail has already started bouncing.

Step 4: Point the domain at Hostworld's nameservers

Once the new zone is ready, set the domain's nameservers to:

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

Where you enter these depends on where the domain is registered:

• Registered through Hostworld: the nameserver fields sit under the Domains area of your account at portal.hostworld.uk, alongside the domain's other details. Enter the four values above and save. WHMCS checks the registrar live each time you view the page, so what you see is the domain's current state, not a stale local copy, and it submits your change to the registrar in the background rather than storing it only on our side.
• Registered elsewhere: log in to that registrar's own control panel and find the section for nameservers or DNS management on the domain. Every registrar labels it slightly differently, but it will be somewhere in the domain's own settings. Enter the same four values there.

For the exact click-by-click if your domain sits in your Hostworld account, see changing your nameservers in your Hostworld account. This guide covers the reasoning and the checking; that one covers the screens.

Step 5: Know what happens after you save, because it isn't a broadcast

There's no mechanism in DNS that pushes your change out to resolvers around the world. What exists is a distributed caching system with an expiry clock. Every resolver that has previously looked up your domain has cached the old answer for a length of time set by that record's TTL (time to live). It carries on serving that cached answer, correctly, until the TTL runs out, then it asks the authoritative server again and gets your new value.

That's the whole of what "propagation" means: not travel, but expiry. It follows that how long it takes depends almost entirely on the TTL that was set on the old records, not on a fixed industry figure:

The nameserver record itself is the one exception worth knowing about. Because it's also cached at the registry level above your registrar, a full nameserver change can genuinely take up to 48 to 72 hours to be visible everywhere, longer than an ordinary record change on an established zone. That's a real technical reason, not an excuse, which is exactly why it's worth checking properly rather than just waiting it out.

One thing worth avoiding while you wait: don't keep editing the records. Each edit resets the caching clock for that record and can make the visible delay longer, not shorter. Set the correct values once, confirm them, then leave the zone alone.

Step 6: Check propagation properly instead of guessing

Refreshing your browser tells you nothing useful, because your own machine and your own ISP have cached the old answer too. To see what's actually happening, query DNS directly.

From a terminal, check what your own resolver currently sees:

dig yourdomain.com

The ANSWER SECTION shows the record currently being served. If it doesn't match what you set, either it hasn't propagated to that resolver yet, or there's an error in the zone.

Then check against a resolver you know hasn't cached anything of yours before, such as Google's public DNS:

dig @8.8.8.8 yourdomain.com

If that comes back with your new values, the change has genuinely gone live and any remaining delay is just other resolvers catching up. If it still shows the old provider, either the nameserver change hasn't reached the registry yet, or it hasn't been set correctly at the registrar.

For a wider view across many locations at once, a free checker such as whatsmydns.net is a quicker way to spot regional gaps than querying resolver by resolver. A green tick means that location's resolver has picked up the new record; a cross means it's still serving the old one.

If you want to see past the caching layer entirely and check what the authoritative server is actually serving, right now, use:

dig +trace yourdomain.com

This walks the full delegation chain rather than asking a cache. It's the way to answer the question that actually matters when something looks wrong: is this still caching somewhere, or is the authoritative answer itself wrong? If the authoritative server is serving an incorrect record, no amount of waiting will fix it, because propagation only ever spreads what's actually there. That distinction is the whole point of checking properly rather than being told to wait: a genuine misconfiguration, a nameserver typed wrong at the registrar, a missing record, a mismatch, will look identical to normal propagation right up until you check the authoritative answer directly.

What next

Once dig @8.8.8.8 shows your domain resolving to Hostworld and mail is flowing to the records you recreated, the domain is fully pointed at us and there's nothing left to wait for. If you're setting this up for a VPS you manage in Virtualizor rather than cPanel hosting, our VPS guides cover what to do once the domain resolves, including the Linux VPS range if you're building the server itself from here. If you've followed every step above and a record still won't resolve correctly against the authoritative nameservers, that's not a propagation problem to wait out: open a support ticket and we'll check the zone directly.