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

Overview

A domain is the human-readable address visitors use, while hosting is the server environment that delivers the website. DNS connects the two by translating a domain name into the destination records used by browsers, mail services, and other systems.

Before changing anything, identify these four pieces of information:

• Domain registrar: The company where the domain is registered and renewed.
• DNS provider: The service currently managing the domain’s DNS zone. This may be the registrar, the hosting provider, or a separate DNS platform.
• Hosting destination: The cloud hosting account, server IP address, or platform-specific hostname supplied by the host.
• Required services: The website, subdomains, email, verification records, and other systems that depend on DNS.

There are two common ways to connect a domain to hosting. Changing the domain’s nameservers delegates DNS management to the hosting provider. Editing individual A and CNAME records keeps DNS at the current provider while pointing only the required hostnames to the new hosting environment.

Neither approach is automatically better. Nameservers can simplify setup when the host provides a complete DNS zone and you want one provider to manage it. Individual records offer more control when the domain already supports email, verification services, a CDN, or several websites. Document the existing DNS records before making changes, especially during a migration.

If you are also reviewing server requirements for search visibility, the Technical SEO Hosting Checklist can be used alongside this DNS guide.

Checklist by scenario

Scenario 1: The hosting provider manages your DNS

1. Open the hosting dashboard and add the domain to the correct project or site.
2. Copy the exact nameservers provided by the host. Nameservers usually look like hostnames rather than IP addresses.
3. At the registrar, replace the existing nameserver entries with the new ones. Do not add nameservers to an unrelated DNS record field.
4. Keep a copy of the old DNS zone until the site and email have been tested.
5. Check whether the hosting provider creates the root domain, www, mail, and verification records automatically. If not, add them according to the provider’s instructions.
6. Wait for the delegation change to become visible, then activate SSL in the hosting dashboard.

Changing nameservers moves control of the entire DNS zone. This means records for email, subdomains, domain verification, and third-party applications must exist in the new zone. A website may appear to work while email fails if those records were not copied.

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

1. Leave the existing nameservers unchanged.
2. Find the hosting destination supplied by the cloud host. For the root domain, this is commonly an IP address used in an A record. For a subdomain or platform deployment, it may be a CNAME target.
3. Update the root or apex record as instructed. Some DNS providers use an ALIAS, ANAME, or flattened CNAME feature for the root domain because standard DNS does not permit a CNAME at the apex.
4. Point www to the required destination, often with a CNAME to the root domain or a host-provided hostname.
5. Remove conflicting A, AAAA, or CNAME records for the same hostname if they point to an old server.
6. Retain MX, TXT, and other records that support email and external services unless you are intentionally changing them.

The practical difference between an A record and a CNAME is important. An A record maps a hostname directly to an IPv4 address. A CNAME maps one hostname to another hostname, allowing the destination to be managed separately. Use the record type specified by the host rather than guessing from a generic example.

Scenario 3: You are migrating an existing website

1. Lowering DNS TTL before the migration may help future changes be recognized sooner, but it does not remove caching everywhere.
2. Export or record the existing DNS zone, including MX, SPF, DKIM, DMARC, TXT, SRV, and subdomain records where applicable.
3. Build and test the website on the new cloud hosting environment before switching DNS.
4. Confirm the new server handles the correct domain, application settings, database connection, uploads, and redirects.
5. Change the required DNS records during a planned window and monitor both the new site and email.
6. Keep the old hosting account available until DNS visibility is consistent and the new site has passed its functional checks.

For a broader migration process, see this guide to recognizing when a site has outgrown its hosting plan. DNS is only one part of a safe migration; files, databases, application configuration, and redirects also need validation.

Scenario 4: You are connecting a new domain to a website builder or one-click deployment

1. Create or select the site in the builder or deployment platform.
2. Add both the root domain and the preferred www or non-www version if the platform requires both.
3. Copy any verification TXT record exactly, including punctuation and quotation marks where the DNS interface requires them.
4. Add the platform’s A, CNAME, or other specified records.
5. Wait for verification, then select the canonical domain and enable HTTPS.

What to double-check

DNS propagation and visibility

