Point a domain at a hosting plan

A domain and a hosting account are two separate things, and connecting them is the step where most new sites stall. The DNS looks set, the hosting is running, and the domain shows a parking page or an error.

There are two ways to make the connection, and choosing between them is the whole decision. Everything after that is waiting.

The two ways

Point the nameservers at us. The domain keeps its registration where it is, and its DNS is handed to our nameservers. Every record then lives in one panel, ours, including the ones the hosting needs. This is the simpler arrangement and it is what we recommend when the domain is new or when nobody else is managing its mail.

Leave the DNS where it is and add records. The domain keeps using another provider's nameservers, and you add an A record pointing at the hosting address. Choose this when the DNS already does something you depend on, such as mail on Microsoft 365 or Google Workspace, and moving it would mean rebuilding all of that first.

Do not do both. Changing the nameservers and adding an A record at the old provider means the record you are looking at is not the record that answers.

If you point the nameservers at us

1. Open the domain in the domain manager in your toolbox.
2. Find the nameservers for the hosting plan. They are in the hosting welcome mail and in the plan's own details, and they are the same pair for every plan.
3. Replace the existing nameservers with ours, both of them.
4. Wait. The change is published within minutes and visible to resolvers as their caches expire, which is why the honest figure is up to 48 hours and often much less.

Once the nameservers answer, the hosting account supplies the records the site needs, including the ones for mail if you are using our mailboxes. That is the reason to prefer this arrangement, because the records and the hosting cannot drift apart.

If you keep the DNS where it is

1. In the hosting account, find the address the site should answer on. It is an IPv4 address, and it is the one to use for an A record at the apex of the domain.
2. Add an A record for @ pointing at that address. If the panel wants a hostname rather than @, the bare domain works too.
3. Add a CNAME for www pointing at the bare domain, so both spellings reach the same place.
4. Leave the mail records alone. An MX record and the SPF and DKIM records belong to whichever system handles the mail, and changing hosting has nothing to do with them.

The steps for a specific provider are in managing the DNS records for a domain, and the nameserver route is covered in changing the nameservers.

The three mistakes that leave a site unreachable

A second A record at the apex. Two A records for the bare domain means two addresses and no rule about which wins. A resolver picks one, often the wrong one, and the result is a site that loads for some visitors and not others. One A record at the apex.

The record was added at a provider that no longer answers. If the nameservers point somewhere else, the record you just added is in a zone nobody reads. Check which nameservers the domain actually uses before editing records.

An A record where a CNAME belongs, or a CNAME at the apex. The apex of a domain cannot carry a CNAME in practice, because it would collide with the SOA and NS records that have to exist there. Apex gets an A. Subdomains can use a CNAME.

How to check it is working

Look at the records as the rest of the world sees them, not as your panel shows them. The DNS lookup tool queries from five regions and shows what each one gets, which is how a partial propagation or a stale cache becomes visible instead of guessed at.

Then load the site with the domain in a browser, in a private window, so your own cache is not answering for you. A 404 from the hosting rather than from the domain means the DNS is right and the site is not published yet, which is a different problem with a different fix.