How to connect a domain to hosting, step by step - Zephyra Studio

Connecting a domain to hosting comes down to two approaches: change the name servers, or change individual DNS records. The first is simpler and hands control to the host. The second keeps DNS with the registrar and changes only what needs changing. If the site is new and you do not use the domain for e-mail yet, entering the host's name servers at the registrar is enough. If the domain also carries your mail, move only the A record and the www CNAME, and leave the MX records untouched. That is where the damage usually happens, and it is the kind that only shows when someone does not receive a message.

What actually changes: name servers or individual records

DNS is the directory that translates a domain name into a server address. That directory can live with the registrar or with the host, and that decides what you edit.

Name servers are the addresses of the machines that hold the whole directory for your domain. Change them to the ones your host provides and the host takes over every record, which you then edit in its own panel.

Individual records are the other extreme. Keep the directory at the registrar and change only the records that send traffic to the site. The A record maps the root domain to the server IP, the CNAME maps the www version, MX records carry mail, and TXT records hold verifications and mail rules.

The TTL is the number of seconds other machines may cache a record. Dropping it to five minutes before a change shortens the uncertain period, and it is raised again afterwards.

If you change the name servers

This is the fastest route and the usual one for new sites. Order matters, because the first step decides whether your mail survives the change.

• Write down the existing MX and TXT records before touching anything, because they belong to mail, not to the website
• Take the name server addresses from the host, usually two or three of them
• Ask the host whether it also manages mail or only the website, so you do not lose e-mail
• Enter the name servers at the registrar and wait; the change usually appears within hours and at most within two days
• Do not make the change on a Friday afternoon or before a holiday, because if something breaks nobody is around to fix it
• After the change, send a message from the domain address to another address of yours and reply back, since the site can work while mail is silent

DNS records worth sorting out now

Besides the records that carry traffic, a domain also holds records that decide how mail is sent. They are rarely touched, and their absence explains why messages from a website form or a campaign end up in the junk folder.

These four records are checked once and then forgotten until a delivery problem appears.

The values are not invented but copied from the instructions of the service that sends the mail. If Google or Microsoft handles the mail, their documentation contains the exact record content, which is simply typed into the registrar's panel.

If the site itself also sends messages, for example from a contact form, that server has to be listed in the SPF record as well. Without it some messages are rejected or land in spam, even when the address is correct and the message did reach the recipient.

• SPF, which lists the servers the domain has authorised to send mail in its name
• DKIM, which signs messages so the recipient can verify the content was not altered
• DMARC, which tells the recipient what to do with a message that fails the checks and where to report it
• The TXT record for ownership verification, usually for Google tools, which must stay in place after verification
• A CAA record, if you want to limit which authorities may issue a certificate for your domain

If you change only individual records

This route needs more attention but leaves mail alone. It is the one to use when the domain is years old and already carries mailboxes or another service.

• Edit the A record for the root domain and enter the IP address the host gave you
• Edit the CNAME for www so it points to the root domain or to whatever address the host specifies
• Leave MX records alone, they do not belong to the website
• Keep TXT records in place, because they often hold Google verifications and mail rules
• Lower the TTL to five or ten minutes a day before the change and raise it again after testing
• Test the site and the mail from another network, for example over mobile data, so you are not looking at your own machine's cache

What most often goes wrong

The most expensive mistake is a deleted MX record. The site works, everything looks fine, and messages quietly fail for weeks until someone calls to ask why they never get a reply.

The second is mixing the www and non-www versions. If both addresses work but lead to different versions of the site, Google sees two pieces of content. It is better for one to be the main address and the other to redirect to it permanently.

With Cloudflare or a similar proxy service, the A record points at their address rather than at the hosting server. That is correct behaviour, but it confuses anyone who checks the IP and does not see what they expect.

A certificate is issued only once the domain points at the hosting server, so it cannot be obtained before the DNS change. If the host is taking over both the site and the mail and you are unsure what is being changed, it is safer to have someone who has done it before handle it. Our hosting and domains service covers exactly that step, and it is worth running through our website launch checklist before going live.

Source

Key takeaways

• Changing name servers hands every record to the host; changing individual records keeps mail untouched.
• MX and TXT records do not belong to the website and must not be deleted when connecting a domain.
• A TTL lowered before the change shortens the period in which some visitors still see the old setup.
• Never make the change before a holiday or on a Friday, because mistakes need fixing immediately.
• Test the site and the mail separately, from another network, before calling the job done.

Conclusion

Connecting a domain to hosting is not hard, but it is the kind of job where a mistake does not show up immediately, only a week later. If the domain carries your mail, change only the records you must, and remember that MX records are not part of the website. On new projects we handle registration, DNS and setup together, so the first enquiry is never lost to a record nobody checked.