Pointing a domain at your hosting: DNS records and propagation
By Datafex Engineering TeamPublished 5 min read
When a hosting plan is provisioned the site is ready, but your domain still points at its old home. The layer that joins the two is DNS, and a wrong step here usually takes down not the site but the email. Below is the order to follow on the web hosting plans, and the checks not to skip.
There are two routes — do not mix them
There are two ways to attach a domain to your hosting, and the one you pick decides where you will manage the records from then on.
Changing the name servers. In the panel of the company you bought the domain from, you replace the name servers with the ones given on the hosting side. From that moment every record for the domain is managed in the DNS section of Plesk. The name server hostnames you need are shown in your hosting panel; read them there rather than guessing.
Keeping the records at your current DNS provider. The name servers stay as they are and you only repoint the A record to the hosting server's IP address. If you use a CDN, or your mail lives with another service, this route is safer because you never touch the other records. You will find the server's IP address in the domain card details in Plesk.
What each record does
| Record | What it does | What happens if you change it |
|---|---|---|
| A | Binds the domain to an IPv4 address | The site is served from the new server |
| AAAA | The same for IPv6 | Visitors on IPv6 are affected |
| CNAME | Binds one name to another, usually for www | The www address resolves where the root does |
| MX | Names the server that accepts mail for the domain | If it is wrong, incoming mail stops |
| TXT | Carries SPF, DKIM and verification records | Your outgoing mail starts landing in spam |
The fourth and fifth rows are where migrations do the most damage: a site that is down for a few hours gets noticed and reverted, while mail that never arrives gets noticed by nobody.
The order of the move
- A day before the move, take a copy or screenshot of every existing record. That list is the only thing you will have to fall back on.
- On the same day, lower the TTL of the records you are going to change (300 seconds, for instance). The TTL itself is cached for as long as its old value, which is why this has to be done early.
- Get the site ready to serve on the new server and verify it without touching DNS; do not change a record before the files and the database are in place.
- Repoint the A record to the new IP. If you are changing name servers, make sure before the switch that the MX and TXT records on the new side match the old ones.
- Leave the old hosting plan running for at least a week after the change. The last visitors and messages still land on the old server during that window.
- A week later, put the TTL back to a normal value such as 3600 seconds.
What "propagation" actually is
Contrary to the common belief, nothing spreads across the world. Intermediate resolvers keep the old answer in cache for the length of the TTL and ask again when it expires. So the wait is the TTL value that was in place before the change; lowering the TTL after you have already changed the record does nothing for it.
The 24 to 48 hours people quote comes from the resolvers that ignore the TTL and apply their own caching policy instead. A few hours is typical, but do not plan a launch on the assumption that it is guaranteed.
Can the domain stay with another company?
It can. The registrar of a domain and the place the site is hosted are independent of one another; you do not have to transfer the domain to buy hosting. Transfer it only when you want renewals and administration in one place, not in order to publish a site.
If you are going to transfer the domain, do not put it on the same day as the site move. Name servers usually carry over during a transfer, but the process can take days, and making two changes at once leaves you unable to tell which one caused a problem.
How to tell whether the change took
Opening the site in a browser is misleading: the browser and the operating system keep caches of their own. The right check is to ask for the record directly:
dig +short example.com A
dig +short example.com MX
nslookup example.com 1.1.1.1The third line asks a specific DNS server, which is the quickest way to bypass your own provider's cache. Different answers from different servers mean the change is still working through, not that something is broken.
The most expensive mistake
Changing the name servers at the registrar and forgetting to recreate the MX records on the new side. The site comes up perfectly, nobody notices anything, and incoming mail is quietly rejected the whole time. If your mail is staying with another service, copy the MX and the related TXT records over exactly before the switch; the panel-side mail setting that goes with it is covered in mailboxes and spam settings.
If you are pointing the domain at your own machine rather than shared hosting, the job does not end with an A record: reverse DNS, outbound mail and the firewall become yours too. On the virtual server side all of those are your responsibility.