How to point your domain to a new web host?

To point your domain to a new web host, get the new server's IP address (or the hostname the host gives you), then go to wherever your domain's DNS is managed and update the A record for the root domain (@) and the record for www to the new values. Leave your MX and email-related TXT records alone so mail keeps working, lower the TTL a day or so beforehand so the change spreads quickly, and test the new site before you switch. Most visitors will reach the new host within minutes to a few hours.

The alternative is to change your domain's nameservers to the ones the new host provides, which moves your whole DNS zone to them. That's a bigger change, and it's often not necessary. This guide focuses on the record-level approach: working out where your DNS lives, preparing the switch, testing the new site before anyone sees it, changing the records, and confirming everything worked, including HTTPS and email.

Two Ways to Point a Domain at a New Host

When a new host says "point your domain to us", they usually mean one of two things:

Approach	What you change	Where	Effect
Update records	A, AAAA, CNAME for the website	Your current DNS provider	Only the website moves. Email and other records stay as they are
Change nameservers	The domain's NS delegation	Your registrar	The new host manages all your DNS, including email records

Updating records is lower risk. You keep full control of the zone, and email, verification records and any other services are untouched. Changing nameservers can be convenient if the new host bundles DNS with hosting, but you must recreate every existing record on the new host first, or things like email will break.

If your host gives you a choice, prefer updating records unless you have a reason to move DNS.

Step 1: Find Out Where Your DNS Is Managed

Your domain's DNS isn't necessarily managed where you bought the domain. Check which nameservers are in use:

dig +short example.com NS

ns1.oldhost.example.net.
ns2.oldhost.example.net.

On Windows:

Resolve-DnsName example.com -Type NS

The nameserver names usually reveal the provider. Common patterns include names ending in cloudflare.com for Cloudflare, awsdns for Amazon Route 53, domaincontrol.com for GoDaddy, and registrar-servers.com for Namecheap. If they point at your old web host, be careful: when you cancel that hosting account, the DNS may disappear with it. In that case, move DNS to a neutral provider or to your registrar before you cancel.

Step 2: Record What You Have Now

Before changing anything, write down your current records. At minimum, capture these:

for type in A AAAA CNAME MX TXT CAA; do
  echo "== $type"
  dig +short example.com $type
  dig +short www.example.com $type
done

Most DNS dashboards also have an export option that downloads a zone file. Keep that copy somewhere safe. If something goes wrong, you'll know exactly what to put back.

Pay attention to:

• MX records: These route your email. They shouldn't change when you move your website.
• TXT records: SPF, DKIM, DMARC and verification records for services such as Google, Microsoft and analytics tools.
• Other subdomains: mail, shop, app, status and so on may point at services that aren't moving.

Step 3: Get the Target From Your New Host

Your new host will give you one or more of these:

• An IPv4 address, for example 203.0.113.25, for an A record.
• An IPv6 address, for example 2001:db8:25::1, for an AAAA record.
• A hostname, for example sites.newhost.example.net, for a CNAME record.

Use exactly what they provide. Platform hosts such as Vercel, Netlify, Shopify and others often give you an IP or special record for the root domain and a CNAME target for www, because a CNAME can't be used at the root of a domain unless your DNS provider supports CNAME flattening or ALIAS records.

If the old host gave you an AAAA record and the new host doesn't support IPv6, you'll need to delete the old AAAA record. Otherwise visitors on IPv6 networks will keep reaching the old server.

Step 4: Lower the TTL in Advance

The TTL (time to live) on a record tells resolvers how long they can cache it. If your A record has a TTL of 86,400 seconds (one day), some visitors could keep seeing the old site for up to a day after you change it.

Lower the TTL on the records you're about to change to 300 seconds (five minutes), then wait at least as long as the old TTL before switching. If the TTL was one day, make the change a day in advance.

Check the current TTL with:

dig example.com A +noall +answer

example.com.        86400   IN  A   198.51.100.10

The second column is the TTL in seconds. Once the migration is stable, you can raise it again.

Step 5: Test the New Site Before Switching DNS

You don't need to wait for DNS to see whether your site works on the new host. You can make your own computer, or a single command, use the new IP while everyone else still sees the old one.

Test With curl

The --resolve option tells curl which IP to use for a hostname, without touching DNS. It also sends the right Host header and SNI name, so HTTPS works if a certificate is already installed:

curl -sI --resolve example.com:443:203.0.113.25 https://example.com/
curl -sI --resolve www.example.com:443:203.0.113.25 https://www.example.com/

If the certificate isn't issued yet, you can test over HTTP instead:

curl -sI --resolve example.com:80:203.0.113.25 http://example.com/

Test in a Browser With the Hosts File

To browse the site properly, add a temporary entry to your hosts file.

On macOS and Linux, edit /etc/hosts:

sudo nano /etc/hosts

Add:

