Overview
When a domain stops resolving — or never resolves after being set up — it almost always comes down to one of three things: DNS propagation hasn’t completed yet, a DNS record is wrong, or the problem is local to your machine (cached bad data). Domain propagation issues are the most common complaint we see after a site migration or domain transfer, and the fix is often simpler than people expect.
This article covers the full diagnostic process: how to check whether the problem is on your end or in DNS itself, how to correct common record errors in cPanel or your DNS zone editor, and what to do when propagation is taking longer than it should. If you’ve just pointed a new domain to a Shared Hosting account and it’s not loading, start at Step 1.
One thing worth clarifying upfront: “propagation” isn’t a single event. DNS changes ripple across thousands of resolvers worldwide at different rates. Your site might load fine on your phone’s cellular connection but still time out on your home Wi-Fi — that’s two different resolvers at different stages of catching up.
Prerequisites
- Access to the domain registrar account where the domain is registered (to check or update nameservers)
- cPanel, Plesk, or WHM access if you need to edit DNS zone records on the hosting side
- The IP address of your hosting server (find this in your Host & Tech welcome email or control panel)
- A terminal or command prompt — available on macOS, Linux, and Windows 10/11 natively
- Basic understanding that DNS changes can take up to 48 hours to propagate globally, though most changes complete within 1–4 hours
Step-by-Step Instructions
Step 1: Confirm It’s Not Just Your Machine
Before touching any DNS settings, rule out a local caching problem. Your computer and router both cache DNS lookups, and they’ll keep serving a stale answer long after DNS has actually updated.
Check what IP your domain is currently resolving to from an external perspective using one of these tools:
- whatsmydns.net — shows real-time resolution from ~20 global locations
- dnschecker.org — similar, with visual propagation map
- Google’s dig tool at
toolbox.googleapps.com/apps/dig/
If those tools show your domain resolving to the correct IP but it’s still not loading in your browser, the problem is local. Flush your DNS cache:
Windows:
ipconfig /flushdnsmacOS (Ventura/Sonoma/Sequoia — macOS 13–15):
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderLinux (systemd-resolved):
sudo systemd-resolve --flush-cachesAfter flushing, close and reopen your browser — browsers maintain their own DNS cache separately from the OS, and simply refreshing the page won’t clear it. In Chrome you can also go to chrome://net-internals/#dns and click Clear host cache.
📝 Note: If you’re on a corporate network or VPN, the DNS resolver might be controlled by your IT department and ignoring public DNS changes entirely. Test on mobile data to confirm.
Step 2: Verify Nameservers Are Set Correctly
If external DNS checkers show the domain resolving to the wrong IP — or not resolving at all — check that the nameservers at your registrar are pointing to Host & Tech’s nameservers.
Log into your domain registrar (GoDaddy, Namecheap, Google Domains, etc.) and find the nameserver settings for the domain. They should match the nameservers listed in your Host & Tech control panel. Typically these look like:
ns1.hostandtech.com
ns2.hostandtech.comIf you’re on a VPS or dedicated server with a custom hostname, your nameservers may differ — check your welcome email or open a support ticket to confirm.
⚠ Warning: Changing nameservers resets which DNS zone is authoritative for your domain. If you have existing records (MX records for email, subdomains, etc.) set up at your old nameservers, you’ll need to recreate them at the new location before switching — otherwise email and other services will break.
Step 3: Check the DNS A Record in Your Zone Editor
Even with correct nameservers, your domain won’t load if the A record in your DNS zone points to the wrong IP.
In cPanel, navigate to Domains > Zone Editor. Find the A record for your bare domain (shown as @ or your domain name) and confirm the IP matches your server’s IP address. Do the same for the www subdomain.
If you need to update it, click Edit next to the record, enter the correct IP, and click Save Record. The record should look like this in zone file format:
yourdomain.com. 14400 IN A 203.0.113.45
www.yourdomain.com. 14400 IN A 203.0.113.45📝 Note: The TTL value (14400 = 4 hours in seconds) controls how long resolvers cache this record. If you’re actively troubleshooting and need changes to propagate faster, temporarily lower it to 300 (5 minutes) before making the change, then restore it afterward.
Step 4: Test DNS Resolution Directly
Use dig or nslookup to query DNS directly and confirm what’s being served. This bypasses local caching and gives you a clean answer from the authoritative server.
# Query the authoritative nameserver directly
dig yourdomain.com A +short
# Check what nameservers are set
dig yourdomain.com NS +short
# Query a specific DNS server (e.g. Google's 8.8.8.8)
dig @8.8.8.8 yourdomain.com A +shortOn Windows without dig installed, use nslookup:
nslookup yourdomain.com 8.8.8.8The IP in the response should match your server IP. If you’re getting NXDOMAIN (non-existent domain) or no response, the zone itself may be missing or the nameservers aren’t responding correctly.
Step 5: Wait Out Propagation (If Records Are Correct)
If everything looks right — nameservers are correct, A record points to the right IP, external checkers show the update in most regions — but a handful of locations are still behind, you just need to wait. There’s nothing to fix.
I’d recommend checking propagation every 30 minutes using whatsmydns.net rather than staring at your browser. Most ISP resolvers respect TTL values and will update within 1–4 hours. Some older or misconfigured resolvers ignore TTL entirely and cache for up to 48 hours — that’s frustrating, but it’s not something you can control from your end.
Common Issues & Troubleshooting
Domain resolves correctly on external checkers but not in the browser
Cause: Browser-level or OS-level DNS cache is serving a stale record.
Fix: Flush your OS DNS cache using the commands in Step 1. Then clear the browser cache specifically at chrome://net-internals/#dns (Chrome) or restart Firefox. Testing in an incognito/private window doesn’t help here — private browsing still uses the same DNS resolver.
Domain shows “This site can’t be reached” or times out everywhere
Cause: Usually means the A record is missing, points to a non-existent IP, or the nameservers aren’t set at all.
Fix: Run dig yourdomain.com A +short — if you get no output or NXDOMAIN, the zone has no A record. Log into cPanel Zone Editor and add one. If dig yourdomain.com NS returns nothing, the nameservers at the registrar haven’t been set yet.
Domain loads but shows wrong website (someone else’s site or a parking page)
Cause: The A record points to the correct server IP, but the server isn’t configured to serve that domain name. This is common after migrations where the domain is pointed before the account is fully set up.
Fix: In cPanel, go to Domains and confirm the domain is listed and has a document root assigned. In WHM (for reseller/admin), check List Accounts and verify the domain is associated with the right account. On a VPS with Apache, check that a virtualhost block exists for the domain in your config under /etc/httpd/conf.d/ or /etc/apache2/sites-enabled/.
Propagation is stuck — it’s been 48+ hours and some regions still don’t see the update
Cause: Either a very high TTL on the old record (some registrars default to 86400 — a full 24 hours), or a downstream ISP resolver that ignores TTL values.
Fix: Confirm the current TTL on the A record with dig yourdomain.com A — the TTL is the number shown in the response. If it’s still high, lower it in your zone editor. For stubborn ISP resolvers, there’s little you can do except wait or advise affected users to switch to a public DNS resolver like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) in their network settings.
Email stopped working after pointing domain to new host
Cause: This is the gotcha that catches a lot of people. When you update nameservers, your MX records move with them — but only if you’ve recreated them in the new DNS zone. If you didn’t, your email has no routing.
Fix: In cPanel Zone Editor, check that MX records exist for your domain. If you use Google Workspace or Microsoft 365, you’ll need to manually re-add their MX records. Run dig yourdomain.com MX +short to see what’s currently published. An empty response means mail is unroutable.
FAQ
Frequently Asked Questions
How long does DNS propagation take?
Most DNS changes propagate within 1–4 hours. The full 48-hour window people often cite is a worst-case scenario based on older TTL values. If you’ve set your TTL to 300 seconds (5 minutes) before making the change, you’ll usually see global propagation in under 30 minutes.
Why does my domain work on mobile data but not on my home Wi-Fi?
Your home router uses a DNS resolver assigned by your ISP, and that resolver may still have the old record cached. Your mobile connection uses a different resolver (your carrier’s) that’s already updated. Flushing your router’s DNS cache — usually done by restarting it — or switching to a public DNS like 1.1.1.1 will resolve this.
Do I need to update nameservers or just the A record?
It depends on where your DNS is managed. If your domain’s nameservers already point to Host & Tech, you only need to update the A record in cPanel’s Zone Editor. If they point elsewhere (like your old host or registrar), you’ll need to update the nameservers at your registrar — or update the A record at whoever currently hosts your DNS zone.
Why is my domain showing a cPanel default page instead of my website?
DNS is resolving correctly — the problem is on the server side. Either the domain isn’t added to your cPanel account, or it’s pointing to the wrong document root. In cPanel go to Domains and confirm the domain is listed with the correct folder path. If you just migrated, the files may also not have been transferred yet.
Will setting a lower TTL make propagation faster?
Yes, but only if you set it before making the change. TTL tells resolvers how long to cache the current record. If you lower it to 300 seconds and then wait for that to propagate, subsequent changes will spread much faster. Lowering it after the fact only affects caching of the new record going forward.