How to Point a Domain to Hosting: A Record, CNAME or Nameservers

Crawvix Editorial Team · Published November 4, 2026 · Last updated November 4, 2026 · 11 min read

A domain name plate with three arrows converging on a hosting server box that has a green tick.

You bought a domain at one company and a website plan at another. Now the domain shows a parking page or an error, and your host's setup screen says "connect your domain" without saying how. Knowing how to point a domain to hosting comes down to one choice: which of three ways to tell the internet where your site lives. Pick the wrong one and you can lose your email along the way.

This guide is for site owners and small teams who manage their own domain. It explains the three methods (an A record, a CNAME record, or changing nameservers), shows how to choose between them, and walks through the change in an order that keeps the old site working until the new one answers. You will finish with the domain and the www name both reaching your host, and a way to prove it from the command line.

It does not cover buying a domain or transferring it between registrars. For what each record type means, see DNS Records Explained: A, AAAA, CNAME, MX and TXT for Your Launch.

Short answer: To point a domain to hosting, either add an A record (to an IP address) or a CNAME (to a hostname) at your current DNS provider, as your host instructs, or change the domain's nameservers at the registrar to your host's. Use records if you want to keep your DNS where it is; use nameservers only if the host will manage the whole zone.

Before you begin

You need three things: login access to the registrar (where the domain is registered), login access to wherever DNS is edited today, and the connection details from your host. The last one is the key. Hosts publish either an IP address, a hostname such as sites.host.example, or a pair of nameservers. Use the values from your own host's current instructions; they differ between providers and change over time.

The registrar and the DNS host are often the same company, but not always. If the nameservers already point at a service such as a CDN, records are edited there. Step 1 shows how to tell.

Before touching anything, copy every existing record, especially MX and TXT. Export the zone if you can; otherwise take screenshots. Expect about an hour. The risk is moderate: a wrong record can take the site or email offline, and caches mean mistakes can linger.

How to point a domain to hosting: the three methods compared

Method What you change Where Best when Watch out for
A record (and AAAA) The IP address a name resolves to Your current DNS provider Your host gives you a fixed IP address If the host changes the IP, your site breaks until you update it
CNAME record An alias from one name to another Your current DNS provider Your host gives you a hostname, usually for www A plain CNAME is not allowed at the bare domain
Nameservers Who answers every DNS question for the domain The registrar The host or a CDN will manage all your DNS Records not copied across are lost, including email

An A record says "this name is at this IPv4 address" (AAAA does the same for IPv6). A CNAME says "this name is another name for that one". Nameservers are a delegation, not a record about your site: the registrar tells the world which servers are authoritative for the whole domain, and those servers hold every record. RFC 1034 describes NS records as naming the servers for a zone, which is why changing them moves everything at once.

Why can't I use a CNAME on the bare domain?

The bare domain (the "apex", such as example.com) must also carry NS and SOA records. RFC 1034 says that if a CNAME is present at a node, no other data should be present, and RFC 2181 repeats that a name with a CNAME may have no other data apart from certain DNSSEC types. So a plain CNAME at the apex conflicts with the records that must be there.

Providers work around this with an ALIAS or ANAME record, or CNAME flattening, which Cloudflare describes as returning the target's address instead of the CNAME. Netlify tells external-DNS users to use an ALIAS at the apex if their provider supports one and an A record if not. Read your own provider's documentation to see which you have.

Which method should I choose?

Work down this list and stop at the first line that applies.

  1. Your host requires nameservers. Some platforms only support full DNS delegation. Check that you cannot use records, because nameservers affect email and everything else too.
  2. Your host gives a hostname for the apex and your DNS provider supports ALIAS, ANAME or flattening. Use that for the apex, and a CNAME for www.
  3. Your host gives a hostname only. Use a CNAME for www, and redirect the bare domain to www at your DNS or registrar if the host cannot serve it.
  4. Your host gives an IP address. Use an A record for the apex and either an A record or a CNAME to the apex for www.

Netlify recommends www as the primary domain with external DNS, citing apex resolution limits; that is one vendor's advice. Choosing the primary address is covered in WWW vs Non-WWW: Choose One Canonical Host and Redirect the Other.

Step-by-step instructions

Step 1: Find out where DNS is actually managed

Ask the nameservers directly:

dig +short NS example.com

If the answer names your registrar or a hosting company, edit records there. If it names a CDN or DNS service, edit records in that service. Without dig, Google's Admin Toolbox has a browser-based Dig lookup.

What success looks like: You know the single place where the A, CNAME and MX records for this domain are edited, and you can log in there.

Step 2: Collect the exact target from your host

Open your host's domain-connection page and write down the record type, name and value it asks for. Some hosts want the domain added in their dashboard first; Netlify's instructions say to add the custom domain to the project before configuring external DNS.

What success looks like: A written list such as apex: A 203.0.113.10 and www: CNAME sites.host.example, copied from the host.

Step 3: Lower the TTL and save the old records

TTL is how many seconds a resolver may keep an answer. Lower it to a short value your provider allows (for example 300 seconds) and wait for the old TTL to pass before the real change. Save the old values so you can paste them back.

What success looks like: The TTL on the records you will change is short, and a copy of the old zone is saved.

Step 4: Make the change for the method you chose

For records, edit or create the entries at your DNS provider. A typical result looks like this, using documentation-only values:

example.com.      300  IN  A      203.0.113.10
www.example.com.  300  IN  CNAME  sites.host.example.

