Connect a Domain to Hosting: DNS and SSL Setup

Connecting a new domain requires three things to agree: the authoritative DNS records, the website configured on the hosting server, and the names covered by its TLS certificate. This guide works through choosing a DNS provider, preparing the website and records, publishing the change, and checking HTTPS and email. For an existing site, prepare the destination before switching traffic; a nameserver change does not copy files, databases or mailboxes.

Step 1: Understand How Domains, DNS and Hosting Fit Together

Before touching any control panels, it helps to have a mental model of what is happening behind the scenes. Confusing the roles of registrar, DNS and hosting can lead to changes in the wrong control panel.

At a high level:

• Domain registrar: Where you register and renew a domain, such as example.com.
• Authoritative nameservers: Publish the domain’s DNS zone. The registrar’s delegation identifies which nameservers are responsible.
• DNS records: Provide addresses and service information for web, email and other uses.
• Hosting server: Serves the website files and application data for the requested hostname.
• SSL/TLS: The certificate helps authenticate the server name; TLS encrypts HTTPS traffic. A valid certificate and correct server configuration work together.

These pieces can all be at the same provider or split across different ones. For example, you might have the domain at one registrar, DNS hosted on a specialized DNS or CDN service, and the site itself running on a VPS or shared hosting account.

If you want a deeper conceptual overview of how these layers work together, we already covered it in detail in our article what web hosting is and how domain, DNS, server and SSL work together. In this guide we will stay very practical and focus on the settings and records you need to connect a new domain; exact menu labels vary by provider and panel version.

Step 2: Decide Where Your DNS Will Live

The first decision is: which nameservers will answer for your domain? That answer decides where you will manage DNS records (A, CNAME, MX, TXT and so on).

In practice you have three common options:

1. Registrar DNS – You keep the default nameservers provided by your domain registrar and manage DNS records there.
2. Hosting provider DNS – If your hosting plan includes authoritative DNS, you can use the assigned nameservers and manage records through the provider’s DNS interface.
3. Third‑party DNS / CDN – You point your domain to external nameservers (for example a CDN or security provider) and manage DNS there.

There is no single “best” choice for everyone. Instead, think about:

• Simplicity: If your hosting plan includes DNS and email management in the same interface, using its nameservers can keep these tasks in one place.
• Features: If you need web traffic filtering, a WAF or edge rules, consider a CDN or reverse-proxy service with those features; external DNS hosting alone does not provide them.
• Team workflows: Agencies sometimes prefer keeping DNS separate from hosting so different teams manage them independently. Our guide DNS and domain access management for agencies goes deeper into this topic.

Our comparison of Cloudflare DNS and hosting DNS provides more context. You can retain working authoritative DNS and update the web records there; changing hosting does not require a nameserver change. If you do move DNS, prepare the complete destination zone before changing delegation, including email and service-verification records. For a planned move, lower the TTLs of the records you intend to change early enough for their previous TTLs to expire; review parent NS/DS lifetimes separately.

Step 3: Prepare the Domain and Website on Hosting

The hosting server must map the requested domain to the correct website before public DNS sends visitors there. Add the domain, select its document root and prepare the application. If the panel refuses a domain because its public DNS has not moved yet, coordinate destination provisioning with the provider before changing a working service.

How you “attach” a domain to the server depends on your control panel:

• Current cPanel: Open Domains → Create a New Domain and choose Registered Domain. Enter your domain. For a separate website, clear Share document root and select its directory; for another name serving the same content, evaluate the shared-root option. Quotas and available options depend on the host’s configuration.
• DirectAdmin: Use the domain-management workflow documented for your installed version and account permissions, then confirm the actual web root.
• Plesk Obsidian: Use Websites & Domains → Add Domain when your plan permits additional domains, and confirm the website hosting and document-root settings.

For a domain configured to host a website, the panel typically handles the following tasks, depending on the selected options:

