A DNS record is a single line in your domain’s zone file that answers one question: where does this name go, who handles its mail, or is this domain verified. Hostinger exposes those lines in the DNS records tab of the DNS page in hPanel, where each row has a type, a name, a value and a TTL. The default TTL is 14400 seconds, and a saved change can take up to 24 hours to reach every resolver. This page is the reference: what each record family does, which fields it needs, and the specific mistake that breaks it most often.
Which record do I actually need?
Start from the job, not from the record type. Nearly every support question about DNS is someone adding the wrong type for a legitimate goal.
| What you want | Record | Where the value comes from |
|---|---|---|
| Send the domain to your server’s IPv4 address | A | Your hosting plan |
| Same, over IPv6 | AAAA | Your hosting plan |
Make www follow the bare domain |
CNAME | Your own domain, @ |
| Point a hostname at a service that may change its IPs | CNAME | The service’s target hostname |
| Receive email for the domain | MX | Your mail provider |
| Prove you own the domain to a third party | TXT | The service asking for proof |
| Say which servers may send mail as you | TXT (SPF) | The list of senders you use |
| Cryptographically sign outbound mail | TXT (DKIM) | Your mail provider’s key |
| Publish a policy for mail that fails checks | TXT (DMARC) | Your own policy decision |
| Advertise a service on a specific port | SRV | The service’s documentation |
| Restrict which authorities may issue certificates | CAA | Your certificate authority |
| Hand a whole domain to a DNS provider | NS | That provider |
If the answer is NS for one hostname rather than the whole domain, stop: Hostinger domains do not allow custom NS records for subdomains, only for the main domain. Use an A, CNAME or TXT record there instead. Delegation to another DNS provider is a separate job, covered in the nameserver guide.
Before you start editing: look over the Hostinger hosting plans — Premium is $1.99/mo on a 48-month term ($95.52 up front, renews at $10.99/mo), and every hosting plan carries a 30-day money-back guarantee.
A and AAAA: the records that send traffic
An A record maps a hostname to an IPv4 address. An AAAA record does the same for IPv6. They decide which machine a browser connects to, so they are the first thing to check when a site does not load.
Fields: type, name (@ for the bare domain, or a subdomain label), value (the address), TTL. No priority.
The mistake: putting a hostname in the value. An A record takes an address, not a URL and not a domain name. Pasting https://example.com or the server’s hostname into the value field is the single most common rejection in this tab. Strip the protocol, strip the trailing slash, and use the numeric address only.
A quieter mistake: editing the root A record to test something. That row serves your live site to everyone. Create a subdomain and point that instead.
CNAME and ALIAS: pointing at a name instead of an address
A CNAME says “this hostname is an alias of that hostname”. The resolver then looks up the target and follows it. The benefit is that when the target’s address changes, your record keeps working because you never hard-coded the address.
Fields: type, name, value (a hostname, with no protocol and no path), TTL.
The mistake: a CNAME at the root. The DNS standard does not allow a CNAME where other records must also exist, and the root of a domain always has other records, mail being the obvious one. Hostinger handles this with ALIAS, which behaves like a CNAME at the root but is resolved by the nameserver rather than handed to the client. If a provider tells you to point the bare domain at them with a CNAME and the editor refuses, ALIAS is the record you want.
A CNAME also cannot coexist with an A record on the same name. Two answers to one question means behaviour depends on which one a resolver picks up first.
MX: where email lands
MX records tell the world which servers accept mail for the domain. Each one carries a priority number, and the lowest number is tried first. Multiple MX rows with different priorities give you a fallback list.
Fields: type, name (usually @), value (the mail server hostname, never an IP address), priority, TTL.
The mistake: mixing providers. If Google’s MX rows are still present while you add a new provider’s rows, mail will be delivered to whichever set has the better priority, and half your mail goes to an inbox nobody is reading. Remove the old rows in the same edit, and remember that a change can take up to 24 hours to settle, so a short window of split delivery is expected.
A second MX mistake: a target with no A record of its own. Mail servers resolve the MX target, so the target must resolve.
TXT: verification, SPF, DKIM and DMARC
TXT records carry arbitrary text, which is why every service that needs to prove something to DNS uses them. Four jobs account for nearly all TXT rows on a normal domain.
Verification. A service gives you a string and a hostname to put it on. Copy both exactly. Truncated values and values with a stray space are rejected silently by the service that issued them.
SPF lists the servers allowed to send mail as your domain. It is a TXT record at the root beginning with v=spf1. The mistake here is having two SPF records. Two records is not a merge, it is a permanent error, and receivers treat the domain as having no valid policy at all. Merge the includes into one row.
DKIM is a public key published as a TXT record on a selector hostname the provider gives you. It is not a separate record type, which is why people hunt for a “DKIM” option that does not exist. Paste the key exactly as issued; line breaks and missing characters both invalidate it.
DMARC is a TXT record on _dmarc that tells receivers what to do with mail that fails SPF and DKIM, and where to send reports. It only works if SPF or DKIM is already aligned, so it belongs after those two, not before.
SRV and CAA: the two most people never touch
SRV publishes a service’s host and port so clients can discover it without being told. Chat, voice and some mail and directory services use it. It takes a priority, a weight, a port and a target hostname, all four from the service’s own documentation. The mistake is inventing the values, or entering the port in the value field alone when the record needs it as its own field.
CAA restricts which certificate authorities may issue for the domain. Each row names an authority and a flag that says whether the row is an authorization or a refusal. The mistake is adding a CAA record before checking which authority your host actually uses: a CAA row that omits the issuer your certificate comes from blocks renewal, and the failure appears weeks later when the certificate expires.
Every type at a glance
The short version, without the explanation:
| Type | Fields | Typical failure |
|---|---|---|
| A | Name, address, TTL | A hostname or URL pasted into the value field |
| AAAA | Name, IPv6 address, TTL | Added when the server has no IPv6 address |
| CNAME | Name, target hostname, TTL | Placed at the root, or beside an A record of the same name |
| ALIAS | Name, target hostname, TTL | Used where a plain CNAME was already legal |
| MX | Name, mail hostname, priority, TTL | An address instead of a hostname, or two providers mixed |
| TXT | Name, text, TTL | A second SPF row, or a DKIM key with a character missing |
| SRV | Name, priority, weight, port, target | Values invented instead of copied from the service docs |
| CAA | Name, flags, authority | Leaves out the authority that actually issues the certificate |
| NS | Name, nameserver hostname | Attempted on a subdomain, which Hostinger does not allow |
TTL, and why the default is usually right
TTL is the field on every record that people change without a reason. It defaults to 14400 seconds on Hostinger. It tells resolvers how long they may keep the answer cached.
A short TTL makes changes travel faster and costs more lookups; a long one does the opposite. For a record you set once and forget, leave the default. For a record you are about to change as part of a migration, a lower value set before the change shortens the window in which some visitors see the old answer, but remember that the wait is documented as up to 24 hours regardless of what you set, because the old cached copy has to expire first.
Records you did not create are the other case. If a zone already has rows from a previous host or a previous owner, read them before deleting. A TXT row that looks like noise may be the only thing keeping a service verified, and an MX row you do not recognise may be someone’s mail. The hPanel DNS editor walkthrough covers the restore and export tools, which are the safe way to back the zone up before removing anything, and Hostinger documents every field in its knowledge base at support.hostinger.com.
One zone, one place to manage it: compare Hostinger’s plans before you buy — hosting that includes a free domain for the first year puts the zone in the same dashboard you already log into, with no second provider to chase.
Frequently asked questions
What is the difference between a CNAME and an A record?
An A record stores an address, so it is fixed until you edit it. A CNAME stores another hostname, so it follows whatever that hostname resolves to. Use an A record for your own server, and a CNAME when a third party may change its addresses without telling you.
Can I have two SPF records?
No. Two SPF records on the same domain is a permanent error and receivers will treat the domain as unpublished, so every message is judged on reputation alone. Merge the mechanisms into a single v=spf1 row and delete the extra one in the same edit, then check that only one row beginning with v=spf1 remains.
Why is my MX record pointing at a hostname and not an IP?
Because mail servers resolve the MX target themselves, which lets the provider move its mail infrastructure without asking every customer to update a record. An MX value that is a bare IP address is invalid, and so is a target hostname that has no A record behind it. Copy the hostname your mail provider publishes.
Do I need an AAAA record?
Only if your server has an IPv6 address and you want IPv6 clients to reach it directly. A domain with only an A record still works for everyone, because clients fall back to IPv4. Adding a wrong AAAA record is worse than having none.
Why does my new record not show up anywhere?
Because it has not propagated yet. Hostinger documents the wait as up to 24 hours. The row is live in the zone the moment you save it; what lags is every resolver holding an older cached answer. Test from more than one location before editing again.
Most DNS problems are one wrong field rather than a broken system: an address in a hostname field, a second SPF row, a CNAME at the root. Read the row you are about to change, change only that row, and give it a day. If a record needs a value you cannot find, ask the service that asked for the record, not the hosting provider.