Billy Wallson
Senior DirectorBilly Wallson is a senior operations director with over 15 years of experience scaling remote teams and implementing lean business strategies.
If you have just purchased a domain name and a hosting plan, the next logical step is connecting the two so that visitors typing your domain into a browser actually see your website. This process — commonly called pointing a domain to hosting — is one of the most fundamental skills every website owner should understand. Without it, your domain is just an empty address sign pointing nowhere, and your hosting account is a collection of files nobody can reach. The good news is that once you grasp a few DNS basics, the entire procedure takes less than ten minutes, even if you have never touched a technical setting before. At Hosting Captain, we have guided thousands of beginners through this exact workflow, and we have distilled everything you need to know into this comprehensive guide. By the time you finish reading, you will know exactly how to point a domain to your hosting using either the nameserver method or the A record method, how to verify everything is working, and how to troubleshoot common issues that trip up newcomers.
The Domain Name System, or DNS, is often described as the phonebook of the internet — and for good reason. In the same way a phonebook maps a person's name to their telephone number, DNS maps human-friendly domain names like hostingcaptain.com to machine-readable IP addresses like 192.168.1.1. When someone types your domain into their browser, their computer asks a network of DNS servers a straightforward question: "What IP address does this domain point to?" The DNS servers respond with the correct IP, and the browser connects to that address, loading your website. This entire lookup happens in milliseconds, yet it involves a remarkably distributed hierarchy of root servers, top-level domain (TLD) servers, and authoritative nameservers all collaborating behind the scenes. Understanding this phonebook analogy is the foundation for everything that follows, because pointing a domain to hosting is essentially telling the DNS system which IP address or which nameserver should be the authoritative source for your domain. Once you internalize that, the steps ahead become intuitive rather than mysterious.
For a deeper dive into the fundamentals that underpin how websites work, we recommend reading our guide on web hosting fundamentals, which explains the server side of the equation in plain English. You may also find the Mozilla Developer Network's domain name guide helpful for a broader technical perspective on how domain names fit into the web ecosystem.
When it comes to actually connecting your domain to your hosting account, you have two primary methods at your disposal. The first and most common approach — especially for shared hosting, WordPress hosting, and managed hosting plans — is the nameserver method. With this method, you delegate full DNS authority to your hosting provider by pointing your domain's nameservers to the ones your host provides. Once you do that, your hosting company handles all DNS records automatically, including the A record that maps your domain to your server's IP address, MX records for email, and any subdomain entries. The second method, known as the A record method, gives you more granular control. Instead of handing over the entire DNS management to your host, you keep DNS control at your domain registrar and manually create an A record that points your domain directly to your hosting server's IP address. Both methods achieve the same end result — visitors reaching your website — but they differ in convenience, flexibility, and the scenarios where each one makes sense.
The nameserver method is what we at Hosting Captain recommend for the vast majority of beginners, and it is the approach most hosting providers will guide you toward in their onboarding emails. When you use the nameserver method, you are telling the global DNS system: "For any question about my domain, ask my hosting company's nameservers — they are the authority." This means your host automatically configures the correct A record, sets up email-related MX records if you are using their email service, and handles any future IP address changes behind the scenes without you needing to lift a finger. The trade-off is that you lose the ability to manage individual DNS records from your domain registrar's control panel, but for most website owners who simply want their site to work reliably, that trade-off is well worth it. This method also eliminates a whole category of potential errors — mistyped IP addresses, forgotten www records, or misconfigured subdomains — because your hosting provider's system generates all the necessary DNS entries automatically.
The A record method is the preferred choice when you want to keep DNS management centralized at your domain registrar while pointing only the website traffic to your hosting server. This scenario commonly arises when you use a third-party email service like Google Workspace or Microsoft 365 and need to maintain custom MX records at your registrar, or when you run multiple services on different servers and want fine-grained control over each subdomain's destination. With the A record method, you log into your registrar's DNS management panel, locate the existing A record (or create a new one), and enter the IP address of your hosting server. You will typically need at least two A records — one for the root domain (@) and one for the www subdomain — to ensure that visitors can reach your site regardless of whether they type the www prefix. This method demands a bit more attention to detail, but it preserves your independence and makes it easier to switch hosting providers down the line without a full DNS migration.
Now that you understand the two approaches, let us walk through the nameserver method in detail. This is the path that nine out of ten Hosting Captain customers follow, and it consistently proves to be the fastest and least error-prone way to get a new site online. You will need access to two accounts: your hosting account (where your website files live) and your domain registrar account (where you purchased your domain). If you purchased both your domain and hosting from the same company, this process is often handled for you automatically, but it is still worth understanding the mechanics. Keep both accounts open in separate browser tabs as you follow the steps below, and do not hesitate to contact your hosting provider's support team if any detail is unclear — reputable hosts are accustomed to walking new customers through exactly these instructions.
Every hosting company operates its own set of nameservers, and you need to know exactly what those nameservers are before you can point your domain. The most reliable place to find them is in the welcome email your hosting provider sent when you first signed up — look for lines labeled "Nameserver 1" and "Nameserver 2," or something similar. If you cannot locate that email, log into your hosting control panel (cPanel, hPanel, or your provider's custom dashboard) and check the account information or DNS section; most hosts display your assigned nameservers prominently on the main dashboard. Typical nameserver addresses look something like ns1.hostingcaptain.com and ns2.hostingcaptain.com, though exact formats vary by provider. Make a note of both — you will almost always receive at least two nameservers for redundancy, and you should enter all of them at your registrar, never just one. If your host provides more than two (some offer three or four for enhanced resilience), include every single one.
Open a new browser tab and log into the website where you originally purchased your domain name. Popular registrars include Namecheap, GoDaddy, Google Domains, Cloudflare, Porkbun, and Dynadot, though there are hundreds of accredited registrars worldwide. Once logged in, navigate to your list of domains — often labeled "My Domains," "Domain List," or "Domain Management" — and locate the specific domain you want to point to your hosting account. Click on that domain to open its management or settings page. From there, look for an option labeled "Nameservers," "DNS Management," or "DNS Settings." The exact terminology and placement vary between registrars, but the concept is universal: you are looking for the field where the current nameserver entries are displayed and can be edited. If you see default nameservers provided by the registrar itself (often branded with the registrar's name), those are the ones you are about to replace.
On the nameserver settings page, you will typically see a radio button or dropdown that lets you choose between "Use default nameservers" and "Use custom nameservers." Select the custom or manual option, which should reveal two or more text input fields. Carefully type the nameserver addresses you gathered from your hosting provider in Step 1 — one per field — ensuring there are no typos, extra spaces, or trailing dots. A single mistyped character in a nameserver address will prevent your domain from resolving correctly, so double-check each entry character by character before saving. Once you are satisfied, click the Save or Update button. Most registrars display a confirmation message indicating that your nameserver change has been submitted, often accompanied by a warning that changes may take up to 48 hours to propagate globally. This leads us directly to the final and most patience-testing step.
DNS propagation is the global process by which your nameserver change spreads across thousands of DNS servers worldwide, and it is not instantaneous. After you save your new nameservers at the registrar, the change must be communicated from the registry for your top-level domain (.com, .org, .net) to internet service providers and their recursive DNS resolvers around the world. During this window — which typically ranges from a few minutes to 48 hours, though 2 to 6 hours is common in practice — some visitors may still be directed to your old DNS configuration while others see the new one. This inconsistency is perfectly normal and does not indicate an error. Our advice at Hosting Captain is simple: make yourself a cup of coffee, work on something else, and check back after a few hours. Impatience during propagation leads to more unnecessary support tickets than any other DNS-related issue we see. For a broader look at diagnosing site accessibility problems, bookmark our guide on how to troubleshoot a website that won't load — you will want it in your toolkit eventually.
If you have chosen the A record method — either because you need granular DNS control or because your hosting provider specifically instructed you to use an IP address — the steps below will walk you through the process. The A record method keeps your nameservers pointed at your domain registrar while adding a specific DNS record that maps your domain name to your hosting server's IP. This approach requires careful attention to detail, because a single digit wrong in the IP address or a missing record for the www version of your domain can result in a site that does not load. Follow each step methodically, and when in doubt, consult your hosting provider's documentation or support team for the exact IP address you should use. Once configured correctly, this method is just as reliable as the nameserver approach and offers superior flexibility for advanced setups.
Before you can create an A record, you need the exact IPv4 address of the server where your hosting account resides. This information is typically found in the same welcome email that contains your nameserver details, often listed as "Server IP," "Shared IP," or "Website IP Address." If you are using cPanel, the IP address is usually displayed on the right-hand sidebar of the main dashboard under "General Information" or "Shared IP Address." For custom hosting dashboards, check the account details, technical information, or server status section. The IP address will be a series of four numbers separated by periods, such as 203.0.113.42. Copy this address exactly — do not confuse it with your dedicated IP if you have one, unless your host has explicitly told you to use that. If you cannot locate the IP, contact your hosting provider's support team and ask directly: "What is the IP address I should use for my A record?" They handle this question daily and will provide the correct answer within minutes.
Log into your domain registrar's control panel and navigate to the DNS management or DNS zone editor for your domain. This is the same area where you would change nameservers, but instead you will be editing individual DNS records. Look for an existing A record — it may already be present if your registrar provided a default parking page — and either edit it or delete it and create a new one. The host or name field for the root domain is typically represented by the @ symbol, though some registrars simply leave it blank or label it as "root." In the value or points-to field, paste the IP address you copied in Step 1. Leave the TTL (Time to Live) at its default value unless you have a specific reason to change it; a TTL of 3600 seconds (one hour) or the registrar's automatic setting is perfectly fine for most situations. Save the record. You have now instructed the DNS system to resolve your bare domain — for example, yourdomain.com — to your hosting server's IP address.
Creating the root A record is only half the job. You must also add an A record for the www subdomain so that visitors who type www.yourdomain.com reach your site as well. In the same DNS zone editor, create a second A record. This time, set the host or name field to www, and enter the identical IP address in the value field. Do not assume that the www version will work automatically — it will not, unless you explicitly create this record or your hosting provider's system does it for you under the nameserver method. Leaving out the www record is one of the most common DNS oversights we see at Hosting Captain, and it creates a frustrating experience where your site loads perfectly without the www prefix but returns an error when someone includes it. If you use additional subdomains such as blog, shop, or app, create corresponding A records for those as well, each pointing to the same hosting IP or to the specific IP provided for that service.
As an alternative to creating a separate A record for www, some website owners prefer to use a CNAME record instead. A CNAME, or Canonical Name record, does not point directly to an IP address but rather aliases one domain name to another. In practice, you would create a CNAME record with the host set to www and the value set to your root domain — for example, yourdomain.com. This tells DNS, "Treat www.yourdomain.com exactly the same as yourdomain.com, and resolve it to whatever IP address the root A record points to." The practical advantage of using a CNAME for www is that if your hosting server's IP address ever changes, you only need to update a single A record (the root), and the www version automatically follows. Both approaches are valid, and your choice depends on your preference. However, do not create both an A record and a CNAME record for the same hostname, as conflicting records can cause unpredictable resolution behavior.
DNS propagation is arguably the most misunderstood aspect of pointing a domain to hosting, and unrealistic expectations about timing cause more frustration than any other part of the process. When you update your nameservers or modify an A record, the change is not pushed out instantly to every corner of the internet. Instead, it must cascade through a hierarchy of DNS servers — from the top-level domain registry to your registrar's DNS servers, then outward to the recursive resolvers operated by internet service providers, mobile carriers, corporate networks, and public DNS services like Google DNS and Cloudflare. Each of these intermediate servers caches DNS records for a period of time determined by the TTL value, and until that cache expires, the server continues to serve the old information. The widely cited "24 to 48 hours" propagation window is a conservative upper bound that covers the worst-case scenario where every server in the chain has a long TTL. In reality, propagation in most regions completes within 2 to 6 hours, and many users see the change within 30 minutes.
During the propagation window, you might experience inconsistent behavior: your site loads on your phone's cellular connection but not on your home Wi-Fi, or it works for a friend in another city but not for you. This is completely normal and does not signify a configuration error. The inconsistency arises because different networks query different DNS resolvers, each with its own cache state. To check whether propagation has reached your location, you can use online tools such as WhatsMyDNS.net or DNSChecker.org, which query DNS servers from dozens of global locations and report back which ones return the new IP or nameservers versus which ones still show the old values. These propagation checkers are invaluable for diagnosing whether an issue is a genuine misconfiguration or simply a matter of waiting. For a deeper exploration of how hosting environments affect site reliability and accessibility — including compliance considerations that may influence your choice of server location — see our article on hosting compliance and GDPR data residency.
Over the years, the Hosting Captain support team has catalogued the same handful of mistakes cropping up again and again among users who are pointing a domain to hosting for the first time. By familiarizing yourself with these pitfalls now, you can sidestep hours of debugging and avoid the sinking feeling of a website that stubbornly refuses to load. The most frequent error we encounter is typing the wrong nameserver address. Nameserver hostnames are long and often contain multiple subdomains, making them easy to mistype — and even a single misplaced letter renders the entire configuration invalid. Always copy and paste nameserver addresses directly from your hosting provider's dashboard or welcome email rather than retyping them manually. Another perennial classic is entering only one nameserver when your host provides two or more. Nameservers are designed to operate in redundant pairs; if you only enter one, you lose that redundancy, and if that single nameserver experiences an outage, your entire domain stops resolving. Always enter every nameserver your host provides.
On the A record side, IP address typos are the number one culprit. An IP address like 203.0.113.42 can easily become 203.0.13.42 with a single missing digit, and the result is a site that points to the wrong server — or to no server at all. Verify the IP digit by digit against the source. The forgotten www record is another trap: users diligently create an A record for the root domain but neglect to add one for the www subdomain, leaving a significant portion of their traffic stranded. Depending on your hosting platform's configuration, visitors who include www may see an error page or a "server not found" message. Finally, not waiting long enough for propagation is less a configuration mistake and more a psychological one — but its practical consequences are identical. Users who check their site ten minutes after making a DNS change, see that it has not propagated, assume something is broken, and start making additional changes — which only resets the propagation clock and compounds the problem. Set your DNS configuration once, confirm it is correct, and then give it time.
Once you have waited a reasonable amount of time for propagation — at least two hours for routine changes — it is time to verify that your domain is pointing to the correct destination. The simplest method is to open a web browser and type your domain name into the address bar. If your hosting account already has content uploaded (even a default placeholder page), you should see that content load. If your hosting account is empty, you may see a directory listing, a "Coming Soon" page from your host, or an index page indicating that the server is reachable but has no content. Any of these outcomes confirms that DNS is working and your domain is correctly pointed. If you instead see a registrar's parking page, a "This domain is not connected to a website" message, or a browser error like "DNS_PROBE_FINISHED_NXDOMAIN," the pointing is not yet complete or there is a configuration issue that needs attention.
For a more technical verification, you can use command-line tools available on every operating system. On Windows, open Command Prompt and run nslookup yourdomain.com. On macOS or Linux, open Terminal and use dig yourdomain.com or host yourdomain.com. These commands query DNS directly and return the IP address your domain currently resolves to. Compare that IP address against the one provided by your hosting company. If they match, your domain is pointing correctly. If the IP belongs to your registrar or shows a different server entirely, the DNS change has either not propagated yet or was not configured correctly. Online DNS lookup tools such as MXToolbox or IntoDNS provide a more user-friendly interface for the same information and can also check for common configuration issues like missing nameservers or DNSSEC conflicts. For a comprehensive understanding of the hosting environment your domain now connects to, read our complete guide to shared hosting, which covers what happens on the server side once your domain successfully points.
If your domain still does not resolve after 48 hours, something beyond normal propagation delay is at play, and methodical troubleshooting is the fastest path to a resolution. Start by re-verifying your nameserver or A record entries against the exact values provided by your hosting company. Log back into both your hosting dashboard and your domain registrar, and compare the entries side by side. Pay particular attention to subtle differences: a trailing period on a nameserver (some systems add it automatically, others require it), an IP address written as 203.0.113.42 in one place and 203.0.113.042 in another (leading zeros in IP octets can cause issues with certain systems), or a CNAME accidentally created for the root domain (which violates DNS specifications and causes erratic behavior). Correct any discrepancies and save the changes, then allow another propagation cycle.
Another common cause of persistent pointing failures is DNSSEC misconfiguration. DNSSEC is a security extension that cryptographically signs DNS records to prevent spoofing, and if your domain had DNSSEC enabled at your previous DNS provider, the associated DS records must be updated or removed when you switch nameservers. If your new hosting provider does not support DNSSEC and your registrar still has the old DS records in place, DNS resolution will fail entirely as a security measure. Check your domain registrar's DNSSEC settings and either disable DNSSEC or update the DS records to match your new nameserver configuration. Additionally, if you recently transferred your domain between registrars, a mandatory 60-day lock may prevent nameserver modifications — contact your registrar to confirm there are no active locks or transfer holds on the domain. Finally, clear your local DNS cache, because your own computer may be holding onto the old DNS information and displaying a stale error page even though the rest of the world sees your site correctly. On Windows, run ipconfig /flushdns in Command Prompt; on macOS, use sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder; and on Linux, the command varies by distribution but commonly involves restarting the systemd-resolved service. After flushing, open your site in a private or incognito browser window to bypass any remaining browser-level caching.
While the actual configuration process takes less than ten minutes, DNS propagation — the time it takes for your changes to be recognized globally — typically ranges from 2 to 48 hours. In practice, most changes propagate within 2 to 6 hours, and many users see their site go live within 30 minutes. The variability depends on factors such as your domain's TLD registry, your internet service provider's DNS caching policies, and the TTL values set on your DNS records before the change.
Yes, you can use the A record method instead. By keeping your nameservers at your domain registrar and creating an A record that points to your hosting server's IP address, you can connect your domain without delegating full DNS authority to your hosting provider. This approach is particularly useful if you manage email through a third-party service and need to retain control over MX records at your registrar.
Visitors who type your domain with the www prefix (for example, www.yourdomain.com) will encounter an error or a "server not found" message. The root domain (without www) and the www subdomain are treated as separate DNS entries, and you must configure an A record or CNAME record for both to ensure all visitors reach your site regardless of how they type the address. This is one of the most common oversights in DNS configuration.
This is a classic symptom of DNS propagation in progress. Your mobile carrier's DNS servers may have already received the updated DNS records, while your home internet provider's DNS servers are still serving cached, outdated information. The inconsistency is temporary and typically resolves within a few hours as all DNS servers refresh their caches. Using a DNS propagation checker tool can confirm whether the discrepancy is due to propagation rather than a configuration error.
In most cases, no — when you purchase a domain and hosting from the same provider, the company typically configures the DNS connection automatically. However, it is always worth verifying. Check your hosting dashboard to confirm that your domain is listed as "connected" or "active," and visit your domain in a browser to ensure your site loads. If it does not, contact your provider's support team, as occasional provisioning gaps can occur.
An A record maps a domain name directly to an IPv4 address (for example, 203.0.113.42), while a CNAME record maps a domain name to another domain name, creating an alias. For instance, a CNAME record for www.yourdomain.com pointing to yourdomain.com tells DNS to resolve www to whatever IP address the root A record specifies. CNAME records cannot be used for root domains (the apex), which is why every domain needs at least one A record. CNAMEs are convenient for subdomains because they reduce the number of IP addresses you need to maintain.
This indicates that either propagation has not yet completed, or the nameserver change was not saved correctly at your registrar. First, verify that the custom nameservers are indeed saved and active in your registrar's control panel — some registrars require you to confirm changes via a second click or an email verification link. If the nameservers are correct and at least 48 hours have elapsed, contact your hosting provider to ensure your domain is properly added to your hosting account on their end, as some hosts require you to explicitly assign the domain to your account in addition to changing nameservers.
Billy Wallson is a senior operations director with over 15 years of experience scaling remote teams and implementing lean business strategies.