Remove any old A or CNAME at the same name first. Many panels add your domain automatically, so typing the full name can produce www.example.com.example.com. Leave MX and TXT records alone.

For nameservers, first recreate every record at the new DNS host, including MX and the TXT records for email authentication and Search Console. Cloudflare's guide warns that its automatic scan may not find every record and that activating a zone without the right records can leave visitors with a "DNS_PROBE_FINISHED_NXDOMAIN" error. It also says to turn off DNSSEC at the registrar before changing nameservers, because changing them while DNSSEC is active can make the domain unreachable. Then, at the registrar, replace the old nameservers with exactly the names the new host gives you.

What success looks like: The control panel shows the new records, or the new nameservers, saved without errors.

Step 5: Wait for caches, then query from outside

GitHub says DNS changes for Pages can take up to 24 hours to propagate. Cloudflare says to wait up to 24 hours for a registrar to update nameservers. Netlify says up to 48 hours. Treat these as vendor estimates; the real delay depends on the TTLs and caches involved. Query your provider's authoritative answer and a public resolver:

dig +short example.com A
dig +short www.example.com CNAME
dig @8.8.8.8 +short example.com A
dig +short NS example.com

What success looks like: Both your own query and the public resolver return the new IP address, hostname or nameservers.

Step 6: Check the site, HTTPS and redirects

Load the domain in a private browser window and run:

curl -I https://example.com/
curl -I https://www.example.com/

You want a normal success response on one name and a single redirect from the other. A certificate warning at this stage may mean the host has not issued a certificate yet; wait and recheck, and see SSL Certificate Errors: Diagnose Expired, Mismatched and Incomplete Certificates if it persists. To set up the redirect between the bare and www names, use Redirect www to non-www or Redirect non-www to www.

What success looks like: Both names load over HTTPS and one redirects to the other with a single hop.

Step 7: Confirm email and verification still work

Send a test message to and from an address on the domain. Check that your Search Console verification record is still present, because removing it can un-verify the property. After a nameserver change, compare the new zone with your saved copy, record by record.

What success looks like: Mail arrives, and Search Console still shows the property as verified.

Fixing a domain that still shows the old site or an error

The old site still appears

Your device or network resolver is probably serving a cached answer. Test with a public resolver as in Step 5 and try another network. If a public resolver also returns the old value, the change may have been saved at a DNS host that is not authoritative; recheck Step 1.

The browser says the domain cannot be found

No record exists at that name. After a nameserver change, the new zone is probably missing it. Add it there.

The host says the domain is not connected

Compare the record name, type and value with the host's instructions, and look for a doubled domain or a leftover old record. If a proxy or CDN sits in front, see Cloudflare SEO Settings That Help or Hurt Crawling.

One name works and the other does not, or email stopped

Usually only www or only the apex was set up, so add the missing one and redirect. If email stopped, the MX or TXT records did not come across; restore them from your saved copy.

Done carefully, connecting a domain to a new host is routine. The risks are practical: a period when the site is unreachable, a missing redirect, or a certificate error. If the domain itself is changing, that is a site move, covered in Change Your Domain Name Without Losing SEO and Website Migration SEO Checklist. After the cutover, work through Website Launch SEO Checklist: What to Verify Before You Go Live. Crawvix's scan checks from the outside that the domain resolves, the home page loads, HTTP redirects to HTTPS and you have at least two nameservers.

Final verification checklist

  • You know where DNS for the domain is edited, confirmed with an NS lookup.
  • The apex and www both resolve to the target your host gave you.
  • No CNAME shares a name with another record, and the apex uses an A record, ALIAS or flattening.
  • A public resolver and your own provider return the same answer.
  • Both names load over HTTPS, and one redirects to the other in a single hop.
  • MX and TXT records still match your saved copy, and a test email works.
  • If you changed nameservers, DNSSEC was handled as your DNS host instructs, and the Search Console verification record is still in the zone.
  • The old hosting stayed available until the new answer was visible everywhere you tested.

Common mistakes to avoid

  • Changing nameservers when a single record would do. Nameservers move all DNS, including email. Use an A record or CNAME unless the host requires delegation.
  • Switching nameservers before copying the records. Recreate everything first, and compare afterwards.
  • Putting a plain CNAME on the bare domain. Use an A record, ALIAS or flattening instead.
  • Editing DNS where the nameservers do not point. The change will not be served. Run the NS lookup in Step 1.
  • Typing the full domain into a panel that appends it. This creates a doubled name; enter only the label the panel expects.
  • Cancelling the old hosting immediately. Cached answers keep sending some visitors there. Keep it running until tests agree.

Frequently asked questions

How long does it take to point a domain to a new host?

The edit takes minutes; others seeing it depends on caches and TTLs. The hosts cited above quote 24 to 48 hours as an upper estimate. Test with a public resolver instead of waiting blindly.

Do I need to change nameservers to connect a domain to hosting?

Usually not. Most hosts accept an A record or CNAME at your existing DNS provider. Change nameservers only if the host or CDN requires it, and copy all records first.

Should I point the domain to an IP address or a hostname?

Use what your host gives you. A hostname lets the host change servers without you editing anything; a fixed IP means you must update the record if the host changes it.

Will pointing my domain to hosting delete my email?

Not by itself. Records for mail stay if you only edit the website records. A nameserver change can drop email if the MX records are not recreated, so copy them first.

Official references


Next step: Try the free website sample to see how your own site does on a few of these checks. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.

In this category

All 14 Launch guides