How to Point Your Domain Name to a New Host

You can switch hosts without breaking your site or your email.

Moving a website is less about files and more about DNS. You decide who publishes your DNS records, you set the right A, AAAA, and CNAME values, and you time the cutover so traffic flows to the new server with no visible downtime. This guide shows you the exact steps, explains why each step matters, and gives you clean rollback options if something goes sideways.

What “pointing a domain” actually means

When people say they’re pointing a domain to a new host, they’re doing one of two things:

Changing nameservers to a different DNS provider. That provider becomes the source of truth for the domain’s DNS zone.
Leaving nameservers as-is and only changing the DNS records inside the current provider to target the new web host’s IP or hostname.

Either path works. Your choice depends on who you want managing DNS long term, how many records you already maintain, and whether you want CDN or security features that require specific nameservers.

Nameserver change vs record-only change

Change nameservers when you want a different DNS provider, need CDN or security features tied to that provider, or you’re consolidating scattered DNS zones.
Keep nameservers and update records when your current DNS works fine, you have many custom records already in place, or you want the smallest possible change.

Quick glossary

Nameservers: The authoritative DNS servers for your domain. Registrars store and publish these.
DNS zone: The collection of records for your domain: A, AAAA, CNAME, MX, TXT, SRV, etc.
A / AAAA: Map a hostname to an IPv4 or IPv6 address.
CNAME: Alias one hostname to another hostname.
MX: Mail exchange records for email routing.
TXT: Freeform records used for SPF, DKIM, DMARC, and verification.
TTL: Time to live. How long resolvers cache a record before asking again. Lower TTLs help you switch faster.
DNSSEC: Cryptographic signing for your DNS to prevent tampering.

Cutover strategy that avoids downtime

You can move traffic safely if you prepare in the right order. Use this framework.

Step 1: Inventory the current DNS zone

List all existing records before you touch anything.

Export the zone file from your current DNS provider if the UI offers it.
Capture every record type on the apex (example.com) and on key subdomains (www, api, mail, ftp, staging, cp, webmail, autodiscover, s1, s2).
Pay attention to email: MX, SPF (TXT), DKIM selectors (TXT like s1._domainkey), and DMARC (_dmarc).
Note any verification tokens for services such as Google Search Console, Microsoft 365, or domain ownership checks.

This export becomes your safety net and your checklist.

Step 2: Choose your path

Path A: Keep nameservers. You’ll edit A, AAAA, and CNAME to point at the new host.
Path B: Change nameservers. You’ll recreate the entire DNS zone at the new DNS provider, then switch nameservers at your registrar.

If you change nameservers, expect a little more work upfront and cleaner management later.

Step 3: Lower TTLs 24 hours before cutover

Edit the TTL on records you’ll change to something short, like 300 seconds. If you’ll change nameservers, lower TTLs now on your current DNS. This sets the stage for a fast propagation window during cutover. If you forgot to lower TTLs, you can still proceed, but changes may linger in caches longer.

Step 4: Build the new hosting environment completely

You need a ready destination before you point traffic.

Upload files or deploy your application.
Import databases and run search-replace if needed for absolute URLs.
Set environment variables and secrets.
Make sure the app runs on the new host’s temporary URL or a staging subdomain.
Generate an SSL certificate that will be valid after cutover. Many hosts issue Let’s Encrypt certificates as soon as DNS points to them. If your provider supports HTTP-01 validation only, be ready to issue the certificate right after the switch. If they support DNS-01, you can validate earlier with TXT records.

Step 5: Prepare DNS changes

You’ll either create or edit these records:

A / AAAA for apex: example.com → 203.0.113.10 and optionally an IPv6 target.
CNAME or A for www: www → example.com (CNAME) or a direct A record to the same IP as apex.
MX: Confirm current email provider stays the same. If you’re not changing email, do not change MX.
SPF, DKIM, DMARC: Keep existing TXT records for email deliverability.
Other subdomains: Copy or recreate mail, ftp, api, app, and any vendor-specific endpoints.
CAA: If you lock certificate authorities with CAA records, add the new CA if your host will issue certs with a different CA.
SRV: If you use services like SIP or Minecraft, recreate SRV records exactly.

If your new host gives you a hostname instead of a bare IP, you can point a CNAME on subdomains. For the root domain, some DNS providers support ALIAS or ANAME on apex to alias to a hostname while returning an A record to resolvers. If your provider doesn’t support ALIAS, use A and AAAA.

