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

DNS records are the entries in your domain's zone that tell the internet where things live. An A record points a name to an IPv4 address, AAAA to an IPv6 address, CNAME makes one name an alias of another, MX says which servers receive your email, TXT holds text used for email authentication and ownership checks, and NS says which servers are in charge of the zone. A normal business domain needs fewer than fifteen records, but one wrong entry can take down the website or silently send email to spam.

Below, each record type comes with a real example, then TTL, the records a typical site needs, common mistakes, and how to audit your zone. Replace example.com in all examples with your domain.

How to read a DNS record

Every record has the same five parts:

example.com.   3600   IN   A   203.0.113.10
name           TTL    class type value

• Name: the host the record applies to. @ in most panels means the domain itself (the "apex" or root).

• TTL: how many seconds resolvers may cache the answer.

• Class: almost always IN (internet). Panels usually hide it.

• Type and value: what kind of record it is and its data.

The trailing dot in example.com. means "this is a complete name". In some zone editors, leaving it off makes the panel append your domain, so mail.example.com becomes mail.example.com.example.com. If your panel shows the domain next to the name field, type only the part before it, like mail.

The record types, one by one

A record: name to IPv4 address

example.com.       3600  IN  A  203.0.113.10
shop.example.com.  3600  IN  A  203.0.113.20

This is the record that sends visitors to your web server. You can have several A records for the same name; resolvers then rotate between them, which is a basic form of load spreading but not failover.

AAAA record: name to IPv6 address

example.com.  3600  IN  AAAA  2001:db8::10

Same job as A, for IPv6. Publish it only if the server really answers on that IPv6 address with the same site and a valid certificate. A stale AAAA record is a classic cause of "the site works for me but not for my customer", because many mobile networks prefer IPv6.

CNAME record: an alias for another name

www.example.com.   3600  IN  CNAME  example.com.
help.example.com.  3600  IN  CNAME  helpdesk.example.net.

A CNAME says "look up that other name instead". It is handy for www and for pointing a subdomain at an outside service. Two rules matter:

• A CNAME cannot share its name with any other record. That is why you cannot put a CNAME on the bare domain, which always has NS and SOA records. Some DNS providers offer an ALIAS, ANAME or "CNAME flattening" feature that behaves like a CNAME at the apex and returns A records instead.

• MX and NS records must not point to a CNAME. Point them to a name that has its own A or AAAA record.

MX record: where your email is delivered

example.com.  3600  IN  MX  10 mail.example.com.
example.com.  3600  IN  MX  20 backup-mx.example.com.

The number is the priority: lower means preferred. Sending servers try 10 first, then 20. The target must be a hostname with an A or AAAA record, never an IP address. If the domain should never receive mail at all, the standard "null MX" is 0 ..

TXT record: text for verification and email security

TXT records hold free text, but in practice they carry a few well-known formats:

; SPF: which servers may send mail for the domain
example.com.  3600  IN  TXT  "v=spf1 a mx include:_spf.mailprovider.example ~all"

; DKIM: public key used to check message signatures
default._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

; DMARC: what receivers should do when SPF/DKIM fail
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

; Google Search Console ownership check
example.com.  3600  IN  TXT  "google-site-verification=abc123..."

A domain can have many TXT records, but only one may start with v=spf1. SPF also has a limit of 10 DNS lookups (each include, a and mx counts), so adding every marketing tool's include eventually breaks it. The DKIM selector (default above, which is what cPanel uses) is chosen by whoever signs your mail. Our deep dive on SPF, DKIM, DMARC and email authentication covers policies and rollout order.

NS record: who is in charge of the zone

example.com.  86400  IN  NS  ns1.dns-provider.example.
example.com.  86400  IN  NS  ns2.dns-provider.example.

NS records exist in two places: at the registry (set through your registrar) and inside your zone. They should match. Changing the nameservers at the registrar moves control of every record to the new provider, which is why records must be recreated there first. Our guide to connecting a domain to hosting explains when to change nameservers and when to edit records instead.

Other records worth knowing

• SOA: created automatically. It holds the zone's serial number and timers, including how long "record not found" answers are cached.

