How to point your domain to Hostinger (DNS records explained simply)

You bought a domain, you have a server, and the two have no idea the other exists. DNS is what connects them, and it confuses people mostly because every panel shows it differently. Here is how I pointed ahmed-adil.com, www and the blog subdomain to a Hostinger VPS, and what each record does.

Two ways to connect: nameservers or records

Before you touch any record, decide where your DNS lives. There are two common setups.

Option 1: Change the nameservers. At your registrar, you replace the default nameservers with the ones your host gives you. From then on, you manage every record inside the host's panel. If your domain and hosting are both at Hostinger, this is often already done for you.

Option 2: Keep DNS at the registrar and add records. You leave the nameservers alone and add an A record pointing to your server's IP. This is useful when the domain has other services attached that you don't want to move.

Both work. The rule that matters: records only count where the nameservers point. If your nameservers point to Hostinger, editing records at your old registrar does nothing. Most "my DNS change isn't working" problems come from editing the wrong place.

To see where your DNS lives right now:

dig NS example.com +short

Whatever comes back is where you should be editing.

The four records you will actually use

DNS has many record types. For a normal website with email, you need four.

A record. Maps a name to an IPv4 address. "example.com lives at 203.0.113.10." This is the core of pointing a domain to a server. (AAAA is the same thing for IPv6.)

CNAME record. Maps a name to another name. "www.example.com is the same as example.com." Useful because if the IP changes, you update one A record and the CNAME follows. One limitation: you cannot put a CNAME on the root domain itself.

MX record. Tells the world which servers receive email for your domain. Without correct MX records, mail to name@example.com goes nowhere.

TXT record. Free text that other systems read. In practice, it is mostly for email authentication (SPF, DKIM, DMARC) and for proving you own the domain to services like Google Search Console.

In a DNS editor, the name field is usually relative to your domain. @ means the root (example.com), www means www.example.com, and blog means blog.example.com.

Pointing the root domain, www and blog to a VPS

This is what my setup looks like, with a placeholder IP. The site, www and the blog all run on the same VPS, with Nginx deciding which app answers which name.

Type	Name	Value	TTL
A	@	203.0.113.10	3600
CNAME	www	example.com	3600
A	blog	203.0.113.10	3600

A few practical notes:

• Delete conflicting records. If there is already an A record for @ pointing somewhere else, such as a parking page or old hosting, remove it. Two A records for the same name means visitors randomly land on either.
• www can be a CNAME or an A record. Both are fine. I prefer the CNAME so there is only one IP to update later.
• A subdomain is just another name. blog gets its own A record to the same IP. If the blog lived on another server, you would simply use that server's IP instead.
• Don't touch the mail records while doing this. Pointing your website to a VPS does not require changing MX or TXT records. If your email runs on Hostinger, keep the MX and TXT values exactly as hPanel shows them. On my domain, the email settings page in hPanel showed SPF, DKIM and DMARC as set up, and I left those alone. More on that in A professional email on your own domain, set up right.

Always copy MX, SPF and DKIM values from your provider's panel rather than from a blog post. They differ between services and sometimes change.

Propagation: why it is not instant

After saving a record, it doesn't appear everywhere at once. DNS resolvers around the world cache answers, and each record carries a TTL (time to live, in seconds) that tells resolvers how long they may keep the old answer.

So the wait depends mostly on:

• The previous TTL. If the old record had a long TTL, resolvers can keep serving the old IP until it expires.
• Nameserver changes. Switching nameservers usually takes longer than editing a record, because the change goes through the domain's registry. Registrars often quote "up to 48 hours" to be safe. In practice it is often faster, but plan for the worst case.
• Your own machine and network. Your browser, operating system and router cache DNS too.

A useful trick when moving a live site: lower the TTL to something like 300 a day before the move. Make the change, confirm everything works, then raise it again.

Checking your work with dig and online tools

Don't trust the browser to tell you whether DNS works. Ask DNS directly.

# Root domain
dig example.com A +short

# www (shows the CNAME, then the IP it resolves to)
dig www.example.com +short

# Subdomain
dig blog.example.com A +short

# Mail and TXT records
dig example.com MX +short
dig example.com TXT +short

To bypass your local cache, query a public resolver directly:

dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

To see the TTL that is still counting down, drop +short and read the ANSWER section. On Windows, nslookup example.com 1.1.1.1 does a similar job.

For a global view, sites like dnschecker.org or whatsmydns.net query resolvers in many countries and show which ones see the new value. When most of them show your server's IP, you are close.

After DNS: HTTPS and the server side

DNS only gets visitors to your server's door. The server still needs to answer for each name. On my VPS, Nginx has a server_name for each host, and HTTPS came from Certbot once DNS resolved correctly:

sudo certbot --nginx -d example.com -d www.example.com -d blog.example.com

Run this after dig shows the right IP for all three names. Certbot has to reach your server through those names to verify them, so it fails if DNS still points elsewhere. Renewal is automatic after that. You can test it with:

sudo certbot renew --dry-run

If you are still deciding whether you need a VPS at all, read Shared hosting or VPS: what your website actually needs. For how the whole setup has held up for me, see Hostinger from real use: VPS, business email and hPanel. If you are ready to set one up, you can start with Hostinger. Check current plan prices and renewal terms yourself, since first-term prices are usually lower than renewals.

FAQ

Should I use an A record or a CNAME for www?

Either works. A CNAME pointing to the root domain means you only update one IP if the server changes. The root domain itself must use an A record.

I changed the record but the site still shows the old page. Why?

Usually caching. Check with dig @1.1.1.1 example.com +short. If that shows the new IP, the problem is your local cache or browser. If it shows the old one, wait for the old TTL to expire, or confirm you edited records where the nameservers actually point.

Will pointing my domain to a VPS break my email?

Not if you only change A and CNAME records for the website. Email depends on MX and TXT records, so leave those as your email provider specifies.

Do I need a separate SSL certificate for the subdomain?

You can include it in the same Certbot command, as shown above, so one certificate covers the root, www and blog.

---

Setting up a domain, server or email and want a second pair of eyes? Talk to the editor at ahmed-adil.com.