Step 6: Test the new site before public DNS changes

You can test without exposing the new host to the public internet.

Local hosts file: Map example.com and www.example.com to the new IP on your own computer. Visit your site in a fresh browser session and confirm pages, forms, and logins work.
curl or dig: Query the new origin directly with curl http://203.0.113.10 or dig @8.8.8.8 www.example.com.
Staging subdomain: If the host supports it, review staging.example.com and run through key flows.

Fix issues now while users still hit the old site.

Step 7: Execute the cutover

If you’re keeping nameservers: edit the A, AAAA, and CNAME records in your current DNS to target the new host. With TTLs at 300 seconds, most users move over in minutes.

If you’re changing nameservers: first recreate the entire zone at the new DNS provider, then go to your registrar and change the nameservers to the new pair. The registrar update usually takes effect quickly, but recursive resolvers cache previous nameserver referrals. Expect a window where some users see the old DNS and some see the new DNS.

Step 8: Issue or confirm SSL

As soon as enough traffic reaches the new origin, issue the SSL certificate if the host did not pre-issue with DNS validation. Then force HTTPS in your application or at the web server. Test mixed content, redirects, and HSTS if you plan to set it.

Step 9: Monitor and validate

Use a short checklist during the first hour:

Load the home page and several deep pages on both example.com and www.
Submit a form and check for emails or CRM entries.
Confirm admin login works.
Check your app logs for 500 errors.
Use dig or an online DNS checker to confirm A, AAAA, CNAME, and MX look correct in several regions.
Watch error trackers and uptime monitors.

Keep an eye on analytics. A sharp traffic drop may signal a redirect loop or a DNS mistake.

Step 10: Raise TTLs after stability

Once you confirm stability, raise TTLs to a sane level for your operations, such as 3600 or 14400 seconds. Short TTLs help changes, longer TTLs reduce unnecessary DNS traffic and small costs on some providers.

Special scenarios you should plan for

You’re also moving email

Web and email often split across providers. When you only move hosting, you should leave MX, SPF, DKIM, and DMARC as they were. If you also move email:

Update MX to the new provider.
Replace SPF to include the new sender. Keep it under 255 characters and avoid multiple include chains that hit DNS lookup limits.
Publish DKIM TXT records for the new service. Test with a signed send to your personal mailbox and view headers.
Set or update DMARC at _dmarc.example.com. Start with p=none if you’re unsure, then move to quarantine or reject after validation.
If mailing lists or SMTP relays send on your behalf, include them in SPF and DKIM.

You use a CDN or a reverse proxy

If you front your site with a CDN or security layer:

Point DNS records to the CDN hostname or any anycast endpoint the vendor provides.
In the CDN dashboard, change the origin to your new host.
If the CDN offers a proxy toggle, decide whether to proxy or expose direct DNS during early testing.
Renew or re-issue edge certificates if the provider uses its own TLS at the edge.

You host on a provider that uses a shared hostname

Many budget hosts ask you to use a CNAME to a provider hostname. That’s fine for subdomains. For the apex, consider an ALIAS if your DNS supports it, or use A and AAAA provided by the host. If the host rotates IPs behind the scenes, monitor announcements and plan for ALIAS support long term.

You run WooCommerce or another transactional app

Transactions create data on the live site. If you freeze the database during migration, announce a short maintenance window and put the shop in maintenance mode. If you must avoid any freeze, time the database copy during low traffic, then repeat a short delta process just before cutover.

You manage many client sites

Standardize the playbook and use templates:

A common record set for apex, www, MX, SPF, DKIM, DMARC, CAA, and root redirects.
A naming convention for staging and admin endpoints.
A spreadsheet or system of record for nameservers, DNS providers, TTL policies, and service notes.
Quarterly drills: restore tests, TTL audits, and DNSSEC checks.

Common mistakes and how to avoid them

Forgetting to lower TTL: Propagation drags on longer than you expect. Lower TTL the day before.
Overwriting MX during a nameserver migration: Copy old MX and TXT email records exactly if email isn’t moving.
Missing CAA records: Your host can’t issue a certificate because your CAA only allows a different CA. Add the new CA.
Root-only change: You move example.com but forget www. Decide whether www is a CNAME to apex or a direct A record and keep them aligned.
No IPv6: If your host supports IPv6, publish AAAA so dual-stack users reach you directly.
Proxy loops: If you proxy through a CDN and also enable reverse proxy on the new host, double proxies can break HTTPS or client IP detection. Pick one proxy layer.