• Create the web-server mapping or virtual host for the domain.
• Create or select the document root, such as a directory under public_html on an applicable account; use the path actually shown by the panel.
• Create local DNS records where configured. Those records affect public DNS only if that service publishes the authoritative zone, so verify the authoritative copy separately.

If you are on cPanel and wondering whether to use an addon domain inside one account or a completely separate account, our article Addon Domains vs separate cPanel accounts walks through the pros and cons for security, isolation and resource limits.

Upload the files or install the application in the selected document root, and prepare its database and settings. Preview it using a method that preserves the intended hostname and TLS SNI, such as an appropriate local hosts override. That override changes only your own resolution; it does not redirect a certificate authority’s public validation checks. Take backups and plan final data synchronization before an existing site is switched.

Step 4: Prepare the Complete DNS Zone

At the chosen DNS provider, prepare the records that map your hostnames to web and mail services. When changing DNS providers, create and verify the new zone before Step 5. When retaining the existing provider, prepare only the required web-record changes for the cutover and preserve unrelated records. Keep an export or inventory of the old zone for comparison and recovery.

When choosing web hosting, verify whether the plan includes authoritative DNS and whether adding a domain creates initial records. Review any generated records and add or adjust them as needed.

Our DNS records guide explains the record types. Use the values supplied for your actual services; the following names and addresses are documentation examples. Check how your panel represents the zone apex and fully qualified names.

4.1 A and AAAA records (web site)

The A record points a hostname to an IPv4 address (e.g., 203.0.113.10). The AAAA record does the same for IPv6 (e.g., 2001:db8::10).

Common patterns:

• A: Point example.com to the actual web server IPv4 address; 203.0.113.10 is only an example.
• AAAA: Publish an IPv6 address only after routing, listeners, firewall rules and the HTTPS/ACME path work over IPv6. A stale AAAA record can break access or validation even when the A record is correct.
• www: A typical alias is www.example.com CNAME example.com.. Your panel may use @ or another apex notation; verify the resulting name and target.

DNS directs clients to an address; the web server selects the website using the requested hostname, and TLS SNI helps select the certificate for HTTPS. Configure both the root domain and www when you use them. A CNAME follows DNS data and does not perform an HTTP redirect or change the URL in the browser.

4.2 CNAME records (subdomains, CDNs, services)

CNAME records are aliases: instead of pointing directly to an IP, they point one hostname to another hostname. Use them when:

• You have a subdomain like blog.example.com hosted on another service.
• You connect to a CDN or SaaS that gives you a target hostname to use.
• You want www to follow the root domain without managing separate A records.

A standard CNAME cannot coexist with ordinary data at the same owner name. The zone apex already needs NS and SOA records, so use A/AAAA there or a provider-specific ALIAS/ANAME or flattening feature where supported. At a www alias, remove conflicting A/AAAA records only after confirming the intended change; do not delete unrelated zone records.

4.3 MX records (email routing)

Use the MX records prescribed by the service receiving mail for your domain. A web-hosting move does not require a mail-provider move. Preserve existing MX, authentication and service records when email is staying where it is; changing nameservers does not migrate mailboxes.

If your actual mail service uses a host such as mail.example.com, its provider might require records in this form; these are not DCHost connection details:

• example.com MX 10 mail.example.com.
• mail.example.com A 203.0.113.20, replacing the documentation address with the real mail server address.

External mail services normally provide their own MX targets; use their exact values rather than pointing mail at the web server. An MX target is a hostname with address records, not an IP literal or CNAME alias. On cPanel, check Email Routing against the real mail arrangement: automatic detection reads the local zone entry and does not query external authoritative DNS. Confirm remote versus local delivery with the provider where necessary.

4.4 TXT records for SPF, DKIM and DMARC (email deliverability)

Configure the authentication required by your sending services and recipients, preserving existing working records during the DNS move:

