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

Overview

A domain is the address visitors enter, while cloud hosting provides the infrastructure that delivers your website. DNS, or the Domain Name System, connects the two by translating a domain name into the destination used by a browser or other service.

Before changing anything, collect the details supplied by your hosting provider:

• The hosting provider’s nameservers, if you plan to delegate DNS management to the host.
• The public IP address for an A record, if you will keep DNS management with your domain registrar.
• The target hostname for a CNAME record, commonly used for a subdomain or hosted service.
• Any required verification, mail, or service records.
• The instructions for issuing or enabling an SSL certificate.

You generally have two connection methods. Changing nameservers moves DNS management to the hosting provider. Adding or editing records keeps DNS management at the registrar or current DNS provider and changes only the records needed for the website. Neither method is automatically best: nameservers can simplify a single-provider setup, while individual records can reduce disruption when email and other services already depend on the existing DNS zone. For a deeper comparison, see Nameservers vs DNS Records: What Changes Where and How Long It Takes.

Checklist by scenario

Scenario 1: A new domain with no existing services

1. Confirm that the domain is registered and that you can access its DNS management panel.
2. Choose whether to use the cloud host’s nameservers or keep DNS at the registrar.
3. If using nameservers, replace the current nameserver entries with the exact values provided by the host.
4. If keeping DNS at the registrar, create the required A record for the root domain. The host may refer to the root as @.
5. Add a www CNAME pointing to the target supplied by the host, or use the host’s stated alternative.
6. Add the domain to the hosting account and select the intended primary domain.
7. Enable the host’s SSL certificate after the domain resolves to the correct environment.
8. Test both the root domain and the www version over HTTPS.

Scenario 2: An existing website moving to cloud hosting

1. Reduce avoidable risk by recording the current DNS zone before making changes. Include web, email, verification, and subdomain records.
2. Set up the website in the new hosting account before switching DNS. Confirm the application, database, file permissions, and environment settings work on the new platform.
3. Use a temporary host-provided URL or local testing method where available. Do not rely on DNS alone to test an unfinished migration.
4. Copy the current website and database, then check forms, logins, media, redirects, scheduled tasks, and integrations.
5. Change only the web records required for the cutover. Preserve mail records unless email is also moving.
6. Keep the old hosting environment available until the new site has been tested from more than one network and the expected DNS changes are visible.
7. Review application settings for the final domain, including canonical URLs, cookie settings, API callbacks, and WordPress address fields.

For a broader sequence covering backups, testing, and DNS, use the Website Launch Checklist. WordPress owners can also review the guidance on setting up a staging site before switching live traffic.

Scenario 3: The website is moving, but business email must remain active

1. Identify the current MX records and note which email provider they represent.
2. Keep the existing MX records unchanged if email is staying with that provider.
3. Preserve related SPF, DKIM, and DMARC records. These may be published as TXT records.
4. Avoid replacing the entire DNS zone with a host-provided template unless you have first copied every required mail and verification record.
5. Send and receive test messages after the website cutover. Check that messages arrive externally as well as within the organisation.

DNS changes for email can be easy to overlook during a website migration. Use the Business Email DNS Setup Guide when auditing mail records.

Scenario 4: A subdomain or separate service needs connecting

For a service such as app.example.com, docs.example.com, or shop.example.com, create the record type specified by the service provider. An A record points to an IP address; a CNAME points to another hostname. Do not use a CNAME at the root domain unless your DNS provider explicitly supports the relevant feature. Before publishing a subdomain, confirm its SSL certificate covers the exact hostname visitors will use.

What to double-check

• Record name: Check whether the DNS panel expects @, a blank field, or the full domain. Entering the domain twice can create the wrong hostname.
• Trailing dots: Some panels display fully qualified hostnames with a trailing dot and others add it automatically. Follow the panel’s format rather than guessing.
• Conflicting records: Remove obsolete web records only after confirming they are no longer needed. Multiple competing records can produce inconsistent results.
• TTL: A time-to-live value influences how long resolvers may cache a record. It does not force every network to update immediately.
• Propagation: Check the root domain, www, and important subdomains separately. Results can differ between networks while caches expire.
• HTTPS: Test the certificate, the HTTP-to-HTTPS redirect, and both domain variants. A certificate for the root domain may not automatically cover every subdomain.
• Application URLs: Update hard-coded HTTP URLs and old hostnames in the website configuration. This is especially important for WordPress and content management systems.
• Backups: Keep a restorable website and database backup before migration or DNS changes. A DNS update does not provide a rollback for damaged application data.

If HTTPS produces warnings after the connection succeeds, review How to Fix Mixed Content, Redirect Loops, and SSL Errors. For certificate types and renewal planning, see the SSL Certificate Guide.

Common mistakes

Changing nameservers without copying email records: A new DNS zone may contain website records but omit mail records. Export or document the existing zone before delegating DNS elsewhere.

Pointing the domain to the wrong IP: Cloud platforms may provide separate addresses for production, staging, or load-balanced services. Confirm that the record matches the live environment.

Testing too soon: A successful result on one device does not prove that every resolver has refreshed. Test from different networks and use DNS lookup tools to compare authoritative answers with cached results.

Installing SSL before DNS is ready: Certificate issuance commonly requires the provider to verify control of the domain. Complete the DNS connection and follow the host’s certificate workflow in the stated order.

Leaving duplicate redirects: Redirect rules at the application, web server, CDN, and hosting layers can conflict. Keep one clear path from HTTP to the chosen HTTPS URL and test it in a private browser window.

Deleting the old host immediately: Retain the old site until DNS, HTTPS, email, forms, and integrations have been checked. This gives you a safer recovery option during the transition.

When to revisit

Use this checklist whenever you connect a new domain, move to cloud hosting, add a subdomain, change email providers, renew or replace an SSL certificate, or alter DNS management. Revisit it before seasonal planning cycles and major campaigns, when traffic or infrastructure may change, and whenever hosting or DNS workflows are updated.

For a practical review, schedule a short infrastructure check and confirm:

1. The registrar account, DNS provider, and hosting account are documented.
2. Domain renewal and SSL renewal responsibilities are assigned.
3. DNS records match the current website, email, and third-party services.
4. Backups can be restored and are not stored only on the production server.
5. HTTPS works for every public hostname, with no mixed-content or redirect errors.
6. Monitoring or periodic manual checks will detect an unexpected DNS or certificate change.

Infrastructure details change over time, but the order remains useful: document the current state, prepare the destination, change only the necessary records, verify DNS, activate HTTPS, test email, and keep a recovery path until the connection is stable.