How to Point a Domain to Shared Hosting: DNS Setup Guide

What DNS Setup Actually Means When You Point a Domain to Shared Hosting

The Translation Layer That Connects Names to Servers

When you register a domain name and purchase a shared hosting plan, those two services begin their existence as completely separate entities with no awareness of each other. Your domain name lives at a registrar — a company accredited to sell domain registrations — where it exists as an entry in the global Domain Name System that maps the human-readable name to a numerical IP address through a hierarchical lookup process involving root nameservers, top-level domain nameservers, and authoritative nameservers. Your shared hosting account lives on a server at your hosting provider, identified by an IP address that you receive in your welcome email, and that server is configured to serve the files for your website when it receives an HTTP request that includes your domain name in the Host header. The process of point domain to shared hosting is the act of creating the connection between these two independent services — updating the DNS configuration so that when someone types your domain into a browser, the DNS resolution process ultimately returns the IP address of your hosting server, and the browser connects to that server to retrieve your website.

In my fifteen years at Hosting Captain, I have observed that DNS configuration is the single step in the website setup process where beginners most frequently get stuck — not because DNS is conceptually difficult, but because it involves terminology and interfaces that are unfamiliar, the feedback loop is slow (changes can take hours to propagate globally), and the consequences of a misconfiguration are a broken website rather than a clear error message that explains what went wrong. This guide exists to eliminate that friction entirely. It explains, in plain language, every method for pointing a domain to shared hosting, the specific steps for each method, the trade-offs between methods, and the troubleshooting procedures for the most common failure modes. By the time you finish reading, you will understand exactly which method applies to your situation and how to execute it with confidence. If you are starting from absolute zero and need the foundational concepts — what a domain is, what hosting is, and how they relate — our shared hosting guide covers the architecture in beginner-friendly detail before you dive into DNS configuration.

The DNS configuration process is built on a few fundamental concepts that, once understood, make every subsequent DNS task straightforward. A domain name resolves to an IP address through a chain of DNS servers, each delegating responsibility for more specific portions of the namespace until the authoritative nameserver for your domain is reached. That authoritative nameserver stores DNS records — structured entries that map domain names to specific values — and the types of records most relevant to hosting setup are: A records, which map a domain name directly to an IPv4 address; AAAA records, which do the same for IPv6; CNAME records, which map a domain name to another domain name (creating an alias); and NS records, which specify which nameservers are authoritative for your domain. The two primary methods for pointing a domain to shared hosting — nameserver delegation and DNS record configuration — differ in which part of this system you are modifying, and understanding that difference is the key to executing either method correctly. Mozilla's web server fundamentals guide provides a broader context for how web servers process requests, and the DNS layer is the mechanism that ensures those requests arrive at the correct server in the first place.

Method 1 — Changing Nameservers (The Standard Approach)

What Nameservers Are and Why This Is the Recommended Method

Nameserver delegation is the most common and recommended method for connecting a domain to shared hosting because it is simple, reliable, and automatically configures all the subsidiary DNS records — A records, CNAME records, MX records for email, TXT records for verification — that your website and email need to function. When you change your domain's nameservers to those provided by your hosting company, you are delegating DNS authority for your domain to your hosting provider's DNS infrastructure. From that point forward, your hosting provider's nameservers answer all DNS queries for your domain, and your hosting provider's control panel becomes the interface through which you manage all DNS records. This centralization is the key advantage: you do not need to manually create A records, configure MX records for email, or add TXT records for SSL verification because the hosting control panel handles all of these automatically when you add your domain to your hosting account.

The process for changing nameservers follows a consistent pattern regardless of which domain registrar you use, though the specific menu labels vary. Log into your domain registrar's account dashboard, locate the domain you want to configure, find the DNS management or nameserver settings section (frequently labeled "DNS Settings," "Name Servers," "DNS Management," or "Custom DNS"), and change the nameserver selection from your registrar's default nameservers to the custom nameservers provided in your hosting welcome email. Hosting providers typically provide at least two nameserver addresses — ns1.yourhost.com and ns2.yourhost.com, or similar — and you should enter all of them to provide redundancy in case one nameserver becomes temporarily unreachable. Save the changes. The registrar's interface may warn you that changing nameservers will affect your website, email, and other services — this warning is accurate and expected, and it is the reason you are performing this change in the first place. DNS propagation — the time it takes for nameserver changes to be recognized by DNS resolvers worldwide — typically takes between one and twenty-four hours, though the majority of resolvers update within thirty minutes to two hours. During propagation, your site may appear intermittently available as different resolvers point to different servers, and this behavior is normal and temporary.