• SPF: A TXT policy authorizes sending IPs for the envelope MAIL FROM/HELO identity, not the visible From header. Keep one valid SPF policy at each evaluated name and include all legitimate sending services.
• DKIM: The sender signs with a private key; recipients retrieve the selector’s public key from DNS. Publishing a TXT record alone does not enable signing at the sender.
• DMARC: At least one successfully authenticated SPF or DKIM identity must align with the visible From domain for a pass. When neither produces an aligned pass, the published policy can influence receiver handling; local policy still applies.

The exact values depend on how you send mail (web hosting, dedicated email service, transaction email provider, etc.). We explain these protocols end‑to‑end in our guide Inbox or spam? A step‑by‑step guide to SPF, DKIM, DMARC and rDNS. If email is important for your business, it is absolutely worth setting these up correctly from day one.

4.5 Other records you might need

Depending on your setup, you might also see:

• TXT records for verification (Google Search Console, Microsoft, SaaS apps).
• SRV records for some services (VoIP, chat, auto‑discover for email clients).
• CAA records to restrict which Certificate Authorities may issue SSL for your domain.

Whether these records are needed depends on the services you use. Preserve verification and SRV records for existing integrations. If CAA is present, confirm it authorizes the intended CA and any wildcard issuance; do not remove all CAA records as a shortcut. CAA changes do not revoke certificates that have already been issued.

Step 5: Publish the Record or Nameserver Change

With the website and records prepared, publish only the changes your plan needs. If authoritative DNS stays where it is, update the web A/AAAA and relevant www record there; leave nameservers and unrelated mail records alone. If DNS is moving, confirm the new nameservers already answer correctly for the whole zone before updating the registrar.

5.1 Verify the assigned nameservers

If your hosting plan includes DNS hosting, obtain its assigned nameservers from the provider’s account details or documentation. The following hostnames are illustrative only; do not enter them at your registrar:

• ns1.example.net
• ns2.example.net

Use the actual nameserver hostnames assigned by your DNS provider. Editing records in a hosting panel affects public DNS only when those records are published by the domain’s authoritative DNS service.

5.2 Check DNSSEC, then update delegation

If DNSSEC is enabled, use a coordinated key-preserving migration when both DNS operators support it. Otherwise, remove the old DS record through your registrar while keeping the old zone signed and available; confirm removal at the parent and wait for the previous DS TTL to expire before changing nameservers. This creates a temporary interval without DNSSEC validation. After the new delegation has settled and the new provider’s signed zone is verified, publish its new DS record. An A/AAAA-only change at the same DNS provider does not itself require disabling DNSSEC.

For a nameserver switch, open the domain’s Nameservers section at the registrar after the site, zone and DNSSEC preparation is complete:

1. Select the registered domain.
2. Choose custom nameservers or the equivalent option.
3. Enter all nameserver hostnames actually assigned by the new DNS provider; do not use this guide’s examples.
4. Save the change and check the parent delegation and answers from the new authoritative servers.
5. Keep the old DNS and hosting available while caches and data migration are being checked; only retire them after remaining dependencies and traffic are accounted for.

Once the registrar publishes the new delegation, resolvers can discover the new DNS provider’s nameservers. Cached delegation and record data mean that the change will not be visible everywhere immediately.

5.3 Check cached delegation and record answers

Changes become visible when providers publish them and cached data expires. There is no universal 24–48-hour guarantee. Web-record TTLs, parent NS/DS delegation TTLs and cached negative answers such as NXDOMAIN can have different lifetimes. Clearing one device’s cache does not clear every recursive resolver.

Two key tips to avoid surprises:

• Compare answers: Check the parent delegation, authoritative servers and more than one recursive resolver. A missing record or DNSSEC mismatch needs correction; waiting alone will not repair it.
• Plan TTL changes in advance: Lower the TTLs of the records you intend to change early enough for their previous TTLs to expire. This does not retroactively shorten cached answers or parent NS/DS delegation data. Our TTL planning guide for migrations explains the approach; low TTL alone does not guarantee continuity.

