dns · 2026-10-27 · 7 min
DNS Records Explained (Without the Jargon)
A practical guide to the DNS records most domains actually need — A, CNAME, MX, TXT, SPF, DKIM, DMARC — with real examples and the mistakes to avoid.
You type example.com into your browser. A moment later, the right website loads.
That happens because of DNS — the Domain Name System, the internet's phonebook. You remember names; computers find each other with IP addresses. DNS records are the instructions in that phonebook that make the connection happen.
This guide covers the DNS records most domains actually use, what each one does, and the mistakes to avoid — in plain English.
What Is a DNS Record?
A DNS record is a single instruction attached to your domain. It mostly contains four things:
- Type — what kind of instruction it is (A, CNAME, MX…)
- Name — which domain or subdomain it applies to
- Value — the IP, hostname, or text it points to
- TTL — how long resolvers may cache it before re-checking
For example:
| Type | Name | Value |
|---|---|---|
| A | @ | 192.0.2.10 |
Here @ means the root domain in a DNS dashboard. One instruction, one job — nothing happens on its own.
The Records You'll Actually Use
Six instructions cover almost every real-world domain. Here they are at a glance:
| Type | Name | Value | Note |
|---|---|---|---|
| A | @ | 192.0.2.10 | Points a hostname at an IPv4 server address |
| AAAA | @ | 2001:db8::10 | Same job as A, but for IPv6 addresses |
| CNAME | www | myawesomewebsite.com | Makes one hostname an alias of another |
| MX | @ | mail.myawesomewebsite.com | Tells other servers where to deliver your email |
| TXT | @ | site-verification=abc123 | Stores public text: verifications, SPF, DKIM, DMARC |
| NS | @ | ns1.dnsprovider.example | Points to the servers managing your DNS zone |
That's the whole working set for most domains — here's where each one earns its place.
A Record — Point Your Domain to a Server
The A record connects a hostname to an IPv4 address.
If your site is hosted on a server at 192.0.2.10, you configure:
| Type | Name | Value |
|---|---|---|
| A | @ | 192.0.2.10 |
Now myawesomewebsite.com resolves to that server. Subdomains work the same way:
| Type | Name | Value |
|---|---|---|
| A | blog | 192.0.2.20 |
That makes blog.myawesomewebsite.com point to a different server.
Use an A record when your hosting provider gives you an IP address.
AAAA Record — The IPv6 Version of the A Record
The AAAA record is identical in purpose, but for IPv6 addresses:
| Type | Name | Value |
|---|---|---|
| AAAA | @ | 2001:db8::10 |
Easy to remember: A = IPv4, AAAA = IPv6. You only need it if your server supports IPv6.
CNAME Record — Point a Hostname at Another Hostname
The CNAME (Canonical Name) record makes one hostname an alias of another:
| Type | Name | Value |
|---|---|---|
| A | @ | 192.0.2.10 |
| CNAME | www | myawesomewebsite.com |
Visiting www.myawesomewebsite.com follows the CNAME to the root domain and resolves its address.
The everyday pattern you'll actually hit: a third-party service tells you to point a subdomain at them.
| Type | Name | Value |
|---|---|---|
| CNAME | shop | shops.provider.example |
Now shop.myawesomewebsite.com follows whatever the provider manages.
The key difference: an A record points to an IP address; a CNAME points to another hostname. And a CNAME can't sit at the root domain — some DNS providers offer "CNAME flattening" for that case.
MX Record — Tell Email Where to Go
When someone emails hello@myawesomewebsite.com, the sending server checks your domain's MX (Mail Exchange) records to find where to deliver it:
| Type | Name | Priority | Value |
|---|---|---|---|
| MX | @ | 10 | mail.myawesomewebsite.com |
Lower priority = preferred (10 beats 20), which is how backup mail servers work. The hostname in the MX record must itself resolve through an A or AAAA record.
Use an MX record whenever you set up email for your domain — Google Workspace, Microsoft 365, or another provider will give you the exact values.
TXT Record — A Public Note Attached to Your Domain
The TXT record stores arbitrary text in DNS. Simple, but it carries a lot of modern infrastructure:
| Type | Name | Value |
|---|---|---|
| TXT | @ | site-verification=abc123 |
That's the classic pattern: a service gives you a verification string, you publish it, the service confirms you control the domain's DNS.
Two things worth knowing:
- The contents aren't secret — never put passwords or credentials in a TXT record
- TXT is also where SPF, DKIM, and DMARC live (next section)
Email Security: SPF, DKIM, and DMARC
These three are published as TXT records, and they answer one question: can this email be trusted as coming from your domain?
SPF — Who May Send Email for Your Domain?
SPF (Sender Policy Framework) lists the servers authorized to send email using your domain:
| Type | Name | Value |
|---|---|---|
| TXT | @ | v=spf1 ip4:192.0.2.10 -all |
If a spammer sends fake mail "from" your domain, receiving servers check this policy and see the sending server isn't on it.
One rule to burn in: a domain should have only one SPF record. Multiple SPF policies for the same hostname cause SPF evaluation errors — combine all legitimate senders into a single record.
DKIM — A Tamper-Evident Signature
DKIM (DomainKeys Identified Mail) signs outgoing email with a digital signature that receiving servers verify against a public key in DNS — like a tamper-evident seal on a package:
| Type | Name | Value |
|---|---|---|
| TXT | selector1._domainkey | v=DKIM1; k=rsa; p=EXAMPLEPUBLICKEY |
Your email provider generates this. (Some providers publish it via CNAME instead of TXT — that's normal.)
DMARC — What to Do When Checks Fail
DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving servers how to handle mail that fails SPF/DKIM checks:
| Type | Name | Value |
|---|---|---|
| TXT | _dmarc | v=DMARC1; p=none; |
The policy levels:
p=none— just monitor resultsp=quarantine— treat failed mail as suspiciousp=reject— refuse failed mail
The mental model in one line: SPF says who may send for you, DKIM says the message wasn't altered, DMARC says what to do when either fails.
NS Record — Who Holds Your DNS?
The NS (Name Server) record identifies which servers are authoritative for your domain — the ones holding the official instructions:
| Type | Name | Value |
|---|---|---|
| NS | @ | ns1.dnsprovider.example |
| NS | @ | ns2.dnsprovider.example |
You'll touch this when you buy a domain at one company but manage DNS at another — setting the nameservers delegates everything to the provider.
Be careful here: the new provider must have your records copied first, or your website and email break.
Quick Reference
| Record | Does | You use it when |
|---|---|---|
| A | Name → IPv4 address | Pointing a domain at a server |
| AAAA | Name → IPv6 address | Your server supports IPv6 |
| CNAME | Name → other hostname | Third-party managed subdomains, www |
| MX | Where email goes | Setting up domain email |
| TXT | Arbitrary text | Verification + SPF/DKIM/DMARC |
| NS | Authoritative name servers | Delegating DNS to a provider |
(In the background, your DNS provider also maintains records like SOA, PTR, CAA, and the DNSSEC family. They manage most of these automatically — you rarely touch them by hand.)
A Real-World Example
You just bought myawesomewebsite.com for a business site with professional email. The configuration that makes it work:
| Type | Name | Example value | Purpose |
|---|---|---|---|
| A | @ | 192.0.2.10 | Root domain → website |
| CNAME | www | myawesomewebsite.com | www → root domain |
| MX | @ | mail.myawesomewebsite.com | Incoming email |
| TXT | @ | Provider verification value | Prove domain ownership |
| TXT | @ | SPF policy | Authorized senders |
| TXT | selector1._domainkey | Provider-supplied DKIM data | Email signatures |
| TXT | _dmarc | v=DMARC1; p=none; | Monitor authentications |
Note the shape of it: you don't add every record that exists. You add exactly the records your services need.
Common Mistakes to Avoid
- Using a CNAME where an A record belongs — a CNAME points to a hostname, never an IP address
- Publishing two SPF records — combine them into one, or SPF evaluation fails
- Breaking a working setup by deleting TXT records — some of them carry email authentication or verification; check before removing
- Expecting DNS changes to be instant — TTL caching means old values can persist for a while
- Copying records incompletely when moving nameservers — the new zone needs everything the old one had
- Assuming DNS makes your site secure — records route traffic; HTTPS still needs a TLS certificate
Final Thoughts
DNS looks intimidating until you see that every record has one job. A and AAAA point at servers, CNAME creates aliases, MX routes email, TXT carries verification and email-security policy, NS delegates authority.
You don't memorize the whole list — you add the records your provider asks for, and you check before touching anything unfamiliar.
That's it. DNS stops being a dark art and becomes what it actually is: a small set of instructions that tells the internet where each of your services lives.