Post-Nameserver Configuration: Adding Your Domain to the Hosting Account

Changing nameservers tells the internet's DNS infrastructure to query your hosting provider's nameservers for your domain's records, but it does not automatically configure those records — you must also add your domain to your hosting account's control panel so that the nameservers have records to serve. This step is frequently overlooked by beginners, resulting in a situation where DNS is correctly delegated but the hosting server does not recognize the domain. In cPanel, the process is: navigate to the "Domains" section, click "Addon Domains" (or "Create a New Domain" depending on the cPanel theme), enter your domain name, and submit. cPanel automatically creates the document root directory where your website files will live, configures the virtual host entry in the web server configuration that tells the server to respond to requests for your domain, and generates the necessary DNS records — A record pointing to the server's IP address, MX records for email routing, and TXT records for SPF email authentication. This entire process takes under a minute, and once it completes, your domain is fully configured on both the DNS side (nameservers are authoritative) and the hosting side (server recognizes and serves the domain).

If your hosting provider uses a control panel other than cPanel — DirectAdmin, Plesk, or a proprietary panel — the same fundamental operation exists under different names: "Domain Setup," "Add Domain," "Website Setup," or similar. The principle is identical: you are telling the hosting server to create a hosting space for your domain and generate the DNS records that the nameservers will serve to querying resolvers. Some providers automatically add your domain during the signup process when you specify which domain you will be hosting, eliminating this manual step entirely — check your welcome email or control panel dashboard after signup to confirm whether your domain already appears in the hosted domains list before manually adding it.

Method 2 — Configuring DNS Records Manually (A Record Method)

When and Why to Use Manual DNS Records Instead of Nameserver Changes

The alternative to changing nameservers is to leave your domain's nameservers at your registrar's default and manually create the DNS records that point your domain to your hosting server's IP address. This method is appropriate in several specific situations: when your email is hosted on a service (Google Workspace, Microsoft 365) that you do not want to reconfigure, because changing nameservers would require recreating all email-related DNS records on the new nameservers; when you are using your registrar's advanced DNS features — geo-routing, DNS-based failover, or traffic management — that your hosting provider's nameservers may not support; or when you want to maintain DNS management at your registrar for administrative convenience and separation of concerns, keeping DNS and hosting in separate accounts under separate billing relationships.

The manual DNS record configuration requires you to create at minimum an A record — and optionally an AAAA record for IPv6 — that maps your domain name to the IP address of your shared hosting server. The A record is the fundamental DNS record type for pointing a domain to an IP address, and its structure is simple: a name (typically "@" to represent the root domain, meaning "yourdomain.com" itself, or "www" to represent the www subdomain), a record type (A), a value (an IPv4 address, such as "192.0.2.123"), and a TTL (Time to Live, the number of seconds DNS resolvers should cache this record before querying again). To configure this, log into your domain registrar's DNS management interface, locate the DNS records section (frequently labeled "DNS Management," "Advanced DNS," "DNS Zone File," or "Manage DNS Records"), and create a new A record with the name "@" and the value set to the IP address provided in your hosting welcome email. Create a second A record with the name "www" and the same IP address, or alternatively create a CNAME record for "www" that points to your root domain ("@") — both approaches work, and the A record method is marginally more robust because it eliminates an additional DNS lookup.

The key limitation of the A record method is that it only creates the fundamental domain-to-IP mapping; you must also manually configure any other DNS records your website, email, or third-party services require. MX records for email must be created manually if your email is hosted elsewhere; TXT records for SPF, DKIM, and DMARC email authentication must be created manually; TXT records for domain ownership verification with Google Search Console, Bing Webmaster Tools, or other services must be created manually; CAA records specifying which certificate authorities are authorized to issue SSL certificates for your domain should be created manually for security. Each of these record types has a specific format and content requirement that the service requiring the record provides in their setup documentation, and creating them correctly is a manual, error-prone process that the nameserver delegation method handles automatically. For these reasons, Hosting Captain recommends the nameserver delegation method for beginners and reserves the manual DNS record method for situations where specific technical constraints require maintaining DNS at the registrar.