• CAA: lists which certificate authorities may issue SSL for your domain, for example example.com. CAA 0 issue "letsencrypt.org". If you add CAA, include the authority your host uses for free SSL, or renewals will fail.

• SRV: points a service (some calling, chat and email-autodiscovery systems) to a host and port.

• PTR (reverse DNS): maps an IP back to a name. It is set by whoever owns the IP, usually your hosting provider, not in your zone. Mail servers on a VPS need a matching PTR to be trusted.

TTL: how long answers are cached

• 3600 (one hour): a sensible default for most records.

• 300 (five minutes): set this a day before a planned change, then raise it again afterwards.

• 86400 (one day): fine for records that almost never change, like NS.

A detail that confuses people: "not found" is cached too. If you look up new.example.com before creating it, your resolver may remember the negative answer for the SOA's negative-cache time even after you add the record. Wait it out, or test against a different public resolver.

The records a typical business domain needs

For the website:

• A record for @ pointing to the web server.

• CNAME (or A) for www.

• AAAA only if IPv6 is configured on the server.

For email:

• MX records from your email provider.

• One SPF TXT record listing every service that sends as your domain.

• A DKIM TXT (or CNAME) record per sending service.

• A DMARC TXT record at _dmarc, starting with p=none to collect reports.

• An A record for the mail host if the MX points to mail.example.com.

For verification: a TXT record for Google Search Console and any other service that asks you to prove ownership. Some services use a CNAME instead.

If you run email on your domain, IM HOST email hosting gives you the exact MX, SPF and DKIM values to add, and our guide to professional email on your own domain helps you decide where your mailboxes should live.

Mistakes we see most often

• CNAME on the root domain. Either rejected by the panel or, worse, accepted and breaking email. Use A records for @.

• Two SPF records. Usually after adding a new mailing tool. Receivers treat this as an SPF error. Merge into one record.

• MX pointing to an IP or a CNAME. Some senders tolerate it, many do not.

• Missing trailing dot in a raw zone file, producing names like mail.example.com.example.com.

• Forgotten AAAA pointing to an old server after a move.

• Wildcard records (*) that make every typo subdomain resolve, hiding mistakes.

• Dangling CNAMEs to services you cancelled. If someone else can claim that external name, they can serve content on your subdomain. Delete records for services you no longer use.

• Jumping to DMARC p=reject before checking reports, which blocks legitimate mail from tools you forgot.

How to audit your DNS zone

Start by exporting or copying the full zone from your DNS panel. Then query what the world actually sees. Do not rely on dig ANY; most servers now return minimal answers to it. Query each type instead:

for t in A AAAA CNAME MX TXT NS CAA; do
  echo "== $t"
  dig +short "$t" example.com
done

dig +short CNAME www.example.com
dig +short TXT _dmarc.example.com
dig +short TXT default._domainkey.example.com

# Show TTLs as well
dig +noall +answer example.com A

On Ubuntu or Debian, dig comes with the dnsutils package. Then go through the list:

1. For every record, write down what it is for and who owns that service. Anything nobody can explain is a candidate for removal, after checking.

2. Confirm A and AAAA records point to servers you still use.

3. Check there is exactly one SPF record and that it includes every real sender.

4. Check DKIM exists for each sending service and DMARC exists at _dmarc.

5. Look for CNAMEs to external services you have cancelled.

6. Repeat the audit after every hosting or email change, and at least once a year.

Frequently asked questions

What is the difference between an A record and a CNAME?

An A record maps a name directly to an IP address. A CNAME maps a name to another name, which then has its own A record. Use A for the root domain and CNAME for aliases like www.

How many MX records should I have?

Whatever your email provider specifies, often one to five. What matters is that each points to a valid hostname and that the priorities match the provider's instructions.

Can I have more than one TXT record?

Yes, as many as you need. The exception is SPF: only one TXT record per name may start with v=spf1.

How long do DNS changes take?

For a record edit, up to the old TTL, often an hour or less. Nameserver changes can take up to 24 to 48 hours because of caching at the TLD level.

Every domain registered with IM HOST includes free DNS management, so you can add and edit all the records above from one place. If something in your zone looks wrong, our engineers can review it with you 24/7.