How to Connect a Domain to Cloud Hosting: DNS, SSL, and Verification Guide

Overview

A domain is the public address people use to reach your website. Cloud hosting provides the server or platform that delivers the website. DNS management connects the two by telling browsers which service should answer for the domain.

Before changing anything, record your current setup. Note the domain registrar, the DNS provider, existing nameservers, website host, email provider, and any subdomains in use. This inventory helps prevent an otherwise avoidable outage, particularly when the domain already handles business email.

There are two main ways to connect a domain to hosting:

• Change nameservers: You delegate DNS management to the hosting provider. The provider then controls the domain’s DNS zone and may create the required website records automatically.
• Keep your current DNS provider: You leave the nameservers unchanged and add or update individual records, such as an A record or CNAME, using the hosting provider’s instructions.

Use the first option when you want domain and hosting in one place and the hosting platform is also responsible for DNS. Use the second when you already have managed DNS, email records, security controls, or other services that should remain under separate management. Neither approach is universally better; the important point is to know which system is authoritative before editing records.

For broader preparation, use the website launch checklist for domain, DNS, deployment, email, security, and monitoring.

Checklist by scenario

Scenario 1: A new domain and a new hosting account

1. Confirm the domain registration is active and that you can access its management panel.
2. Confirm the hosting account, cloud VPS, or deployment platform is ready to receive the domain.
3. Find the host’s required connection method. It may provide nameservers, an IPv4 address, an IPv6 address, or a target hostname for a CNAME.
4. Choose whether the host or your existing DNS provider will manage the zone.
5. Add the root-domain record. This is commonly an A record pointing to an IPv4 address, although the provider may specify another method.
6. Add a www record if you want visitors to use www.example.com. A CNAME pointing to the root domain or the host’s target is common, but follow the provider’s exact instructions.
7. Configure the website or web server to recognize both the root domain and any intended subdomains.
8. Request or enable an SSL certificate after DNS points to the correct service.

Scenario 2: The domain already has email

Do not replace all DNS records simply because the website is moving. Add only the records needed for the website unless you are deliberately migrating DNS management. Preserve the existing MX records and review TXT records used for email authentication, verification, or other services. Email-related changes may include MX, SPF, DKIM, and DMARC records, but the exact values must come from the email provider.

If you plan to change nameservers, copy the existing DNS zone first. Compare the old and new zones record by record, including mail, verification, calendar, VPN, and subdomain entries. The guide on launching a website without breaking email is useful when web and mail services are changing at the same time.

Scenario 3: A cloud VPS or self-managed server

1. Assign the domain’s DNS record to the server’s public address.
2. Open the required web ports in the cloud firewall and the server firewall, following the host’s security guidance.
3. Configure the web server, reverse proxy, or container router with the domain name.
4. Set the application to listen on the expected internal port and keep that port separate from public web traffic where appropriate.
5. Install and test SSL at the reverse proxy or web server layer.
6. Confirm that redirects, application environment variables, cookies, and callback URLs use the final HTTPS domain.

For deployment-specific preparation, see the guides to Docker on a VPS and deploying a Node.js app on a VPS.

Scenario 4: A static site or hosted application

Use the platform’s custom-domain instructions rather than guessing the record values. Static hosting providers often require a CNAME, a verification record, or both. Some platforms also require the root domain and www hostname to be configured separately. Add every required hostname in the platform dashboard, then configure one canonical version to receive traffic through a redirect.

What to double-check

• Record type: An A record points to an IPv4 address. An AAAA record points to an IPv6 address. A CNAME points a hostname to another hostname. Do not enter a hostname where the provider requires an IP address.
• Host or name field: DNS panels differ. The root may be represented by @, a blank value, or the full domain. Follow the panel’s format.
• Duplicate records: Remove obsolete website records when appropriate, but do not remove mail or verification records without confirming their purpose.
• TTL: A lower TTL may help during planned changes, but it does not guarantee immediate visibility everywhere. Save the final intended value after the migration is stable.
• Propagation: Check the domain from more than one network or DNS lookup tool. Different resolvers may retain previous answers for a period of time.
• SSL coverage: Test the root domain, www, and every public subdomain. A certificate for one hostname does not automatically cover every other hostname.
• Canonical redirects: Choose whether the site uses the root domain or www as its primary address, then redirect the alternate version consistently.
• Application settings: Update trusted origins, OAuth callback URLs, API endpoints, CORS rules, sitemap URLs, and environment variables when the domain changes.

Use a simple verification sequence: check DNS resolution, open the site over HTTP and HTTPS, inspect the certificate, test the redirect, submit a form, sign in if applicable, and confirm that email still sends and receives. A domain can resolve correctly while the web server, application, or certificate is still misconfigured.

Common mistakes

Changing nameservers without copying existing records. This can remove email and third-party services from the active DNS zone. Export or document the records before delegating DNS to a new provider.

Pointing the domain to a private IP address. A public website normally needs a publicly reachable address or the hosting platform’s specified target. Private addresses are generally used inside a network, not as the public DNS destination.

Adding only the root domain. Visitors may use the www hostname, a staging subdomain, or an application subdomain. Configure each intended hostname deliberately.

Assuming propagation is the only problem. If the correct DNS answer is visible but the site fails, inspect the hosting account, firewall, web-server virtual host, application logs, and SSL configuration.

Installing SSL before the hostname reaches the server. Certificate issuance commonly depends on proving control of the domain or reaching the configured service. Make DNS and host configuration consistent first.

Leaving old records indefinitely. Unused records create confusion during future migrations and can expose forgotten services. After confirming the new setup, remove records that are no longer needed.

When to revisit

Revisit this checklist before a website launch, hosting migration, domain transfer, seasonal campaign, major application release, or change to email providers. It is also worth reviewing after a team changes DNS ownership, adopts a new managed DNS platform, introduces a staging environment, or moves an application to a different cloud server.

Keep a short change record containing the date, DNS provider, intended records, server address, SSL method, primary hostname, and rollback plan. Review it whenever workflows or tools change. If you need to move hosting providers, use the website migration checklist and lower the risk by preparing the new service before changing the live DNS records.

Before declaring the connection complete, confirm these final items:

• The domain resolves to the intended hosting service.
• The root and preferred subdomain load the correct site.
• HTTP redirects to HTTPS as intended.
• The SSL certificate covers every public hostname.
• Email records remain present and email tests succeed.
• Forms, logins, integrations, and analytics use the correct domain.
• Monitoring, backups, and renewal reminders are active.
• Old DNS records and temporary deployment settings have been documented or removed.

Once these checks pass, save the final DNS configuration and deployment notes. That record turns the next domain connection, migration, or launch into a controlled operational task rather than a series of guesses.