Configuring Email DNS Records for Shared Hosting

MX Records and Email Routing When You Use Hosting-Provided Email

If your shared hosting plan includes email hosting and you intend to use it — creating addresses like [email protected] that send and receive through your hosting provider's mail servers — the DNS configuration for email is handled automatically when you use the nameserver delegation method because the hosting control panel generates the correct MX records during domain setup. An MX (Mail Exchanger) record tells the internet's email infrastructure which server should receive inbound email for your domain, and it includes a priority value that allows you to specify multiple mail servers in order of preference for redundancy. If you are using the manual A record method, you must manually create MX records that point to your hosting provider's mail server hostname, which is typically something like "mail.yourdomain.com" or a provider-specific hostname documented in their knowledge base. The MX record requires a name (usually "@" for the root domain), a record type (MX), a priority (lower numbers receive higher priority — "0" or "10" for the primary mail server), and a value (the mail server hostname).

Beyond MX records, email deliverability in 2026 requires three additional DNS record types that authenticate your domain's outgoing mail and prevent spammers from forging emails that appear to come from your domain. SPF (Sender Policy Framework) is a TXT record that lists the IP addresses and hostnames authorized to send email on behalf of your domain; receiving mail servers check this record and reject or quarantine email that originates from unauthorized sources. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing email headers that receiving servers validate against a public key published in a DNS TXT record, proving that the email was not altered in transit and genuinely originated from your domain. DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a TXT record that tells receiving servers what to do with email that fails SPF or DKIM checks — quarantine it, reject it, or deliver it anyway — and provides a reporting address where aggregate authentication failure reports are sent, giving you visibility into who is attempting to spoof your domain. When using the nameserver delegation method, the hosting control panel automatically creates SPF and DKIM records and provides instructions for creating DMARC; when using the manual DNS method, you must create all three records yourself using the values provided by your hosting provider's email setup documentation. For context on shared hosting email limitations beyond DNS configuration, our add-on domains guide covers how email accounts work when you host multiple domains on a single shared hosting plan.

Email Deliverability and the Shared IP Reputation Challenge

The DNS configuration for email on shared hosting is technically correct once MX, SPF, DKIM, and DMARC records are in place, but deliverability — whether your email actually reaches recipients' inboxes rather than their spam folders — depends on factors beyond DNS configuration, the most significant of which is your sending IP reputation. On shared hosting, your domain's outgoing email originates from the same IP address used by every other account on that server, and the reputation of that IP address is the collective result of every domain's sending behavior. If another customer on your shared server sends spam and causes the IP address to be added to a blocklist, your legitimate email may be rejected or filtered by receiving mail servers through no fault of your own. This is the structural limitation of shared hosting email that no amount of DNS configuration can overcome, and it is why businesses whose revenue depends on reliable email communication frequently pair their shared hosting with a dedicated email service — Google Workspace, Microsoft 365, or a specialized email hosting provider — while continuing to host their website on the shared plan. When using a dedicated email service, the DNS configuration changes: instead of pointing MX records to your hosting provider's mail server, you point them to the email service's mail server hostnames, and you configure SPF, DKIM, and DMARC using the values provided by the email service rather than the hosting provider.

Subdomains, Addon Domains, and Multi-Domain DNS Configuration

How to Point Multiple Domains to One Shared Hosting Account

Shared hosting plans that support multiple domains — typically mid-tier and premium plans — allow you to host several separate websites under a single hosting account, each with its own domain name, by using the addon domain feature in your control panel. An addon domain is a fully independent website that lives in its own directory on your hosting account, with its own files, its own database, and its own email addresses, but shares the resource allocation of the primary hosting account. The DNS configuration for an addon domain follows the same two methods as the primary domain: either change the addon domain's nameservers to your hosting provider's nameservers, or create A records at the addon domain's registrar that point to your hosting server's IP address. After the DNS configuration is in place, add the domain through your control panel's Addon Domains interface, which creates the directory structure and the DNS zone on the hosting side.

