Moving a website should not mean gambling with your business email. The practical question behind how to point domain names is not just where your website will load. It is which DNS records need to change, which ones must stay untouched, and how to test the result before customers notice a problem.

A domain can be registered with one company, hosted with another, and use email from a third. That setup is normal. The key is making DNS changes deliberately instead of replacing settings you do not fully recognize.

What pointing a domain name actually changes

A domain name points visitors to a destination through DNS, short for Domain Name System. DNS is the public directory that tells browsers where to find your site and tells mail servers where to deliver email.

When someone enters yourdomain.com, DNS may direct them to a hosting server through an A record. When they send a message to you@yourdomain.com, DNS uses MX records to find your email provider. Other records handle subdomains, verification, email authentication, and services such as Microsoft 365 or Google Workspace.

That is why “point the domain” can mean two different things:

• Change the domain’s nameservers so another provider manages all DNS records.
• Keep DNS where it is and change only the records needed for the website.

Neither option is automatically better. A full nameserver change can be simple when you are starting fresh. Editing individual records is usually safer when email and other services are already working.

Before you point domain names, document DNS

Start by finding out who currently manages DNS. This is not always the domain registrar. The registrar is where you renew the domain and change nameservers, while DNS may be managed by the registrar, your web host, a dedicated DNS provider, or a website platform.

Open the current DNS zone and make a copy of every existing record. Include the record type, host or name, value, and priority where applicable. Screenshots are helpful, but a written copy is easier to compare while you work.

Pay close attention to MX, TXT, and CNAME records. MX records route email. TXT records often contain SPF, DKIM, and DMARC policies used to authenticate outgoing email. CNAME records may connect subdomains or support third-party verification. Removing any of these without replacing them can cause mail failures, login issues, or disconnected services.

If you are moving an established business site, lower the TTL value for the web records a few hours or a day before the switch, if your DNS provider allows it. TTL controls how long DNS resolvers cache a record. A lower TTL, such as 300 seconds, can make the transition easier to reverse if you spot a problem. Do not lower it at the last minute and expect every network to update immediately. Existing caches may still hold the old value until their current TTL expires.

Option 1: Change nameservers

Nameservers determine where the complete DNS zone is managed. Your new hosting provider may give you two or more nameserver addresses, such as ns1.examplehost.com and ns2.examplehost.com.

To use them, sign in to the company where the domain is registered, locate the domain’s nameserver settings, and replace the existing nameservers with the ones provided. Save the change. After DNS updates, the new provider’s DNS zone becomes authoritative for the domain.

This approach is often appropriate when the new host will manage both the website and DNS, especially for a new site with no existing email configuration. It can also reduce day-to-day confusion because website-related DNS records live in the same account as the hosting service.

The trade-off is clear: changing nameservers does not copy your old DNS records. You must recreate them at the new DNS provider. Before changing nameservers, add the necessary A, CNAME, MX, and TXT records in the new zone. If you switch nameservers first and build the zone afterward, there may be a period when your site or email cannot be found.

For a basic website, the new zone usually needs an A record for the root domain, shown as @, pointing to the server IP address. It may also need a www CNAME pointing to the root domain. Your host may provide different instructions, so use the specific values supplied for your account rather than guessing.

Option 2: Edit DNS records without changing nameservers

If your domain already has working email, the safer path is often to leave nameservers alone and update only the web-related records. This keeps email routing and other existing DNS settings in place.

For a standard hosting account, change the root A record to the new server’s IPv4 address. Then set www as either a CNAME to the root domain or an A record using the same IP, depending on the host’s instructions. In many cases, those are the only changes required.

For a website builder, ecommerce platform, or application service, you may receive a combination of A and CNAME records. Follow the host names exactly. A CNAME for www is common, while some providers require a verification TXT record before they will publish the site.

Do not create duplicate records with conflicting values. Two A records for the same host can split visitors between two servers. That is useful for intentional load balancing, but it is a common mistake during a migration. Remove or replace the old web record once you are ready to make the change.

Root domain versus subdomains

The root domain is yourdomain.com. The www version is a subdomain: www.yourdomain.com. Many site owners want both versions to work, with one redirecting to the other for consistency.

You may also have subdomains such as shop.yourdomain.com, app.yourdomain.com, or blog.yourdomain.com. These can point to entirely different services. Changing the root domain does not automatically change them, which is usually useful. Review each subdomain before deleting old entries.

Keep email records intact

Email is where domain changes become expensive. If you use a separate mailbox provider, retain its MX records exactly as supplied. Also preserve the TXT records for SPF, DKIM, and DMARC unless you are intentionally changing the email service.

A web host may offer local email accounts, but you do not need to move email just because you move a website. Keeping an existing email provider can be the lower-risk choice, particularly when staff already have working inboxes and devices configured.

After making DNS changes, send test messages both ways. Send from an outside address to your domain, then send from your domain to an outside address. Check spam folders and confirm that replies work. If email delivery fails after a nameserver change, compare the new DNS zone against the record copy you made before the move.

Verify the site before calling the job done

DNS changes can appear within minutes, but full propagation may take up to 24 to 48 hours. The exact timing depends on TTL settings, resolver caches, and the networks your visitors use. Avoid making repeated changes every few minutes. That can make troubleshooting harder because different locations may be seeing different versions.

Check the domain with and without www. Open a few important pages, submit a contact form, and confirm that images, stylesheets, and redirects load correctly. If the site uses HTTPS, install or renew the SSL certificate after the domain resolves to the correct server. A certificate cannot validate reliably when the domain still points somewhere else.

For WordPress migrations, also check the WordPress Address and Site Address settings. A correct A record will not fix a site that still has an old URL configured internally. For an unmanaged VPS, confirm that the web server has a virtual host or server block for the domain and that the firewall permits web traffic.

Common problems and the practical fix

If the domain shows a parking page, it is probably still pointed at the registrar or an old host. Check whether the authoritative nameservers are correct, then verify the A or CNAME record in the active DNS zone.

If the site loads on the server IP but not on the domain, the DNS record may be wrong or still propagating. If it loads without www but not with it, the www record is likely missing. If visitors see a certificate warning, confirm the DNS is settled before issuing SSL again.

If email stopped after a nameserver change, restore the MX and related TXT records from your backup. If you are unsure which record is needed, do not delete anything further. A support team can work faster when you provide the domain name, the intended website destination, and a copy of the current DNS zone.

DoRoyal customers can keep domain registration, hosting, DNS, backups, and security services in one practical setup, but the same principle still applies: change only what the service requires and preserve the records that support everything else.

Pointing a domain is a small technical task with real business consequences. Make one controlled change, verify the website and email, and keep a record of the settings that worked. That approach is slower than clicking through a migration wizard blindly, but it is far less likely to leave customers staring at an error page or wondering where their email went.