Troubleshooting quick reference

Site loads on some networks, not others: Cached DNS. Check TTLs and wait. Try a different resolver or flush local DNS cache.
Certificate invalid after cutover: Edge or origin cert not issued yet. Issue cert now and confirm CAA.
Email stops: Wrong MX or SPF. Restore old MX and SPF, then reapply changes carefully.
Redirect loop: Conflicting HTTPS or www redirects between app and server. Consolidate redirects in one layer.
New content missing: You cut over to an older copy. Restore the latest database or redeploy.

DNSSEC: turn it on the right way

DNSSEC protects your DNS from tampering. If your DNS provider and registrar both support DNSSEC, enable it after your nameserver migration settles. Do not enable DNSSEC during a nameserver change unless you’re comfortable managing DS records and understanding key rollover timing. If you already had DNSSEC on the old provider, remove DS records at the registrar before switching nameservers, then add the new DS values after the new zone publishes its DNSKEY.

Redirects, www vs non-www, and SEO checks

Decide your canonical hostname. If you prefer www, make example.com 301 redirect to https://www.example.com. If you prefer the apex, redirect the other way. Keep the redirect count at one hop. Confirm:

200 on your canonical, 301 from the non-canonical.
HTTPS everywhere.
HSTS only after you confirm there are no mixed content issues.
Update Search Console property for the canonical host and submit a new sitemap.
Update analytics filters if you use hostname filters.

Zero-downtime migration checklist

Use this quick list when you run the process again:

Export current DNS zone.
Lower TTLs to 300 seconds on records you’ll change.
Build and test the new host on a temporary URL or staging subdomain.
Prepare SSL issuance plan.
Recreate or edit DNS records for apex and www.
Test with hosts file and curl.
Cut over by editing records or changing nameservers.
Issue or confirm SSL.
Verify web and email.
Raise TTLs after stability.
Turn on DNSSEC if you use it.
Update Search Console and analytics.

Final Takeaway

Pointing a domain to a new host is a controlled DNS exercise, not a leap of faith. Inventory the zone, lower TTLs, build the new host fully, and switch either nameservers or the target records with a short testing window. Protect email by preserving MX, SPF, DKIM, and DMARC. Secure the site with correct CAA and SSL. If anything misbehaves, raise the old records from your export and roll back in minutes. When you run this playbook, your visitors won’t notice the move. You will, mostly because nothing breaks.

Frequently Asked Questions

How long does DNS propagation take after I switch?

Most changes resolve in minutes when TTLs are low, but some resolvers cache longer. Allow up to 24 to 48 hours as a safe window for global convergence. Lower TTLs the day before to shorten the wait.

Should I change nameservers or just the A record?

If your current DNS is solid and you want the smallest change, just edit A, AAAA, and CNAME. If you want a new DNS provider or features tied to it, change nameservers after you recreate the zone there.

Will moving my domain break email?

It shouldn’t. Email breaks when MX or SPF changes by accident. If you aren’t moving email, copy MX, SPF, DKIM, and DMARC exactly. Confirm with a test send and look at message headers.

What’s the safest way to test before I flip DNS?

Use your local hosts file to point example.com to the new IP on your own machine. You can browse the site privately and run full checks without exposing it to the public.

Do I need IPv6 records?

If your host supports IPv6, publish AAAA alongside A. Many networks prefer IPv6 when available, and dual-stack improves reachability.

When should I turn on DNSSEC?

After the move. If you change nameservers, disable old DS records, complete the switch, then enable DNSSEC at the new provider and add the new DS records at the registrar.

How do I handle the www vs non-www decision?

Pick one canonical host, redirect the other with a 301, and enforce HTTPS. Keep the redirect to a single hop and update Search Console for the canonical property.

References

ICANN DNS basics and authoritative vs recursive resolution
IANA root zone and nameserver delegation overview
Let’s Encrypt documentation on HTTP-01 and DNS-01 validation
Major DNS provider docs on ALIAS or ANAME records at the apex
DNSSEC concepts and DS record management from registrar help centers