DNS changes do not update on every resolver at the same time. Cached answers, record TTLs, nameserver delegation, and local network behavior can all affect what you see. Test from more than one network and use DNS lookup tools to inspect A, AAAA, CNAME, NS, MX, and TXT records separately. A record can be correct at the authoritative DNS provider while an older answer remains cached elsewhere.

For a more detailed explanation of the process, refer to DNS Propagation Explained. Avoid repeatedly changing records simply because one location still shows the previous value; unnecessary edits make troubleshooting harder.

SSL and HTTPS

After DNS points to the intended hosting environment, activate the host’s SSL certificate for every hostname visitors will use. Check the root domain and www separately, along with important subdomains. Some platforms issue certificates automatically after domain verification, while others require a manual activation step.

Test both HTTP and HTTPS. Confirm that HTTPS loads without a certificate warning, that the certificate covers the requested hostname, and that the application does not load images, scripts, fonts, or stylesheets over insecure HTTP. Configure one preferred version of the site and redirect the other version consistently. A redirect from HTTP to HTTPS is useful, but it should not replace correcting insecure resource URLs or application settings.

If a CDN is part of the design, verify its DNS target and SSL mode as well as the origin server. The CDN performance guide provides additional context for checking this layer.

Email and third-party services

Website DNS changes can affect email when nameservers are replaced or when existing records are overwritten. Confirm that MX records still point to the email provider. Preserve relevant SPF, DKIM, and DMARC records, along with TXT records used for search tools, payment services, analytics, or domain verification. Never create a second SPF record when the provider expects one combined policy; follow the email provider’s configuration guidance.

Application behavior

Open key pages, forms, login areas, images, downloads, and checkout or contact flows. Confirm that the application recognizes the final HTTPS URL and that cookies, callbacks, API endpoints, and webhook URLs use the intended domain. For WordPress, update the site URL carefully and clear relevant caches after the domain becomes active.

Common mistakes

• Editing DNS at the wrong provider: The visible registrar and the authoritative DNS provider are not always the same. Check the active nameservers first.
• Leaving conflicting records: Multiple A records can distribute traffic among destinations unintentionally. Old AAAA records can also send IPv6 users to the previous server.
• Using a CNAME at the root without provider support: Use the apex-record option supported by your DNS provider or follow the host’s documented alternative.
• Changing nameservers without copying email records: The website may work while mail delivery is interrupted.
• Expecting propagation to be instant: Local caches and resolver caches can continue showing previous results.
• Activating SSL before domain verification: Certificate issuance normally depends on the host being able to verify control of the hostname.
• Testing only one URL: Check HTTP, HTTPS, the root domain, www, and any actively used subdomains.
• Redirecting without checking the application: Redirect loops can result when the proxy, hosting server, and CMS disagree about whether the request is secure.

When diagnosing a failure, change one layer at a time: first nameserver delegation, then DNS records, then hosting response, then SSL, and finally application redirects. This isolates the cause more reliably than changing several settings together.

When to revisit

Return to this checklist whenever a domain moves to new cloud hosting, a website changes platforms, a CDN is introduced, an email provider changes, or a new subdomain is launched. It is also useful before seasonal campaigns, major product releases, planned maintenance, or other periods when downtime or missed email would be costly.

Revisit the records after changes to hosting workflows or deployment tools. A one-click deployment may create a new target hostname, a platform may alter its verification method, or a team may begin managing DNS in a different dashboard. Keep an exported record list and a short ownership note stating who controls the registrar, DNS provider, hosting account, and email service.

Use this final verification checklist before closing a domain or migration task:

• Nameservers are intentionally set and managed in the documented location.
• The root domain and preferred www version resolve to the intended hosting destination.
• Old A, AAAA, and CNAME records are removed or intentionally retained.
• MX, SPF, DKIM, DMARC, and important TXT records are present and correct.
• HTTPS works for every public hostname, with no certificate or mixed-content warnings.
• One canonical domain is selected and redirects work without loops.
• Key pages, forms, logins, integrations, and monitoring checks pass.
• The DNS changes, final targets, and responsible account owners are documented.

For ongoing reliability, pair this process with a website uptime monitoring checklist. Monitoring will not prevent a DNS mistake, but it can shorten the time between a failed change and its detection.