For a migration, retain the old working service during the transition and monitor both environments. DNS cannot synchronize orders, uploads, sessions or database writes; plan a final data sync, a controlled write strategy or a maintenance window as the application requires.

Step 6: Enable SSL and HTTPS for Your New Domain

Verify HTTPS before accepting sensitive information from visitors. HTTP traffic is not encrypted, while a certificate file alone does not establish a working HTTPS service. For a migration, a supported DNS-01 flow or correctly routed validation can prepare a certificate before the web cutover; a local preview override alone cannot do that.

6.1 Choose between free and commercial SSL

Ask whether your plan includes automated issuance and renewal of a TLS certificate. Let’s Encrypt issues free domain-validated certificates, but the host must enable a supported ACME workflow and complete validation. The price of a certificate alone does not determine the TLS security of a configured service.

OV and EV add organization-validation requirements. Wildcard describes name coverage rather than a separate validation level; Let’s Encrypt can issue wildcard certificates through DNS-01. A wildcard such as *.example.com covers first-level names such as www.example.com, but not the apex example.com or deeper names such as a.b.example.com. Include those names separately where needed.

We break down the differences and when to consider paid options in our guide to DV vs OV vs EV vs wildcard SSL certificates.

6.2 Issue SSL from your control panel

Use the interface and validation method supported by your actual panel version and account:

1. Check each requested hostname and the selected challenge method. Let’s Encrypt HTTP-01 needs the correct /.well-known/acme-challenge/ response through public port 80; proxies, CDN routing and multiple web servers must not send validation to the wrong content.
2. Check both published A and AAAA records. Let’s Encrypt initially prefers IPv6, and working IPv4 is not a universal fallback for an incorrect IPv6 challenge response.
3. In current cPanel, use SSL/TLS Status or its unified SSL/TLS Certificates view to inspect names, coverage and errors. Account eligibility and AutoSSL execution are controlled by the provider/server administrator; available user actions vary.
4. In DirectAdmin, when enabled, use SSL Certificates → ACME settings. In other panels, follow the installed version’s certificate workflow instead of assuming an identically named Issue button.
5. DNS-01 proves control with a TXT value under _acme-challenge and supports wildcards. Automate authorized DNS updates for renewal. cPanel’s built-in Let’s Encrypt wildcard workflow requires local cPanel DNS or its DNS cluster; third-party authoritative DNS needs a separately supported approach.
6. After issuance, verify the certificate actually served by the website, its SAN names, chain and validity period.

Confirm that automatic renewal is enabled and monitor expiry and validation failures. Changes to DNS, CAA, challenge routing or DNS API access can prevent renewal. Our Let’s Encrypt and renewal guide provides additional context; verify that the renewed certificate is actually deployed to the service.

6.3 Force HTTPS and update URLs

After the intended domain names serve valid HTTPS, configure web redirects and application URLs. A redirect alone does not fix mixed content embedded in the page:

• Use the appropriate panel, Apache or Nginx setting for permanent HTTP-to-HTTPS redirects. Preserve paths and query strings, and test for loops across root and www names.
• Update application site URLs, canonical references, internal links and sitemaps to the chosen HTTPS form.
• Find hard-coded HTTP resources. Before database-wide URL replacement, take a recoverable backup and preview changes with a tool that preserves serialized application data.
• Consider HSTS only after HTTPS and renewal are reliable. Start with a short lifetime; do not apply includeSubDomains or preload until the full affected scope is ready.

Our HTTPS migration guide covering redirects and HSTS explains further checks. Correct redirects can support URL migration, but no change can guarantee unchanged search rankings.

6.4 Troubleshoot common SSL errors

Sometimes SSL does not work on the first try. Common problems include:

• The certificate does not cover the exact root or www hostname being requested, or its chain or validity period is wrong.
• An A or AAAA record still reaches the old server while only the new one has the intended certificate.
• A DNSSEC mismatch causes DNS validation failure before HTTPS can be reached.
• HTTP resources remain in the page, producing mixed-content errors even though the main page uses HTTPS.

We maintain a practical troubleshooting guide covering these scenarios and more in our article on fixing common SSL certificate errors, mixed content and browser warnings.

Step 7: Test, Troubleshoot and Go Live Safely

At this point, verify the following:

• The intended authoritative nameservers publish the complete required zone.
• Web A/AAAA records and any www alias match the tested service; an AAAA record is present only for working IPv6.
• The hosting server maps the requested hostname to the correct document root.
• HTTPS presents a valid certificate for the names used, and email still follows the intended provider.

Before announcing your new site, complete the checks below and investigate any inconsistent results.

7.1 Check DNS resolution

Use tools such as dig, nslookup or online DNS checkers for these checks:

• Compare authoritative NS, A/AAAA and relevant CNAME answers with the prepared values, then compare results through more than one resolver.
• Check MX and SPF/DKIM/DMARC/service-verification records against the mail and application inventory.
• Look for unintended conflicts, such as a CNAME alongside A/AAAA at the same name. Multiple A, AAAA or MX records can be intentional; do not delete them just because several answers exist.
• Where DNSSEC is enabled, verify the DS/DNSKEY/signature chain. One successful A lookup does not establish global propagation or successful DNSSEC validation.

NXDOMAIN means the queried name was reported as nonexistent; it can also persist in a negative cache. SERVFAIL can have other causes, including DNSSEC validation failure. Compare delegation and authoritative answers before assuming more waiting will fix the problem. Our DNS error troubleshooting guide provides further diagnosis.

7.2 Verify SSL and HTTPS

Next, open your site in multiple browsers and on different networks:

• Inspect the browser’s connection and certificate details; security icons differ between browsers, so a padlock is not a universal test.
• Confirm exact hostname coverage, the chain and expiry; a wildcard does not automatically cover the apex or deeper subdomains.
• Test root and www HTTPS URLs, the chosen redirect behavior and both IP families when IPv6 is published.
• Test forms and incoming/outgoing email, and inspect the relevant authentication results and application logs.

For a deeper check, you can use external SSL test tools to analyze protocol versions, ciphers and certificate chain, especially if you run a high‑traffic or e‑commerce site.

7.3 Run a quick launch checklist

Finally, it is worth running through a simple launch checklist on the hosting side:

• Confirm backups cover the needed data and that recovery has been checked.
• Keep the application and a supported runtime updated, and confirm applicable firewall, access-control and brute-force protections. WAF availability depends on the service.
• Review application-specific PHP limits and caching rather than applying a generic setting to every CMS.
• For a migration, confirm the final data sync and remaining dependencies before decommissioning the old service.

We created a detailed new website launch checklist for hosting‑side SEO and performance that you can adapt for each project. It covers things like robots.txt, redirects, caching headers and log monitoring so you do not discover issues days later via angry users.

A Repeatable Domain-to-Hosting Checklist

The order is: choose authoritative DNS, prepare the website and complete zone, plan any DNSSEC transition, then publish the required record or nameserver changes and verify HTTPS and email. Keeping working DNS is a valid option. Caches and application data need their own transition plan; neither a low TTL nor a successful browser visit guarantees a seamless migration.

The same checks apply when comparing shared hosting, VPS or a dedicated server. If you are considering colocation, confirm availability and management responsibilities separately. With DCHost or another provider, clarify who handles authoritative DNS, panel setup, certificate renewal, backups and email routing for the exact plan.

Combine this guide with our first-month domain checklist when preparing a new project. Use the results to agree which tasks the provider performs and which remain with you, and retain the DNS inventory and recovery plan for later changes.