How to Point a Domain to Cloud Hosting: DNS Records, SSL, and Troubleshooting Checklist

Overview

A domain is the human-readable address visitors use, while hosting is the infrastructure that serves the website. DNS connects the two by translating a hostname such as www.example.com into the destination configured by your hosting provider.

Before you begin, collect four pieces of information:

• Access to the domain registrar or current DNS provider.
• The cloud hosting account and its assigned destination, such as an IP address or hostname.
• The preferred site address: the root domain, www, or both.
• Any existing email, verification, analytics, or third-party service records that must remain active.

There are two common approaches to a domain and hosting setup. You can change the domain's nameservers so the hosting provider manages the DNS zone, or you can keep DNS at the current provider and edit individual records. Nameserver changes are convenient when one provider should manage the whole zone. Individual record changes offer more control when email or other services already depend on the existing DNS provider.

For a broader launch sequence, see the domain, hosting, DNS, and SSL setup guide. If you are moving an existing site, also review the website migration to cloud hosting guide before changing production records.

Checklist by scenario

Scenario 1: Your hosting provider manages DNS

1. Find the provider's authoritative nameservers in the hosting dashboard. Copy them exactly; do not substitute a web server IP address in the nameserver fields.
2. At the registrar, replace the existing nameservers with the provider's nameservers.
3. Confirm whether the provider created records for the root domain and www hostname. Some platforms require you to add one or both manually.
4. Keep a written copy of the previous DNS records before making the change, especially MX, TXT, and CNAME records related to email or verification.
5. Wait for the change to become visible across DNS resolvers, then complete domain verification and SSL activation in the hosting dashboard.

Changing nameservers can move responsibility for every DNS record, not just the website. If email is hosted elsewhere, recreate the required mail records in the new DNS zone before relying on the new configuration.

Scenario 2: You are keeping DNS with the registrar or another provider

1. Locate the DNS zone for the domain.
2. For the root domain, add or update an A record pointing to the IPv4 address supplied by the cloud host. If the provider supplies an IPv6 destination, use an AAAA record as instructed.
3. For www, add a CNAME pointing to the hostname supplied by the hosting platform, or follow the provider's specific root and subdomain instructions.
4. Remove conflicting records for the same hostname. Two old and new A records can cause visitors to reach different servers.
5. Save the records and confirm that the host is added to the website project. A DNS record alone does not always associate the domain with the correct site.

An A record maps a hostname to an IPv4 address. A CNAME maps one hostname to another hostname. In practice, the root domain and www may use different record types because DNS providers apply different rules to the zone apex. Use the hosting provider's documented target rather than assuming that one record format works everywhere.

Scenario 3: You are launching a new site

1. Build and test the site on its temporary hosting address or preview URL.
2. Confirm the production domain is attached to the correct project.
3. Set the DNS records, then verify both the root domain and www address.
4. Activate SSL for every public hostname. Do not test only the homepage; check representative paths and assets over HTTPS.
5. Choose one canonical version, such as HTTPS at the root domain or HTTPS at www t, and configure a redirect from the alternate version.
6. Run a final launch review using the domain, DNS, SSL, hosting, and analytics checklist.

Scenario 4: You are migrating an existing website

Reduce risk by lowering the DNS TTL ahead of the planned switch when your provider allows it, preparing the new site, and testing the destination before changing traffic. Record the old DNS values, preserve email records, and schedule the change when you can monitor it. After the switch, check redirects, forms, logins, media, robots instructions, and important landing pages. The cloud hosting migration checklist provides a useful companion process.

What to double-check

DNS visibility and propagation

DNS changes are cached by resolvers according to each record's TTL. As a result, one network may show the new destination while another still uses the old value. Check the record from more than one resolver or network, but do not treat a single lookup as proof that every visitor sees the same result. The DNS check tools guide can help you choose a verification method.

SSL and hostname coverage

SSL must cover the hostname visitors actually use. Test the root domain, www, and any important subdomains separately. If the certificate is pending, confirm that DNS points to the intended project and that the hosting platform has accepted the domain. Once HTTPS works, test HTTP-to-HTTPS redirects and check for mixed content caused by hard-coded HTTP asset URLs.

Email and verification records

Website records and email records can coexist, but they serve different purposes. Preserve MX records for mail delivery and retain relevant TXT records used for sender authentication or service verification. Do not delete unfamiliar records without identifying the service that created them. If you change nameservers, confirm that the complete email DNS configuration exists in the new zone.

Canonical behavior and redirects

Decide whether the preferred address is https://example.com or https://www.example.com. The alternate should redirect consistently, and internal links should use the preferred form. Test a missing page, an old URL, a trailing-slash variation where relevant, and a few migrated URLs to ensure the server returns the intended response rather than a redirect chain or unrelated page.

Common mistakes

• Editing DNS at the wrong provider: The active nameservers determine which DNS zone matters. Check delegation before changing records.
• Leaving conflicting records in place: Remove obsolete A, AAAA, or CNAME records for the same hostname when the new setup replaces them.
• Changing nameservers without copying email records: A successful website launch can still disrupt mail if MX and related TXT records are missing.
• Using a CNAME at the root without provider support: Follow the DNS provider's supported method for the zone apex.
• Assuming propagation is an outage: Compare results across networks and allow for caching before making repeated changes.
• Activating SSL too early or for only one hostname: Attach the domain to the correct site first, then verify every public hostname.
• Skipping the old site during migration: Keep the previous environment available until traffic, forms, redirects, and key pages have been checked.

When to revisit

Keep this checklist with the domain's operational records and revisit it before a planned launch, seasonal campaign, hosting change, rebrand, or domain transfer. It is also useful after changing email providers, adding a subdomain, replacing a website builder, or moving from one cloud hosting environment to another.

At each review, confirm that the registrar login and recovery details are current, the DNS provider is documented, the preferred canonical hostname is clear, SSL renewals are functioning, and the current records have an owner. Recheck the setup after workflow or tool changes, because a hosting dashboard may use a different target hostname or validation process over time.

Final action checklist: document the current records, verify the authoritative nameservers, update only the required A, AAAA, or CNAME entries, preserve email records, attach the domain to the correct site, activate and test SSL, confirm redirects, and monitor the old and new destinations during the transition. This sequence makes a domain change repeatable rather than a one-time troubleshooting exercise.