203.0.113.25  example.com www.example.com

On Windows, open Notepad as Administrator and edit C:\Windows\System32\drivers\etc\hosts with the same line.

Browse the site, log in, submit a form, and check images and links. Remove the line when you're done, otherwise you'll keep seeing the new host even if DNS is wrong, which hides problems.

Step 6: Update the DNS Records

Log in to your DNS provider and edit the website records. A typical end state looks like this:

example.com.        300   IN  A      203.0.113.25
example.com.        300   IN  AAAA   2001:db8:25::1
www.example.com.    300   IN  CNAME  example.com.
example.com.        3600  IN  MX     10 mx1.mailprovider.example.net.
example.com.        3600  IN  TXT    "v=spf1 include:spf.mailprovider.example.net -all"

In a typical dashboard, that means:

1. Edit the A record with name @ (or blank) and change its value to the new IP.
2. Edit or delete the AAAA record depending on whether the new host supports IPv6.
3. Edit www: either point it at the root with a CNAME, or give it its own A record, or use the CNAME target your host specified.
4. Leave MX, TXT, and unrelated subdomains alone.

Don't create a second A record alongside the old one. Two A records for the same name means visitors are spread between both servers at random. Edit the existing record instead.

Updating Records With an API

If your DNS host has an API, you can script the change, which is useful for scheduled cutovers. Here's an example with the Cloudflare API, where you first look up the record ID and then update it:

RECORD_ID=$(curl -s \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?type=A&name=example.com" \
  -H "Authorization: Bearer $CF_API_TOKEN" | jq -r '.result[0].id')

curl -s -X PATCH \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"content": "203.0.113.25"}'

And with the AWS CLI for Route 53:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEFGHIJ \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{"Value": "203.0.113.25"}]
      }
    }]
  }'

Step 7: Verify the Change

First, ask your authoritative nameserver directly. This shows what your provider is now serving, with no caching involved:

dig @ns1.oldhost.example.net example.com A +short

203.0.113.25

Then check what public resolvers are returning:

dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
dig @9.9.9.9 example.com A +short

If some still return the old IP, they're serving a cached copy and will update when the old TTL runs out. That's why lowering it in advance matters.

Finally, confirm the site is coming from the new server. Many hosts add an identifying response header, or you can check which IP curl actually connected to:

curl -sI https://example.com/ -o /dev/null -w '%{remote_ip} %{http_code}\n'

203.0.113.25 200

Step 8: Sort Out HTTPS

Most hosts issue a free certificate automatically, but they can only do so once DNS points at them, because the certificate authority checks that the domain resolves to the host. Expect a short window, usually a few minutes, where HTTPS isn't ready yet. You can reduce this by:

• Using a host that supports pre-validation through a DNS TXT record, if offered.
• Making the switch at a quiet time of day.
• Checking your host's dashboard for certificate status straight after the change.

If you have a CAA record, make sure it allows the certificate authority your new host uses. A CAA record that only permits one CA will block others from issuing:

dig +short example.com CAA

0 issue "letsencrypt.org"

If your new host uses a different CA, add another issue entry for it.

Step 9: Keep the Old Host Running for a While

Don't cancel the old hosting account the moment DNS changes. Some resolvers and devices cache longer than they should, and if the old site disappears, those visitors see an error.

Keep the old host running for at least a few days, and avoid making content changes on it during that time, or freeze it in maintenance mode. If your site takes orders or user sign-ups, plan for data that might arrive on the old server during the overlap.

Common Problems After Switching

The Old Site Still Shows

Check whether it's DNS or your own machine. Ask a public resolver:

dig @1.1.1.1 example.com A +short

If that shows the new IP, flush your local DNS cache and browser cache, and check that you removed any hosts file entry. On macOS, for example:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

The Site Works but www Doesn't (or the Reverse)

The root and www are separate records. Check both:

dig +short example.com A
dig +short www.example.com

Also make sure the new host has both names added to your site's settings. Many platforms only serve the hostnames you've explicitly attached.

Email Stopped Working

You probably changed or deleted MX records, or you switched nameservers without recreating them. Compare against the backup you took in Step 2:

dig +short example.com MX

Some Visitors See the New Site and Others the Old One

Look for a stale AAAA record pointing at the old host, or a duplicate A record. Both cause split traffic.

---

FAQ: Pointing a Domain to a New Host

---

Conclusion

Pointing your domain to a new web host is mostly about changing two or three records: the root A (and AAAA if supported) and www. The work that makes it smooth happens beforehand: knowing where your DNS is managed, backing up the existing records, lowering the TTL, and testing the new site with curl --resolve or your hosts file before anyone else sees it.

After the switch, verify against your authoritative nameserver and a few public resolvers, check that HTTPS is issued and that both the root and www work, and leave email records untouched. Keep the old host running for a few days, and you'll have moved your site without visitors noticing anything at all.