DNS Records Explained: A, AAAA, CNAME, MX, TXT and NS

Open your domain's DNS settings for the first time and you're greeted by a wall of cryptic entries: A, AAAA, CNAME, MX, TXT, NS. It looks like alphabet soup, but each of these record types does one specific job — and once you understand the six common ones, you can point a domain at a website, set up email, and verify ownership of services without fear.

This guide explains each record in plain English, with real examples, when you'd actually use it, and the mistakes beginners make most often.

The 30-Second Version: What DNS Records Actually Are

DNS records are instructions stored on authoritative DNS servers — the servers responsible for answering questions about your domain. When someone types your domain into a browser, their computer asks: "where is this?" The DNS records answer: "here's the server's address," "send mail over there," "this text proves ownership," and so on.

The classic analogy is a phone book: domain names are the people's names, IP addresses are the phone numbers, and DNS records are the entries connecting them. The analogy breaks down a little because DNS does more than name-to-number mapping (email routing, verification, security policies), but it's a fine starting point.

All of your domain's records live together in what's called a DNS zone — essentially one configuration file (or one screen in your DNS provider's dashboard) for your domain. You edit records there whenever you connect your domain to a new website, email provider, or service.

Every record also carries a TTL (time-to-live), measured in seconds. It tells other servers how long they're allowed to cache that record before checking for a fresh copy. Short TTL (300 seconds / 5 minutes) means changes spread fast; long TTL (86400 seconds / 24 hours) means changes take longer to take effect everywhere.

A Record — Points Your Domain to a Server (IPv4)

The A record (Address record) is the most fundamental DNS record: it maps a hostname directly to an IPv4 address — the familiar four-number address like 192.0.2.1.

Example: `` example.com. A 192.0.2.1 www.example.com. A 192.0.2.1 ``

This says: "when someone asks for example.com or www.example.com, send them to the server at 192.0.2.1."

When you need one: almost always. If your website lives on a server with a fixed IP address — a VPS, a dedicated server, most shared hosting — you'll create an A record for your domain (the "apex" or "root," written as @ in most dashboards) and usually one for www too. Your hosting provider tells you which IP to use; you paste it into the A record's value field.

AAAA Record — The Same Thing, for IPv6

The AAAA record ("quad-A") does exactly what an A record does, but for IPv6 addresses — the longer format like 2001:db8::1. The internet is gradually moving from IPv4 to IPv6, and many hosts now provide both.

Example: `` example.com. AAAA 2001:db8::1 ``

Do you need one? If your host gives you an IPv6 address, add the AAAA record alongside your A record — it costs nothing and makes your site reachable to visitors on IPv6-only networks. If your host only provides IPv4, skip it; nothing breaks. Having an A record without AAAA is completely normal and fine.

CNAME Record — An Alias to Another Name

A CNAME (Canonical Name) record doesn't point to an IP address at all — it points one hostname at another hostname. It's an alias: "whatever that name resolves to, I resolve to as well."

Example: `` www.example.com. CNAME example.com. blog.example.com. CNAME mysite.hostingplatform.com. ``

The first line makes www.example.com follow example.com wherever it goes. The second points a subdomain at a third-party service (a blog platform, a store builder, a CDN) without you needing to know — or track — that service's IP address.

When to use CNAME instead of A: when the target's IP might change without warning. Third-party platforms (website builders, email marketing tools, CDNs) routinely move servers around; a CNAME follows them automatically, while a hardcoded A record would go stale and break. Rule of thumb: your own server with a fixed IP → A record; someone else's service → CNAME.

The big rule — CNAME exclusivity: a hostname with a CNAME record cannot have any other record type at the same name. This is an old, strict DNS rule (RFC 1034), and every DNS provider enforces it. So you can't have both a CNAME and an MX record for mail.example.com — pick one. And critically: you cannot put a CNAME at the root/apex of your domain (example.com itself), because the apex must also hold NS and SOA records. (Some providers offer "CNAME flattening" or ANAME/ALIAS records as a workaround — but a plain CNAME at the apex is invalid DNS.) This is the single most common CNAME mistake beginners make.

MX Record — Routes Your Email

MX (Mail Exchange) records tell the internet where to deliver email addressed to your domain. Without them, nobody can email you at you@yourdomain.com.

Example: `` example.com. MX 10 mail.example.com. example.com. MX 20 mail2.example.com. ``

Two things to notice. First, the value is a hostname, not an IP address — mail.example.com, which itself needs an A record pointing at the mail server. Second, each MX record has a priority number (sometimes called "preference"). Lower number = tried first. Above, mail goes to mail.example.com (priority 10); if that server is down, senders fall back to mail2.example.com (priority 20). That's your email failover.

The classic mistake: pointing an MX record at a CNAME. The DNS standards say MX targets must resolve via A/AAAA records, not via CNAME aliases. Many providers will warn you; some mail simply won't arrive if you get this wrong. Always point MX at a hostname that has a direct A record.

Setting up Google Workspace, Microsoft 365, or any business email? The provider gives you the exact MX values to enter — copy them verbatim, including the priority numbers.

TXT Record — Free-Form Text with Real Jobs

A TXT record stores arbitrary text against a hostname. "Arbitrary" undersells it — TXT records do some of the most important jobs in DNS:

• SPF (v=spf1 ...): declares which servers may send email for your domain — fights spoofing
• DKIM: stores a public key receivers use to verify your mail wasn't tampered with
• DMARC (v=DMARC1; ...): tells receivers what to do with mail that fails SPF/DKIM
• Domain verification: Google, Microsoft, and others ask you to add a TXT record containing a random string to prove you own the domain

Example: `` example.com. TXT "v=spf1 include:_spf.google.com ~all" ``

Unlike most record types, one hostname can (and often should) have multiple TXT records — your SPF record, your DKIM key, and a verification string can all live side by side. Just don't create two SPF records for the same domain; that's invalid and breaks SPF evaluation. One SPF TXT per domain, always.

NS Record — Delegates Your DNS

NS (Nameserver) records declare which servers are authoritative for your domain's DNS — i.e., where the world should go to ask about your records.

Example (at your registrar): `` example.com. NS ns1.dnsprovider.com. example.com. NS ns2.dnsprovider.com. ``

Don't confuse the two places NS records appear:

1. At your registrar (where you bought the domain): these NS records delegate your entire domain to a DNS provider. Change these when you move your DNS hosting — e.g., pointing your domain at Cloudflare's or your host's nameservers. This is the "change nameservers" step every migration guide mentions.
2. Inside your DNS zone: NS records here delegate subdomains to different nameservers — an advanced setup most beginners never touch.

For most people, the only NS records that matter are the ones at the registrar. Set them once to your DNS provider's nameservers and leave them alone.

Quick-Reference Table: All Six at a Glance

Common Beginner Mistakes (and How to Avoid Them)

CNAME at the root/apex

As covered above: example.com (the apex) cannot have a CNAME, because the apex must also carry NS and SOA records, and CNAME forbids company. If your dashboard lets you try, look for an ANAME/ALIAS option instead — or just use an A record.

Forgetting (or mis-adding) the trailing dot

In raw zone-file syntax, mail.example.com. with a trailing dot means "exactly this fully-qualified name." Without the dot, some systems append your domain again, producing mail.example.com.example.com. Most modern dashboards handle this for you (they add the dot silently or use a relative-name field), so this mainly bites when editing raw zone files or following old tutorials. If a record mysteriously doesn't work, double-check for a doubled domain.

Deleting records you don't recognise

That odd TXT record with a long random string? Probably a domain-verification token for a service you connected months ago — deleting it can break that integration. The _dmarc TXT? That's your email security policy. Before deleting anything unfamiliar, look up what it's for; when in doubt, leave it.

Expecting instant changes

DNS changes are not instant. Every record's TTL controls how long the old value lingers in caches worldwide — anywhere from minutes to 48 hours. If you just changed a record and nothing happened: wait, then check with a propagation tool (search "DNS propagation checker") rather than assuming you did it wrong. Pro tip: before a planned change, lower the TTL to 300 seconds a day ahead; change the record; then raise the TTL back.

Frequently Asked Questions

What's the difference between an A record and a CNAME?

An A record points a hostname directly at an IP address (example.com → 192.0.2.1). A CNAME points a hostname at another hostname (www.example.com → example.com). Use A for servers you control with fixed IPs; use CNAME for aliases and third-party services whose IPs may change. And remember: a CNAME can't share its hostname with any other record type.

Do I need both A and AAAA records?

Only if your host provides an IPv6 address. An A record alone works fine — most of the web still runs on IPv4. But if your host hands you both, add both; it costs nothing and future-proofs your site for IPv6-only visitors.

Why isn't my website working after I changed DNS records?

The most common cause is propagation delay — the old record is still cached somewhere, governed by its TTL. Wait it out (up to 24–48 hours for long TTLs), clear your local DNS cache, and verify with an online propagation checker before assuming the record itself is wrong. The second most common cause is a typo in the record value — re-read what you entered.

Can I have email on a subdomain, like mail.example.com?

Yes. MX records work at any level: add MX records for mail.example.com (or whatever subdomain) pointing at your mail provider's servers, exactly as you would for the root domain. Just remember the MX target itself must have an A record, not a CNAME.

How many TXT records can I have?

As many as you need — TXT records happily coexist. The one hard rule: only one SPF record per domain (multiple SPF TXT records invalidate SPF). DKIM, DMARC, and verification strings each get their own TXT record without conflict.

What's the difference between nameservers at my registrar and NS records in my DNS zone?

Same record type, different jobs. The NS records at your registrar delegate your whole domain to a DNS provider ("ask these servers about example.com"). NS records inside your zone delegate individual subdomains elsewhere — an advanced setup. Beginners only ever touch the registrar-level ones, typically once, when first connecting DNS hosting.

Just registered a domain and need to point it somewhere? Start with our domain registration guide for the full setup walkthrough — then come back here when you're ready to create your first A record. And if your site still won't load after DNS changes, the usual culprit is propagation: give it time, check with a propagation tool, and double-check for typos before changing anything else.