How to Point a Domain to Cloud Hosting: DNS Records, Nameservers, and Verification

Overview

A domain name and a cloud hosting account are separate services. The domain registrar manages your registration, while the hosting platform provides the server or application that should answer requests for your website. DNS connects the two by telling resolvers where to find the site.

Before making changes, identify these details from your cloud hosting provider:

• The destination IPv4 address for an A record, if one is required.
• An IPv6 address for an AAAA record, if the provider supplies one and your service supports IPv6.
• A hostname for a CNAME record, commonly used for www or platform-managed deployments.
• The provider's authoritative nameservers, if it offers managed DNS.
• Any verification record, such as a TXT or CNAME record, required before deployment or SSL activation.

There are two main connection methods. With a nameserver change, you delegate the domain's DNS management to the hosting provider. With individual DNS records, you keep DNS management at your registrar or a separate managed DNS provider and point only the required hostnames to the cloud service. Neither method is universally better. Choose based on who should control DNS, how many services use the domain, and what your provider documents.

Checklist by scenario

Scenario 1: Your cloud host provides nameservers

1. Record the existing DNS zone before changing anything. Save A, AAAA, CNAME, MX, TXT, and other records, especially those used for business email, verification, payments, or third-party services.
2. Confirm that the hosting account is ready to accept the domain. Some platforms require you to add the domain in a dashboard before changing delegation.
3. At the registrar, replace the current nameservers with the complete nameserver set supplied by the hosting provider. Do not add the new nameservers alongside unrelated old ones unless the provider explicitly instructs you to do so.
4. Recreate or confirm all required DNS records in the new DNS management interface. A nameserver change transfers DNS authority; it does not automatically preserve every record.
5. Wait for delegation changes to become visible, then test both the root domain, such as example.com, and the www hostname.

This approach can simplify cloud hosting management because the platform may be able to configure records, routing, and SSL from one control panel. It also means the hosting provider becomes an important part of your DNS access and recovery plan.

Scenario 2: You are keeping DNS at the registrar

1. Leave the domain's nameservers unchanged.
2. Add an A record for the root or apex domain if the provider gives you an IPv4 address. The host field may be shown as @ or left blank, depending on the DNS interface.
3. Add an AAAA record only when you have a valid IPv6 destination and have confirmed that the application is configured to serve traffic over IPv6.
4. Add a CNAME record for www or another subdomain when the provider gives you a hostname rather than an IP address. A CNAME generally should point to the exact target supplied by the provider.
5. Follow the provider's instructions for the root domain. Standard DNS does not allow a CNAME at the apex in many systems, while some managed DNS services support an alias or flattened CNAME feature.

Keeping DNS at the registrar can be useful when email, security controls, staging systems, and several cloud services already depend on one carefully managed zone. It also avoids moving unrelated DNS records during a website launch.

Scenario 3: You are launching a new site without changing email

Separate web traffic from mail traffic. Update only the records needed for the website and leave MX records, mail-related CNAME records, SPF records, DKIM records, and DMARC records unchanged unless your email provider tells you otherwise. If you are launching business email on the same domain, review the setup requirements in Business Email on Your Domain before editing DNS.

Scenario 4: You are migrating an existing website

Reduce risk by lowering the relevant DNS record's TTL before the planned cutover, where practical and supported by your DNS provider. Prepare the site on the new cloud host, verify the application using a temporary hostname or provider preview URL, and take a backup. Change DNS during a monitored window, but keep the old hosting available until traffic is consistently reaching the new service. For a fuller migration sequence, use the website migration checklist.

What to double-check

• Record scope: The root domain and www are separate hostnames. Configure both if visitors may use both, then set the preferred version in your hosting platform or application.
• DNS authority: Check which nameservers are active before editing records. Changes made in a non-authoritative DNS panel will not affect public resolution.
• Duplicate records: Remove obsolete A or AAAA records that point to an old server when they conflict with the new destination. Multiple intentional records should be used only when your architecture supports them.
• TTL: TTL controls how long recursive resolvers may cache a response. It does not force every resolver to refresh immediately, so do not treat a low TTL as an instant switch.
• SSL coverage: Add the domain to the cloud host before requesting its certificate. Test HTTPS for the root domain, www, and any other public hostname. DNS resolution alone does not prove that SSL is configured.
• Application settings: Configure the domain in the web server, reverse proxy, CMS, or deployment platform. A correct DNS record can still lead to a default page or host-header error if the application does not recognize the hostname.
• Verification tools: Use a DNS propagation checker for a broad view, and use dig, nslookup, or equivalent tools from more than one network when diagnosing a discrepancy. Compare the returned record type and value with the provider's instructions.

For security-sensitive deployments, also review registrar lock, two-factor authentication, recovery contacts, and DNSSEC compatibility. The domain security checklist provides a useful companion review.

Common mistakes

Changing nameservers and records without a plan

Changing nameservers is not the same as adding an A record. If you change delegation and then edit records at the old provider, the edits may have no effect. Choose one authoritative DNS provider and make changes there.

Overwriting email records

A website move does not normally require changing MX, SPF, DKIM, or DMARC records. Export the zone first and compare it after any nameserver migration. If mail stops after a web launch, inspect the authoritative zone before changing records randomly.

Using the wrong target type

An IP address belongs in an A or AAAA record; a provider hostname generally belongs in a CNAME. Do not place a URL containing https:// or a path such as /login in a DNS value. DNS points to hosts and addresses, not web pages.

Testing only one network

Your device may be using cached DNS data. Test with more than one resolver or network, and distinguish DNS caching from an application, firewall, routing, or SSL problem. If some locations show the old site while others show the new one, check delegation, TTL, and duplicate records.

Requesting SSL too early

Certificate automation commonly depends on the domain resolving to the intended service or on a DNS verification record being present. Confirm DNS and domain ownership steps first, then activate SSL. If HTTPS works but redirects loop, check proxy and application HTTPS settings as well as the certificate.

When to revisit

Keep this checklist with your website launch and change-management records. Revisit it before seasonal planning cycles, major campaigns, product launches, or any event when downtime would be especially costly. It is also worth reviewing whenever your cloud hosting provider changes its dashboard, IP addresses, deployment model, nameservers, or SSL workflow.

Before acting, confirm that you have current registrar access, DNS access, a backup of the zone, the hosting destination, and a rollback plan. After acting, verify the root domain, www, application response, HTTPS, email delivery, and important subdomains. Record the final DNS values, the date of the change, and who approved it.

For the next launch, use this short sequence: identify the authoritative DNS provider, back up the zone, choose nameservers or records, preserve email records, configure the cloud application, verify DNS from multiple locations, activate SSL, and monitor before retiring the old host. That sequence remains useful whether you are connecting a new domain, moving a site, or adding a cloud-hosted application to an established domain.