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

Overview

Your domain and hosting account are separate services, even when one company provides both. The domain registration identifies and controls the name. Cloud hosting supplies the infrastructure that serves your website. DNS records connect the two by telling browsers which servers handle web traffic, email, and other services.

Before changing anything, identify these four details:

• Your registrar: the provider where the domain is registered.
• Your DNS host: the provider that manages the domain's nameservers and DNS records. This may be the registrar, the hosting company, or a separate DNS service.
• Your hosting destination: the cloud hosting provider's IP address, hostname, or required nameservers.
• Your existing services: email hosting, subdomains, verification records, analytics tools, and any third-party applications using the domain.

There are two common connection methods. You can change the domain's nameservers to those supplied by the hosting provider, allowing that provider to manage the DNS zone. Alternatively, you can leave nameservers where they are and edit individual records, usually an A record or CNAME for the website. The first method can be simpler for a new site; the second gives you more control and can reduce the risk of disrupting existing email or verification records.

Do not change nameservers until you know which records need to be recreated. A nameserver change can move the entire DNS zone, not just the website.

Checklist by scenario

Scenario 1: Connecting a new domain to new cloud hosting

1. Register the domain and confirm that it is active and not locked against changes.
2. In the cloud hosting dashboard, add the domain to the correct project, application, or virtual host.
3. Record the hosting provider's instructions. Look for an IPv4 address, IPv6 address, target hostname, or nameservers.
4. Choose whether the hosting provider or your current DNS provider will manage DNS.
5. Add the root-domain record. This is commonly an A record for a server IP, although some platforms require an ALIAS, ANAME, or provider-specific target.
6. Add the www record, often a CNAME pointing to the root domain or the hostname supplied by the host.
7. Remove only conflicting records. Avoid deleting unrelated records until you understand their purpose.
8. Wait for DNS changes to become visible, then test both the root domain and www version.
9. Request or enable the hosting provider's SSL certificate and test the HTTPS version.

Scenario 2: Keeping DNS at the registrar

This approach is useful when the registrar already manages email, subdomains, or other services. Add the records provided by your cloud host without changing nameservers.

• Set the root domain's web record to the hosting destination.
• Point www to the correct hostname or root domain.
• Keep MX, TXT, and other service records intact unless the provider specifically requires a change.
• Check whether the DNS editor automatically appends the domain name. Entering a full hostname in a field that expects only a label can create an unintended record.
• Confirm that the cloud host recognizes both hostnames and assigns them to the same website.

Scenario 3: Changing hosting providers

Complete the new hosting setup before changing live DNS. Upload the website, configure the application, create databases, and test the site using a temporary URL, preview address, or local hosts-file entry if the provider supports one.

Record the existing DNS zone before the change. Pay particular attention to email records, domain verification, payment tools, API endpoints, and subdomains. When the new site is ready, update only the web records first. Keep the old hosting account available until DNS changes are visible and the new site has passed functional checks.

For a broader migration sequence, see How to Migrate a Website to a New Host Without Losing Rankings or Email.

Scenario 4: Using a CDN or reverse proxy

If a CDN sits in front of the cloud host, the public DNS record may point to the CDN rather than directly to the origin server. Follow the CDN's hostname and proxy instructions, then configure the origin hostname or IP in the CDN dashboard. Confirm that the origin accepts requests for the correct domain and that the SSL mode is compatible on both connections.

A CDN is not the same as web hosting. The hosting service still needs to serve the application, while the CDN may handle caching, edge delivery, and some security functions. Read CDN vs Web Hosting: What Each One Does and When You Need Both before changing this layer.

What to double-check

DNS record names and values

Check the record type, host or name, value, and whether a trailing dot or provider-specific format is required. An A record expects an IP address. A CNAME expects a hostname, not an IP address. Do not create a CNAME at the root domain if your DNS provider does not support that arrangement; use the record type recommended by the provider.

Nameserver delegation

If you changed nameservers, verify the change at the registrar and confirm that the new DNS provider contains every necessary record. A DNS dashboard can look correct while the domain is still delegated to a different provider.

SSL and canonical hostnames

Open both https://example.com and https://www.example.com, replacing the example with your domain. Confirm that the certificate covers the hostname visitors use, that HTTP redirects to HTTPS as intended, and that the application does not load mixed HTTP content. If the certificate cannot be issued, the domain may not yet point to the correct service or the host may not recognize the domain.

For certificate-specific diagnostics, use the SSL Certificate Setup Guide.

Email and verification records

Website DNS changes should not silently remove email configuration. Check MX records and the email provider's SPF, DKIM, and DMARC records. Also review TXT records used by search tools, analytics platforms, payment providers, and other services. The guide to DMARC, SPF, and DKIM Setup covers the email authentication layer separately.

Propagation and testing

DNS changes do not appear everywhere at once. Resolvers may retain earlier answers until the record's time to live expires. Test from more than one network, use a DNS lookup tool, and check the hosting provider's domain verification screen. A local result is not enough to confirm that the change is globally visible.

Common mistakes

• Changing nameservers without copying email records: the website may work while mail delivery stops.
• Pointing only the root domain: visitors using www may see an error unless that hostname has its own record and hosting configuration.
• Using the wrong record type: an IP address in a CNAME field or a hostname in an A record will not produce the intended result.
• Editing DNS at the wrong provider: confirm the authoritative nameservers before making changes.
• Testing before adding the domain to the host: DNS can point correctly while the server returns an unknown-host or default-site response.
• Issuing SSL too early: certificate validation usually requires the domain to resolve to the expected service.
• Deleting old hosting immediately: keep the previous environment available until the new site, redirects, forms, logins, media, and email have been checked.
• Ignoring application settings: a CMS may need its site URL, trusted domains, database configuration, or cache cleared after a domain or host change.

If the site is slow after the connection works, DNS is only one possible cause. Review hosting resources, caching, CDN behavior, and asset delivery with How to Speed Up Your Website With Better DNS, Hosting, Caching, and CDN Settings.

When to revisit

Keep this checklist with your domain and hosting records. Revisit it before a planned launch, seasonal campaign, major website release, or migration. It is also useful when changing registrars, moving from shared hosting to cloud hosting, adding a CDN, introducing professional email, or restructuring subdomains.

Tools and hosting dashboards change over time, so check the current provider instructions whenever a workflow differs from the steps above. The underlying questions remain stable: Which service is authoritative for DNS? Which record serves each hostname? Which records support email and verification? Where is SSL terminated? Which environment is currently live?

Before closing a launch or migration, complete this final handoff:

1. Save a copy of the final DNS zone and hosting configuration.
2. Write down the registrar, DNS provider, hosting account, and renewal contacts.
3. Test the root domain, www, HTTPS, forms, logins, redirects, and key pages.
4. Send and receive a test email if the domain handles mail.
5. Check uptime monitoring and schedule a follow-up review after the expected DNS transition period.

For a broader launch review, use the Website Launch Checklist. A documented DNS setup makes the next provider change or website update safer, faster, and easier to verify.