The important operational detail when managing multiple domains is that all addon domains share the same server IP address and the same resource limits (CPU, memory, inode count, I/O) as the primary domain. If one of your addon domains experiences a traffic spike that consumes the shared resource allocation, all domains on the account — including the primary domain — may experience degraded performance. For high-traffic or business-critical addon domains, Hosting Captain recommends hosting them on separate hosting accounts or on a VPS plan that provides guaranteed per-account resource isolation through CloudLinux LVE or similar technologies. Our how many websites guide covers the practical limits of multi-domain hosting in detail, including how to estimate the resource consumption of each site and recognize when you are approaching the capacity ceiling of your shared plan.

Subdomain DNS Configuration

A subdomain is a prefix added to your domain name — blog.yourdomain.com, shop.yourdomain.com, support.yourdomain.com — that creates a separate web-addressable namespace under your primary domain, typically pointing to a subdirectory of your main website or a separate application. From a DNS perspective, a subdomain is configured using an A record with the subdomain name as the record name (e.g., "blog" for blog.yourdomain.com) pointing to an IP address, or using a CNAME record that points the subdomain to another domain name. When using the nameserver delegation method, creating a subdomain through your hosting control panel (cPanel > Domains > Subdomains, or equivalent) automatically creates the necessary DNS records and the document root directory where the subdomain's files will be stored. The distinction between a subdomain and a subdirectory (yourdomain.com/blog/ versus blog.yourdomain.com) is primarily organizational and SEO-related rather than technical — search engines historically treated subdomains as somewhat separate from the main domain for ranking purposes, though this distinction has diminished in importance — and the choice between them should be based on whether the content under the subdomain is substantively different from the main site (subdomain appropriate) or an integral part of it (subdirectory appropriate).

Troubleshooting DNS Configuration Problems

The Systematic Approach to Diagnosing Why Your Site Is Not Loading

When you have completed the DNS configuration steps and your website does not load after a reasonable propagation period — we recommend waiting four hours, though most changes propagate within two — work through the following diagnostic sequence in order, because each step eliminates an entire category of potential causes before you move to the next. Step one: verify DNS propagation using a tool like DNS Checker or WhatsMyDNS, which queries DNS resolvers globally and shows which ones return your hosting server's IP address when queried for your domain. If most resolvers show the correct IP address but your local browser cannot reach the site, the issue is local DNS caching — flush your DNS cache on your device and try again. If most resolvers show an incorrect or missing IP address, the DNS change was not applied or has not propagated, and you should return to Step two. If most resolvers show the correct IP address but your browser displays an error, proceed to Step three.

