Before anything: the 2-minute hPanel check
Half of all “domain not working” tickets resolve in hPanel without touching DNS. Check three things: (1) under Domains, is the domain listed as Active? (2) under Websites, is the domain attached to a hosting plan — or sitting unassigned? (3) under Security → SSL, what is the certificate status? If the domain is active, assigned, and SSL shows anything other than an error, you are almost certainly looking at propagation — skip straight to Fix 1 and save yourself an hour of settings archaeology.
Fix 1: Wait out DNS propagation (the most common “problem”)
When you register a domain or change nameservers, the update has to spread across DNS servers worldwide. This takes anywhere from a few minutes to 48 hours, with most domains resolving within 4–8 hours. During this window the site may load for you but not for a friend — or show a parking page — and nothing is wrong.
How to check: use a propagation checker (dnschecker.org is free) and enter your domain. If some locations resolve and others do not, it is propagation — wait. If nothing resolves anywhere after 48 hours, move to Fix 2.
Fix 2: Point the domain at Hostinger’s nameservers
If you bought the domain elsewhere (Namecheap, GoDaddy, Cloudflare) and host the site on Hostinger, the domain must use Hostinger’s nameservers: ns1.dns-parking.com and ns2.dns-parking.com. Change these at your domain registrar — not in hPanel — under the domain’s nameserver or DNS settings. Changing nameservers restarts the propagation clock, so expect another wait of up to 48 hours.
If you registered the domain with Hostinger itself, the nameservers are set correctly by default — skip this fix.
Fix 3: Assign the domain to your hosting plan
A surprisingly common miss: the domain is registered and the hosting is paid for, but the two were never connected. In hPanel, go to Websites → Add Website (or “Connect a domain”) and add your domain to the plan. Until a domain is attached to a hosting account, Hostinger’s servers do not know which site to serve for it.
Fix 4: Check the DNS zone records
If you kept third-party nameservers (for example, Cloudflare) instead of Hostinger’s, you manage DNS there — and the A record must point at your Hostinger server’s IP address. Find the IP in hPanel under the hosting plan details, then confirm the A record (@ and www) matches it at your DNS provider. A single wrong digit here produces a site that never loads, with no helpful error.
Fix 5: Give the free SSL time to issue
“Not working” sometimes means “works on http but shows a security warning on https.” Hostinger’s free SSL certificate issues automatically after the domain resolves to the server — usually within minutes to a few hours of propagation completing. Check SSL status in hPanel under Security → SSL. If it shows “pending” while DNS is still propagating, that is normal; it will complete on its own. Do not force-install or reinstall repeatedly — that just restarts the process.
Fix 6: Clear cache and try another network
Browsers and ISPs cache DNS aggressively. Before assuming the worst: hard-refresh (Ctrl+Shift+R), try an incognito window, and check the site on mobile data instead of Wi-Fi. If it loads on mobile data but not your home connection, your ISP’s DNS cache is stale — it will clear on its own, or you can temporarily switch to 1.1.1.1 / 8.8.8.8 to confirm.
Fix 7: Confirm the domain is active and paid
Check the domain’s status in hPanel or at your registrar: is it expired, suspended for missing WHOIS verification, or stuck in a transfer? New registrations sometimes require email verification of the registrant contact — an unverified domain can be suspended by the registry. Also confirm you did not just register it minutes ago and expect instant global resolution (see Fix 1).
Fix 8: Registrar transfer and 60-day locks
If you recently transferred the domain to Hostinger, ICANN policy locks transfers for 60 days after registration or a previous transfer — and during an active transfer the DNS can behave oddly. Check the transfer status at your old registrar. Transfers typically complete within 5 days; if yours is stuck beyond that, open a ticket with both registrars.
Fix 9: Ask Hostinger support (with the right info)
If you have waited 48 hours, verified nameservers, and confirmed the domain is assigned to hosting, it is time for support. Hostinger’s 24/7 chat is in hPanel. Give them: the domain name, where it is registered, the current nameservers, what a DNS checker shows, and when you made the last change. That information turns a 30-minute back-and-forth into a 5-minute fix.
Frequently asked questions
Up to 24–48 hours in the worst case, though most domains resolve within 4–8 hours. Global DNS caches update at different speeds, so the site appearing for some visitors but not others during this window is normal. Use dnschecker.org to watch propagation complete location by location.
ns1.dns-parking.com and ns2.dns-parking.com. Set these at your domain registrar if the domain was bought elsewhere and the site is hosted on Hostinger. Domains registered directly with Hostinger already use the correct nameservers.
A parking page usually means the domain is registered but not connected to any hosting — either DNS has not propagated yet, or the domain was never added to a hosting plan in hPanel. Check both: propagation status first, then Websites → Add Website in hPanel.
The SSL certificate has not finished issuing. Hostinger’s free SSL activates automatically once the domain resolves to your server, typically within minutes to hours after propagation. Check Security → SSL in hPanel; if it says pending, wait rather than reinstalling.
Yes — many sites do. Keep Cloudflare’s nameservers at your registrar and point the A records at your Hostinger server IP (found in hPanel). Remember that with Cloudflare nameservers, you manage DNS at Cloudflare, not in hPanel, so make record changes there.
Stale DNS cache on one device or network. Your phone on mobile data uses your carrier’s DNS (likely updated), while your laptop uses your home ISP’s cache (possibly stale). Hard-refresh, try incognito, or temporarily switch the laptop to 1.1.1.1 to confirm — then just wait for the cache to expire.
Related guides
DNS record types: which one is actually broken
The existing fixes cover the common cases. When those do not resolve it, you need to think in record types. Each type fails differently:
| Record | Symptom when broken | How to verify |
|---|---|---|
| A (@ and www) | Site does not load at all; browser shows connection error | Compare the A record value against the server IP in hPanel |
| CNAME (www) | Root domain works but www subdomain fails, or vice versa | Check that www has either a CNAME to the root or its own A record |
| MX | Website works fine but email does not arrive | MX records must point to the mail server, not the web server IP |
| TXT (SPF/DKIM/DMARC) | Email sends but lands in spam, or gets rejected | Use an online SPF/DKIM checker against your domain |
| NS | Nothing works and DNS checkers show no records at all | Confirm nameservers at the registrar match where you are editing DNS |
The classic misdiagnosis: the website works but email broke after a DNS change. That is almost always MX records that were not recreated when nameservers moved. Web hosting and email are separate DNS concerns. Fixing one can break the other if you only copy the A records.
TTL: the invisible timer controlling every change
Every DNS record has a TTL (Time To Live) that tells servers how long to cache it. This is why DNS changes are not instant, and misunderstanding TTL causes most self-inflicted DNS pain.
- Before a planned change, lower the TTL. 24-48 hours before migrating or switching nameservers, set the TTL to 300 seconds (5 minutes) on the records you will change. When you make the actual change, it propagates in minutes instead of hours. Raise the TTL back afterward to reduce DNS query load.
- After an unplanned change, you wait. If you already changed a record with a 24-hour TTL, some servers will cache the old value for the full 24 hours. There is no force-refresh for other people's DNS caches. This is why the lowering step matters.
- Different records can have different TTLs. Your A record might cache for 4 hours while your MX caches for 24. During a migration, the website might switch over quickly while email lags a day behind. Check each record's TTL individually.
Subdomain problems: the forgotten children
Subdomains (blog.yoursite.com, shop.yoursite.com, staging.yoursite.com) break independently of the main domain. Common scenarios:
- Subdomain never created. Creating a subdomain in hPanel's Websites section is separate from DNS. If the subdomain was added to hosting but has no DNS record (or vice versa), it will not resolve. Both sides must exist.
- Wildcard confusion. A wildcard DNS record (*.yoursite.com) catches all undefined subdomains, which is convenient but masks configuration errors. If you rely on a wildcard, a typo in a subdomain name will resolve to the wrong place instead of failing visibly. Prefer explicit records for production subdomains.
- SSL on subdomains. Hostinger's free SSL typically covers the main domain and www. Additional subdomains may need separate certificate issuance. If a subdomain shows a certificate warning while the main domain is fine, check SSL status for that specific subdomain in hPanel under Security.
Email-specific DNS: MX, SPF, DKIM, and DMARC
If the website works but email does not, stop touching A records. Email lives in four record types:
- MX records tell the world where to deliver your email. They must point to your mail provider's servers. When you switch email providers (say, from Hostinger's included email to Business Email or Google Workspace), the MX records must be updated. Old MX records pointing at the previous provider mean incoming mail goes to a dead inbox.
- SPF (a TXT record) declares which servers may send email as your domain. Without it, receiving servers treat your mail as suspicious. With a malformed one (multiple SPF records, syntax errors), they may reject it outright. There must be exactly one SPF record.
- DKIM (a TXT record) cryptographically signs outgoing mail. Your email provider generates the key; you publish it in DNS. If DKIM is missing, deliverability suffers. If the key does not match what the provider signs with, mail fails authentication.
- DMARC (a TXT record) tells receiving servers what to do when SPF or DKIM fail: nothing, quarantine, or reject. Start with p=none (monitoring mode) and check the reports before enforcing p=reject. Jumping straight to reject with misconfigured SPF/DKIM will silently discard legitimate mail.
After any email DNS change, send test messages to Gmail, Outlook, and Yahoo addresses and check whether they arrive in the inbox or spam. Online tools like mail-tester.com give you a deliverability score with specific failures identified. Fix the failures before assuming the problem is elsewhere.