Your website loads, your email arrives, and your domain verifies with Google, all because of a handful of lines in a DNS zone. When one of those lines is wrong, the symptoms look unrelated: a site that works on www but not without it, invoices that bounce, a certificate that won't issue. This guide walks through the seven record types you will touch most often, shows what each one looks like in a real zone, and points out the mistakes that cause most outages.
Key takeaways
- An A record points a name at an IPv4 address, while a CNAME points a name at another name that the resolver then looks up.
- You cannot put a true CNAME on your root domain, but CNAME flattening, ALIAS or ANAME records give the same effect.
- Publish only one SPF record per name, because more than one record starting with v=spf1 causes a permanent error.
- Remove old MX records and untested AAAA records after a migration, as leftovers can bounce mail or cause timeouts.
How to read a DNS record
Every DNS record has the same basic shape, whatever dashboard you use:
; name TTL class type value
example.com. 3600 IN A 203.0.113.10
- Name is the hostname the record answers for. In most dashboards,
@means the bare domain (the "apex" or "root"), andwwwmeanswww.example.com. - TTL (time to live) is how many seconds resolvers may cache the answer. See our guide to DNS propagation for why this matters when you make changes.
- Class is almost always
IN(internet). Most dashboards hide it. - Type tells resolvers how to interpret the value.
- Value (also called data, content or target) depends on the type.
Note the trailing dot on example.com. in zone files. It means "this is a fully qualified name." Many web dashboards add it for you; in raw zone files, forgetting it causes the zone's name to be appended, giving you mail.example.com.example.com.
A record: name to IPv4 address
An A record maps a hostname to an IPv4 address. It's the record that actually sends visitors to your web server.
example.com. 3600 IN A 203.0.113.10
www.example.com. 3600 IN A 203.0.113.10
You can publish more than one A record for the same name. Resolvers return all of them, and clients typically pick one, which gives you crude load distribution. That only helps if every listed IP actually serves your site, so remove old server IPs after a migration.
AAAA record: name to IPv6 address
AAAA ("quad A") does the same job for IPv6 addresses:
example.com. 3600 IN AAAA 2001:db8::10
A common failure: a host or CDN publishes a AAAA record by default, but the server behind it doesn't listen on IPv6, or the firewall blocks it. Visitors on IPv6-capable networks then get timeouts while everyone else is fine. If you publish AAAA, test the site over IPv6. If you can't support IPv6 yet, delete the AAAA record rather than leaving a broken one.
CNAME record: an alias for another name
A CNAME says "this name is an alias; go look up that other name instead."
www.example.com. 3600 IN CNAME example.com.
shop.example.com. 3600 IN CNAME shops.myshopify.com.
CNAMEs are useful when a third party (a store platform, a help desk, a landing page builder) controls the IP addresses and may change them. You point to their hostname, and they handle the rest.
Two rules from RFC 2181 trip people up constantly:
- A CNAME can't coexist with other records at the same name. If
shop.example.comhas a CNAME, it can't also have a TXT or MX record. This is why you can't put a CNAME on your bare domain: the apex must hold NS and SOA records, so a CNAME there breaks the rule. - MX and NS records must not point to a CNAME. Their targets must be names with A/AAAA records.
To use an alias-style record on the apex, many providers offer a workaround: Cloudflare calls it CNAME flattening, others call it ALIAS or ANAME. The provider resolves the target itself and answers with plain A/AAAA records, so the standard is respected.
MX record: where your email goes
MX records tell other mail servers which hosts accept email for your domain. Each has a priority number; lower numbers are tried first.
example.com. 3600 IN MX 10 mx1.mailprovider.example.
example.com. 3600 IN MX 20 mx2.mailprovider.example.
What to check:
- Use exactly the hostnames your email provider gives you. Google Workspace, Microsoft 365 and others publish their current MX values in their setup docs, and they do change over time.
- Remove old MX records after switching providers. Leftover records with a lower priority number will keep receiving mail, or bouncing it.
- MX targets must be hostnames, not IP addresses, and not CNAMEs.
MX only handles inbound mail. Whether your outbound mail lands in the inbox depends on SPF, DKIM and DMARC, which live in TXT records. Our email authentication checklist covers those.
TXT record: verification and email policy
TXT records hold free-form text, and they've become the general-purpose place for domain-level settings:
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. 3600 IN TXT "google-site-verification=abc123..."
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
Common uses:
| Purpose | Name | Starts with |
|---|---|---|
| SPF (who may send your mail) | @ |
v=spf1 |
| DMARC policy | _dmarc |
v=DMARC1 |
| DKIM public key | selector._domainkey |
v=DKIM1 |
| Ownership verification | @ or a given label |
Vendor-specific token |
Rules worth knowing:
- Only one SPF record per name. RFC 7208 says that if a receiver finds more than one record starting with
v=spf1, the result is a permanent error. If you add a new sender, merge it into the existing record instead of creating a second one. See what an SPF record is for the syntax. - Each quoted string is limited to 255 characters. Long values such as 2048-bit DKIM keys are split into several quoted strings inside one record, and receivers join them without spaces. Most dashboards do the splitting for you.
- Multiple TXT records at the same name are fine for different purposes (SPF plus several verification tokens).
NS record: who is authoritative
NS records list the nameservers that hold the authoritative copy of your zone.
example.com. 86400 IN NS ns1.dnsprovider.example.
example.com. 86400 IN NS ns2.dnsprovider.example.
There are two places NS records matter:
- At your registrar (the delegation in the parent zone, such as
.com). This is what actually decides which provider answers for your domain. Changing nameservers at the registrar moves your whole DNS to a new provider. - Inside the zone itself. These should match the delegation. A mismatch is a classic sign of a half-finished migration.
You can also delegate a subdomain to a different provider by adding NS records for it, for example dev.example.com NS ns1.otherprovider.example.
SOA record: zone metadata
Every zone has exactly one SOA (start of authority) record at the apex. Your DNS provider usually creates and manages it.
example.com. 3600 IN SOA ns1.dnsprovider.example. hostmaster.example.com. (
2026101201 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
300 ) ; minimum (negative-caching TTL)
The fields, per RFC 1035:
- MNAME (
ns1.dnsprovider.example.): the primary nameserver. - RNAME (
hostmaster.example.com.): the responsible person's email, with the@written as a dot. - Serial: the zone version. Secondary servers only pull updates when it increases. A
YYYYMMDDnnformat is a common convention. - Refresh / Retry / Expire: how often secondaries check for updates, how soon they retry after failure, and when they stop answering if they can't reach the primary.
- Minimum: today this is used as the TTL for negative answers ("this name doesn't exist"), per RFC 2308. If it is set to a day, a record you just created may stay invisible to resolvers that looked it up beforehand for up to that long.
If you run your own nameservers with secondaries, a serial that isn't incremented is the most common reason "my change isn't showing up."
Putting it together: a typical small-business zone
example.com. 3600 IN A 203.0.113.10
www.example.com. 3600 IN CNAME example.com.
example.com. 3600 IN MX 1 smtp.google.com.
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
The CAA line restricts which certificate authorities may issue certificates for the domain; our CAA records guide explains it.
How to check your records
From a terminal, dig (macOS/Linux) or nslookup (Windows) query records directly:
dig example.com A +short
dig example.com MX +short
dig _dmarc.example.com TXT +short
dig example.com NS +short
To check against a specific resolver, add @1.1.1.1 or @8.8.8.8. To see what the authoritative server says (bypassing caches), query one of your NS hosts directly: dig example.com A @ns1.dnsprovider.example.
If you would rather see everything at once, run a free audit. The DNS section lists your A, AAAA, NS, MX, TXT, SOA and CAA records, checks DNSSEC, and the email section validates SPF, DKIM and DMARC alongside them.
Frequently asked questions
What is the difference between an A record and a CNAME?
An A record points a name directly at an IPv4 address. A CNAME points a name at another name, and the resolver then looks that name up. Use a CNAME when a third party controls the IP addresses; use A/AAAA on the apex unless your provider supports flattening.
Can I have a CNAME on my root domain?
Not as a true CNAME, because the root must hold NS and SOA records and a CNAME can't share a name with other records. Providers that offer CNAME flattening, ALIAS or ANAME records give you the same effect by answering with A/AAAA records.
Why do I have several TXT records at the root?
Different services use TXT records for different jobs: SPF, ownership verification for Google, Microsoft or other tools, and so on. That's normal. The one thing you must not have is two separate records starting with v=spf1.
What TTL should I use?
For records that rarely change, 3600 seconds (one hour) or more is a sensible default. Lower it to around 300 seconds a day or two before a planned change, then raise it again afterwards.
What to do next
Pull up your zone and compare it with the examples above. Look for leftover A records from old hosts, stale MX records from a previous email provider, duplicate SPF records and a AAAA record nobody tested. Then run a free audit to confirm the DNS, email and certificate checks all pass together.
Sources
Written by the MakeItFlow team
We build the website audit these guides are based on. Every fact is checked against the primary sources listed above and this guide was last reviewed on 21 October 2026 . How we research and check
Check your own site in 30 seconds
Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.