Step two: confirm the nameserver change or A record was saved correctly. Perform a WHOIS lookup on your domain (using whois.domaintools.com or your registrar's WHOIS interface) and verify that the nameservers listed match those provided by your hosting company. If they do not match, the change was either not saved, was overwritten by your registrar's default settings, or was delayed by your registrar's processing queue — return to your registrar's DNS management interface and confirm the change is showing as active. For A record configurations, use the "dig" command (available through any online dig tool if you do not have command-line access) to query your domain's A record: "dig yourdomain.com A" should return the IP address you configured; "dig yourdomain.com NS" should return the nameservers currently authoritative for the domain — if these are still your registrar's nameservers and you intended to change them, the nameserver change did not take effect.

Step three: verify that your domain has been added to your hosting account. Log into your hosting control panel and confirm that your domain appears in the list of hosted domains (cPanel > Domains > Domains, or equivalent). If the domain is not listed, your hosting server does not have a virtual host configuration for it and will not serve your website even though DNS is correctly pointing to the server — add the domain using the Addon Domains or equivalent interface, wait five minutes, and test again. Step four: check for SSL issues by testing your site with "https://" explicitly in the URL — some hosting configurations redirect HTTP to HTTPS before the SSL certificate is fully provisioned, causing a certificate error that resolves itself within a few hours as AutoSSL completes. Temporarily test with "http://" to determine whether the site loads without encryption, confirming that DNS and hosting configuration are correct and that the issue is limited to SSL provisioning timing. If all four steps pass and your site still does not load, contact your hosting provider's support team with the specific results of each diagnostic step — the information you have already gathered will allow them to bypass tier-one troubleshooting and escalate directly to the appropriate engineering resource.

Common DNS Misconfiguration Patterns and Their Symptoms

Five DNS misconfiguration patterns account for the vast majority of "my site isn't loading" support tickets, and recognizing these patterns accelerates diagnosis. Pattern one: nameservers changed but domain not added to hosting account — DNS resolves correctly but the server returns a default page, a "no website configured" error, or a connection refused message. Solution: add the domain through the control panel. Pattern two: domain added to hosting account but nameservers still pointing to registrar — the hosting server is configured correctly but DNS queries never reach the hosting provider's nameservers, and visitors see the registrar's parked domain page or a DNS resolution error. Solution: update nameservers at the registrar. Pattern three: conflicting DNS records — both old A records and new NS records exist, and different resolvers use different records based on caching and which nameserver they query, causing intermittent site availability that varies by geographic location. Solution: remove old A records after changing nameservers, or choose one method (nameservers or A records) and commit to it entirely rather than mixing both.

Pattern four: www vs. non-www inconsistency — the root domain (yourdomain.com) resolves correctly but the www subdomain does not, or vice versa, because only one of the two A records was created. Solution: ensure both "@" (root) and "www" A records exist, both pointing to the hosting server IP address, or configure a redirect at the web server level (via .htaccess or control panel setting) that forwards one version to the other. Pattern five: propagation impatience masquerading as a configuration error — the DNS change was made correctly but insufficient time has elapsed for global propagation, and the site appears accessible from some networks but not others. Solution: wait. DNS propagation is a physical constraint imposed by caching at every level of the DNS hierarchy, and no amount of configuration adjustment can accelerate it beyond the TTL values set on the previous DNS records. Before changing nameservers, reducing the TTL on existing DNS records to 300 seconds (five minutes) speeds subsequent propagation by telling resolvers to cache the records for a shorter duration, but this step must be taken before the change, not after. After the change is made, patience is the only tool available, and in my fifteen years of managing DNS for thousands of domains, I have never seen a correctly configured nameserver change fail to propagate given sufficient time. For those considering a VPS instead of shared hosting, our VPS guide covers the DNS considerations specific to VPS environments, where you may have greater control over DNS configuration but also greater responsibility for getting it right.

Frequently Asked Questions

How long does it take for DNS changes to take effect?

DNS propagation — the time required for nameserver or DNS record changes to be recognized by DNS resolvers globally — typically takes between one and twenty-four hours, with the majority of resolvers updating within thirty minutes to two hours. The exact timing depends on the TTL (Time to Live) values set on the previous DNS records, the caching behavior of individual internet service providers' DNS resolvers, and the geographic distribution of the visitors testing the site. Changes are often visible within minutes from networks that have not recently queried your domain, while networks that have cached the previous records may take hours to update.

Which method is better — changing nameservers or using A records?

For beginners and most shared hosting customers, changing nameservers is the recommended method because it centralizes DNS management at the hosting control panel, automatically configures email, SSL, and verification records, and reduces the probability of configuration errors. The A record method is appropriate when email is hosted on a separate service, when advanced DNS features at the registrar must be preserved, or when administrative separation between DNS and hosting is desired. Both methods are functionally equivalent in terms of website performance and reliability when configured correctly.

What should I do if my email stops working after changing nameservers?

Email disruption after a nameserver change indicates that the MX records, SPF records, DKIM records, or a combination of these were not correctly recreated on the hosting provider's nameservers after the delegation. Log into your hosting control panel, navigate to the DNS Zone Editor (cPanel) or equivalent interface, and verify that MX records point to the correct mail server — if using hosting-provided email, these should have been created automatically during domain setup; if using a third-party email service like Google Workspace, you must manually create the MX records with the values provided by that service. Also verify that SPF and DKIM TXT records are present and contain the correct values, as missing or incorrect authentication records cause receiving mail servers to reject or quarantine your outgoing email.

Can I point my domain to shared hosting and keep my email on Google Workspace?

Yes. When using the nameserver delegation method, after changing nameservers, manually create the MX, SPF, DKIM, and DMARC records that Google Workspace provides in their setup documentation, using the DNS Zone Editor in your hosting control panel. When using the manual A record method at your registrar, the existing Google Workspace records at the registrar remain in place, and you add only the A records pointing to the hosting server IP address. In both configurations, web traffic routes to the hosting server while email traffic routes to Google's mail servers, and the two services coexist on the same domain without conflict.