Pointing a domain to Hostinger looks simple in the abstract, but the right path depends on where the domain is registered, whether you use third-party email, and whether you sit behind Cloudflare. The wrong method can take email offline for two days, cache the old site for a week, or rebuild a Cloudflare config you spent hours tuning. This walkthrough covers both DNS paths, which one fits which scenario, registrar-specific steps, and the propagation tricks that cut waiting time.
Two Methods, Two Use Cases
Hostinger supports two DNS paths. Pick before you start because mixing them halfway through creates inconsistent state.
- Nameserver change: Move all DNS authority to Hostinger. Hostinger manages every record (A, MX, TXT, CNAME). Simplest, best for sites where Hostinger is also handling email or there is no email at all.
- A record change: Keep DNS at your existing provider (Cloudflare, registrar's free DNS, AWS Route 53). Only update the A record (and CNAME for www) to point at Hostinger's IP. Surgical, best for sites with complex existing DNS, third-party email like Google Workspace, or Cloudflare proxying.
If you are migrating an existing site, the broader Hostinger setup and migration guide covers when each path makes sense, including the DNS sequencing that protects email continuity.
Before You Change Anything: The Pre-Flight Checklist
Four steps prevent the most common DNS outages.
Lower Your DNS TTL Early
Set your DNS TTL to 300 seconds (5 minutes) at your current DNS provider at least 24 hours before the change. This means propagation finishes in minutes after the cut-over instead of hours. Skip this step and you may wait the full 24 to 48 hours for the old records to expire from resolvers around the world.
Document Every Current DNS Record
Write down every record in your current zone: A, AAAA, MX, TXT, CNAME, SRV. Screenshot the registrar's DNS page or export the zone file if your registrar supports it. If you change nameservers, you will need these values to recreate the zone on Hostinger. Missing one MX or SPF record is the most common cause of post-migration email outages.
Confirm Your Hostinger Site Loads on the Preview URL
Hostinger gives you a yourdomain.hostingersite.com URL the moment your account is live. Open it before you touch DNS. If anything is broken there (blank page, PHP error, wrong content), fix it before you cut over. Debugging a broken site while DNS is mid-propagation is significantly harder than fixing it on the preview URL first.
Plan the Cut-Over for Low-Traffic Hours
Late evening in your primary visitor time zone is the standard choice. Avoid Mondays, holiday periods, and ecommerce sales windows. Even a clean DNS change causes a brief window where some visitors hit the old server and some hit the new one. Low-traffic hours keep that window from affecting many users.
DNSSEC: Disable It Before Changing Nameservers
This is the most-missed step in nearly every guide about pointing a domain to a new host. If your domain has DNSSEC enabled at the registrar and you change nameservers without removing DNSSEC first, visitors get SERVFAIL errors for 24 to 48 hours. The domain resolves to nothing for everyone, not just a slow propagation.
Here is why: DNSSEC uses DS (Delegation Signer) records stored at the parent zone (your registrar) that cryptographically chain down to your nameservers. When you switch nameservers, the old DS records no longer match the new nameservers' keys. Every resolver that validates DNSSEC treats the mismatch as a security failure and refuses to return any answer.
Follow these steps in order:
- Check if DNSSEC is enabled at your registrar. Look for a DNSSEC or DS Records section in your domain management panel. If you see DS records listed, DNSSEC is active. If the section is empty or shows "disabled," you can skip the rest of these steps.
- Delete the DS records at the registrar before changing nameservers. Do not change nameservers at the same time. Delete DS records first, then wait.
- Wait up to one hour for old DS records to expire from cache. DS records have their own TTL. After deletion, cached copies persist in resolvers until that TTL runs out. One hour is usually enough; 24 hours is a safe upper bound.
- Then change your nameservers. Only after DS records have expired from cache is it safe to cut over nameservers without causing SERVFAIL errors.
- Only re-enable DNSSEC after Hostinger's nameservers have fully propagated. That means waiting 24 or more hours after the nameserver change before configuring DNSSEC again. Hostinger will give you the new DS record values to enter at your registrar once their nameservers are serving your zone.
If you are using the A-record-only method (Method 2) and keeping your current nameservers, DNSSEC does not need to change at all. This issue only affects nameserver changes.
Method 1: Change Nameservers (Recommended for Most)
Step 1: Find Your Hostinger Nameservers
In hPanel, look at the home dashboard or go to Hosting > Plan Details. The Nameservers card shows the exact values for your account. Typical Hostinger nameservers are ns1.dns-parking.com and ns2.dns-parking.com, but some accounts use different prefixes. Always copy the values from your own hPanel rather than typing the ones in a generic tutorial.
Step 2: Change Nameservers at Your Domain Registrar
Log in to wherever you registered the domain (Cloudflare, Namecheap, GoDaddy, Google Domains, Porkbun, Hostinger itself if you registered through them). Find the nameserver settings, which usually live under Domain > Manage > Nameservers, then change from "default" or "registrar's nameservers" to "custom nameservers" and paste the two Hostinger values.
Registrar-specific notes that catch people:
- Cloudflare: If your domain is registered at Cloudflare, you cannot change nameservers away from Cloudflare. Use Method 2 (A record) instead, or transfer the domain to a different registrar first.
- GoDaddy: Use My Products > Domains > DNS > Nameservers > Change > Enter my own nameservers. The "Use my own nameservers" toggle is what activates custom values.
- Namecheap: Dashboard > Manage > Nameservers > Custom DNS. Save changes before leaving the page or they revert.
- Google Domains: Google Domains shut down and migrated to Squarespace Domains. The flow is similar but the UI is rebranded.
- Porkbun: Domain Management > pencil icon next to Authoritative Nameservers > paste values.
Step 3: Wait for Propagation
Most nameserver changes propagate globally in 4 to 24 hours. With the TTL pre-lowered to 300 seconds, you usually see changes within 30 to 60 minutes. Use dnschecker.org to confirm globally; type your domain, select NS, and watch for ns1.dns-parking.com appearing across all regions.
Once propagation completes, hPanel's domain status changes from "Pending" to "Active" and your site loads at the real domain.
Method 2: Change A Record Only
Use this when you want to keep DNS at Cloudflare, Route 53, or your registrar's DNS, or when you have complex email rules you do not want to recreate. Only the web traffic moves to Hostinger; email, subdomains, and other records keep working unchanged.
Step 1: Find Your Hostinger Site IP
In hPanel, go to Hosting > Plan Details. The Site IP Address field shows the IPv4 you need (looks like 145.14.157.42). Copy it. If your plan supports IPv6, also copy the AAAA value for full dual-stack coverage.
Step 2: Update the A Record at Your DNS Provider
Open the DNS management area at your current DNS provider. Find the A record where the Name or Host field is @ (your root domain). Change the Value or "Points to" field from the old IP to the Hostinger IP you just copied. Set TTL to 300 seconds for fast propagation, or "Automatic" if your provider supports it.
Do not forget the www CNAME. Find the CNAME record where Name is www, and confirm it points to your root domain (@). If you instead want www to be a separate A record, set the same Hostinger IP. Modern best practice is to use a CNAME for www that follows the apex A record.
Step 3: Update AAAA if You Have IPv6
If your old setup had an AAAA record for IPv6, either delete it (browsers fall back to IPv4 automatically) or update it to Hostinger's IPv6 value from hPanel. A stale AAAA record pointing at the old host is one of the most-missed reasons a "DNS change did not work" symptom shows up; the browser uses IPv6 first and finds the old site.
CAA Records and SSL Provisioning
CAA (Certification Authority Authorization) records tell SSL certificate authorities whether they are allowed to issue a certificate for your domain. Most domains do not have CAA records, in which case any CA can issue, and Hostinger's SSL provisioning via Let's Encrypt works automatically. But if your domain does have CAA records set from a previous host, you may find that SSL fails to provision after pointing the domain to Hostinger.
Here is what to check:
Go to dnschecker.org and look up your domain's CAA records. A CAA record that permits Let's Encrypt looks like this:
0 issue "letsencrypt.org"
If you see a CAA record that names only a different CA (for example, 0 issue "sectigo.com" or 0 issue "digicert.com"), Let's Encrypt cannot issue a certificate for your domain, and Hostinger's SSL will fail silently. The fix:
- Delete the restrictive CAA record at your DNS provider. You can either remove all CAA records (which allows any CA to issue, the default behavior) or add a new CAA record that includes
letsencrypt.org. - Wait for the CAA record deletion to propagate. CAA records follow the same TTL rules as other DNS records. With a 300-second TTL, this takes about 5 to 10 minutes.
- Trigger SSL issuance in hPanel. Go to SSL > Manage > Install. Let's Encrypt certificates typically issue within 2 to 5 minutes once the CAA check passes.
If you previously had an EV or OV certificate from a paid CA (Sectigo, DigiCert, Comodo), that certificate will not transfer to Hostinger. You will need either a free Let's Encrypt certificate (issued by Hostinger automatically) or to purchase a new paid certificate and install it manually via hPanel's custom SSL option.
Cloudflare in the Middle
If your domain runs through Cloudflare (registered at Cloudflare, or pointing through Cloudflare's free CDN proxy), the path is slightly different. You have three options.
- Keep Cloudflare, point A record at Hostinger IP: In Cloudflare DNS, update the A record for @ to Hostinger's IP. Keep the proxy status on the orange cloud (Proxied) if you want Cloudflare's CDN and DDoS protection. Confirm Cloudflare's SSL/TLS mode is set to "Full" (not "Flexible") so HTTPS works end-to-end without redirect loops.
- Remove Cloudflare proxy, keep DNS: Set the A record cloud to grey (DNS only). Hostinger sees real visitor IPs and handles SSL itself. You lose Cloudflare's CDN but get a simpler configuration.
- Move DNS to Hostinger fully: Only possible if your domain is registered somewhere other than Cloudflare. Change nameservers at the registrar to Hostinger's, then recreate Cloudflare's CDN by adding the domain as a partial CNAME setup. Usually not worth the complexity.
If you are protecting WordPress through Cloudflare's WAF or Bot Fight Mode, keep them on after the cut-over. They work the same whether the origin is the old host or Hostinger.
Keeping Email Working During the Cut-Over
Email lives in MX records and the supporting SPF, DKIM, and DMARC TXT records. If you change nameservers without recreating these on Hostinger, email stops for 24 to 48 hours.
Before changing nameservers, copy these from your existing DNS provider:
- MX records: typically several records pointing at your email provider's servers (e.g. ASPMX.L.GOOGLE.COM for Google Workspace).
- SPF record: a TXT record starting with "v=spf1" that lists allowed senders.
- DKIM record: a TXT record at a specific selector (e.g. google._domainkey for Google Workspace).
- DMARC record: a TXT record at _dmarc.yourdomain.com.
Add all of these to Hostinger's DNS zone in hPanel under Domains > DNS Manager BEFORE you change nameservers at your registrar. Propagation then carries them through with everything else and email never goes dark.
If you are using the A-record-only path (Method 2), email is unaffected because you are not touching MX records at all.
Verify the Change Worked
Run these checks 30 minutes to 2 hours after the change.
- dnschecker.org for your domain (A record): should show the Hostinger IP across most regions. A few regions may lag a few hours.
- Open your domain in an incognito browser window: should load the Hostinger site, not the old one. If it still loads the old site, your local DNS or browser cache is stale; try a different network (mobile data).
- nslookup yourdomain.com in a terminal: should return the Hostinger IP. On Windows use Command Prompt, on Mac and Linux use Terminal.
- mxtoolbox.com domain lookup: confirms A, MX, NS, SPF, and DMARC records all match what you set. Catches stale records before users notice.
- Send a test email from your domain to a Gmail address and check the headers for SPF=pass and DKIM=pass. Catches email configuration drift.
Common DNS Errors and Fixes
Domain Still Shows the Old Site After 24 Hours
Either the nameserver change did not save at the registrar, the TTL was not lowered in advance, or a browser cache is showing the old site. Re-check the registrar panel to confirm the nameservers are saved correctly. If they are, wait another 12 hours. If the site loads correctly on mobile data but not on your home network, it is a local DNS cache issue. Flush your DNS cache or restart your router.
"This Site Cannot Be Reached" Error
The A record is wrong or the AAAA record still points at the old host. Re-check both. A stale AAAA is the overlooked cause about half the time: the browser tries IPv6 first, hits the old server, and fails if that server no longer has your files. Delete any AAAA records that point to an old IP and re-test.
"Connection Is Not Private" SSL Warning
Hostinger SSL is not yet provisioned for the domain. In hPanel, go to SSL and click Install or Force HTTPS. SSL issuance typically takes 2 to 5 minutes once triggered. If it fails, check whether CAA records at your DNS provider are blocking Let's Encrypt (see the CAA Records section above).
Email Stopped Working
MX records were lost during the nameserver change. This means they were not copied to Hostinger's DNS zone before the switch. Re-add them under hPanel > DNS > Manage. Also re-add SPF, DKIM, and DMARC records. Wait one propagation cycle (30 to 60 minutes with a 300-second TTL) and test by sending a message to a Gmail address, then checking the headers.
Cloudflare Error 522 (Connection Timed Out)
Cloudflare's SSL/TLS mode is set to Flexible when it needs to be Full. Switch in Cloudflare > SSL/TLS > Overview. "Flexible" sends HTTP from Cloudflare to Hostinger; "Full" sends HTTPS. Hostinger's server redirects HTTP to HTTPS, causing a loop that results in a 522. Set it to Full and the loop breaks immediately.
www Subdomain Shows Old Site but Root Domain Shows New
The CNAME for www was never updated. It still points at the old host's subdomain or IP. Set the www CNAME to point at @ (your root domain) or set a separate A record to the Hostinger IP directly. Either approach works; the CNAME approach is cleaner because it automatically follows changes to the root A record.
Pointing Subdomains to Hostinger
Subdomains follow the same logic. In Hostinger, add the subdomain under Domains > Subdomains in hPanel so the server is ready to serve it. Then either let nameservers handle it automatically (Method 1) or add a CNAME at your DNS provider pointing the subdomain at the root domain or directly at the Hostinger IP via A record (Method 2).
One subtlety: if the subdomain has its own service (mail.yourdomain.com pointing at Google Workspace, blog.yourdomain.com pointing at Medium), do not change it. Only add the subdomains that need to live on Hostinger.
After Your Domain Resolves to Hostinger
Once your domain loads the Hostinger site, walk through the post-cut-over checklist: confirm forms submit and emails arrive, confirm checkout works, confirm Search Console still receives data, and keep the old host running for at least 7 days as a fallback. The broader Hostinger setup and migration guide covers the broader post-migration verification list, and the how to set up Hostinger walkthrough covers the LiteSpeed and security settings that turn a freshly pointed domain into a tuned production site. Once those settings are in place, the how to enable Hostinger CDN on WordPress guide covers the CDN toggle and the cache collision fix that catches most people.
