← Blog

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:

TypeNameValue
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:

TypeNameValueNote
A@192.0.2.10Points a hostname at an IPv4 server address
AAAA@2001:db8::10Same job as A, but for IPv6 addresses
CNAMEwwwmyawesomewebsite.comMakes one hostname an alias of another
MX@mail.myawesomewebsite.comTells other servers where to deliver your email
TXT@site-verification=abc123Stores public text: verifications, SPF, DKIM, DMARC
NS@ns1.dnsprovider.examplePoints 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:

TypeNameValue
A@192.0.2.10

Now myawesomewebsite.com resolves to that server. Subdomains work the same way:

TypeNameValue
Ablog192.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:

TypeNameValue
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:

TypeNameValue
A@192.0.2.10
CNAMEwwwmyawesomewebsite.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.

TypeNameValue
CNAMEshopshops.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:

TypeNamePriorityValue
MX@10mail.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:

TypeNameValue
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:

TypeNameValue
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:

TypeNameValue
TXTselector1._domainkeyv=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:

TypeNameValue
TXT_dmarcv=DMARC1; p=none;

The policy levels:

  • p=none — just monitor results
  • p=quarantine — treat failed mail as suspicious
  • p=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:

TypeNameValue
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

RecordDoesYou use it when
AName → IPv4 addressPointing a domain at a server
AAAAName → IPv6 addressYour server supports IPv6
CNAMEName → other hostnameThird-party managed subdomains, www
MXWhere email goesSetting up domain email
TXTArbitrary textVerification + SPF/DKIM/DMARC
NSAuthoritative name serversDelegating 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:

TypeNameExample valuePurpose
A@192.0.2.10Root domain → website
CNAMEwwwmyawesomewebsite.comwww → root domain
MX@mail.myawesomewebsite.comIncoming email
TXT@Provider verification valueProve domain ownership
TXT@SPF policyAuthorized senders
TXTselector1._domainkeyProvider-supplied DKIM dataEmail signatures
TXT_dmarcv=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

  1. Using a CNAME where an A record belongs — a CNAME points to a hostname, never an IP address
  2. Publishing two SPF records — combine them into one, or SPF evaluation fails
  3. Breaking a working setup by deleting TXT records — some of them carry email authentication or verification; check before removing
  4. Expecting DNS changes to be instant — TTL caching means old values can persist for a while
  5. Copying records incompletely when moving nameservers — the new zone needs everything the old one had
  6. 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.

0%