DNS records are the rows you fill in on your domain's DNS settings page. Each row answers one question about a name, such as "what is the IP of devatlas.site?" or "where should email for this domain go?". Get the rows right and your site loads, your email arrives, and services like Vercel or Resend can verify you own the domain.

If you only remember one thing: A points a name to an IP, CNAME points a name to another name, MX handles email, TXT proves things, and TTL is how long everyone caches the answer.

DNS in one minute

Think of DNS as the phonebook of the internet. You know the name (devatlas.site), but your browser needs the number (an IP address like 76.76.21.21) before it can send a single packet.

The real mechanism is a chain of servers, and no single one knows everything:

1. Your browser and OS check their own cache first.
2. On a miss, they ask a recursive resolver (your ISP's, or 1.1.1.1, or 8.8.8.8) for the final answer.
3. The resolver asks a root server, which says "ask the .site servers".
4. The TLD server for .site says "ask this domain's name servers".
5. The authoritative name server for devatlas.site holds the actual records and returns the answer.

Diagram: Your browser asks a recursive resolver for devatlas.site. The resolver asks a root server, which points to the .site servers; the .site servers point to the domain's authoritative name server; that server answers with the A record 76.76.21.21, which the resolver hands back to the browser. You ask once. The resolver asks up to three servers (2, 3, 4) and hands you the IP. Every answer is cached for its TTL, so most lookups never leave the resolver's cache.

The DNS note covers this lookup in depth. This note is about step 5: the records themselves.

What a DNS record is

DNS record: One row in a domain's zone (its list of records) on the authoritative server. Every row has a name, a type, a value and a TTL.

Most DNS dashboards (Cloudflare, GoDaddy, Hostinger, Namecheap, Route 53) show exactly these four columns. Some add a Priority column, used by MX and SRV.

Bare domain vs subdomain

The bare domain (also called the root or apex) is devatlas.site itself, written as @. A subdomain is anything in front of it, like www.devatlas.site or api.devatlas.site. Several rules below depend on which one you are editing.

A record: name to IPv4 address

What it does: points a name straight to an IPv4 address.

When you'd use it: pointing your bare domain to a server or platform. Vercel asks for an A record on an apex domain like devatlas.site. Copy the exact IP from your project's Domains page rather than from a blog post. A VPS on DigitalOcean or AWS EC2 also gets an A record to its public IP.

A name can have several A records. Clients pick one, which spreads load in a very basic way.

AAAA record: name to IPv6 address

What it does: the same as an A record, but for an IPv6 address. It's called "quad A" because IPv6 addresses are four times longer (128 bits vs 32).

When you'd use it: when your host gives you an IPv6 address. It's optional, but it's good practice if your server supports IPv6. If you add an AAAA record, the server must actually answer on that address, or IPv6 users will hit a dead end.

CNAME record: name to another name

What it does: says "this name is an alias, go look up that other name instead". It never holds an IP.

When you'd use it: pointing a subdomain to a platform. Vercel gives each project its own CNAME target for subdomains like www or docs. Render, Netlify, GitHub Pages and Heroku work the same way. The win is that the platform can change its IPs whenever it likes, and your record keeps working because it points to their name, not their IP.

Diagram: devatlas.site has an A record that points straight to the IP 76.76.21.21. www.devatlas.site has a CNAME that points to the name xyz.vercel-dns-017.com, and that name has its own A record pointing to an IP. A record: name to IP, done. CNAME: name to another name, and the resolver keeps looking until it reaches an A or AAAA record.

The big CNAME rule

A CNAME cannot share its name with any other record. The bare domain always has NS and SOA records, so you cannot put a CNAME on @. This is the most common DNS error people hit when deploying.

Workarounds:

• Use an A record on @ with the IP the platform gives you (Vercel's approach for apex domains).
• CNAME flattening (Cloudflare): you type a CNAME on @, Cloudflare looks up the target itself and answers with plain A/AAAA records. Visitors never see a CNAME.
• ALIAS / ANAME records: the same idea under another name at providers like DNSimple and others. Route 53 calls its version an "alias" record.

Go deeper: why flattening can break verification

Because a flattened CNAME is answered as an A record, a service that checks for the CNAME itself (some domain verifications do) won't see it. Cloudflare's docs warn about this. If a verification CNAME fails on Cloudflare, make sure that record is DNS only (grey cloud), not proxied.

A CNAME can point to another CNAME, but each hop is one more lookup, so keep chains short.

MX record: where email goes

What it does: names the mail server that receives email for the domain, with a priority. Lower number = tried first.

When you'd use it: setting up Google Workspace, Zoho Mail or any inbox on your domain. Google Workspace today uses a single MX record, smtp.google.com with priority 1. Older setups have five aspmx records, and those still work.

Two rules from the RFCs: an MX value must be a hostname, not an IP, and that hostname must have its own A/AAAA record (it must not be a CNAME).

MX only controls receiving. Proving that your sent mail is legit is the job of TXT records.

TXT record: proofs and email security

What it does: stores text on a name. Machines read it to check things: that you own the domain, and which servers may send email as you.

Domain verification. A service gives you a random string, you add it, and it checks DNS. Only the domain's owner could have added it.

SPF lists which servers are allowed to send mail for your domain.

DKIM publishes a public key. Your mail provider signs each email with the matching private key, and receivers check the signature against this record.

DMARC tells receivers what to do when SPF or DKIM checks fail, and where to send reports. It always lives at _dmarc.

When you'd use it: verifying a domain for Google Search Console, Vercel (a _vercel TXT when the domain is used by another account), or Resend. When you add a sending domain in Resend (Resend recommends a subdomain, like updates.devatlas.site), its Records tab gives you a DKIM TXT record plus the SPF records (a TXT and an MX on a send subdomain by default). Copy them exactly, then add a DMARC record. Start DMARC at p=none, check the reports, then tighten to quarantine or reject.

Two SPF records

A name may have only one SPF record (v=spf1 ...). If you use Google Workspace and another sender, merge them into one line, for example v=spf1 include:_spf.google.com include:other.com ~all. Two separate SPF records make SPF fail.

NS record: who is in charge

What it does: names the authoritative name servers for the domain. These are the servers that hold all the other records.

When you'd use it: moving DNS hosting. For example, you bought the domain on GoDaddy but want Cloudflare (or Vercel DNS) to manage it, so you change the nameservers at your registrar. From then on, the records in the new host are the only ones that count.

Changing nameservers moves everything

Records at the old DNS host stop working the moment the new NS takes effect. Copy your MX, TXT and other records to the new host first, or your email breaks. Vercel's docs warn about exactly this.

SOA record: the zone's admin header

What it does: one per zone, created for you. It holds the primary name server, an admin email (written with a dot instead of @), a serial number that increases on every change, timers that secondary servers use to sync, and how long "this name doesn't exist" answers are cached.

When you'd use it: almost never by hand. Your DNS host manages it. You just need to know it exists, because it's one of the reasons a CNAME can't sit on @.

CAA record: which CA may issue HTTPS certificates

What it does: lists the certificate authorities (CAs) allowed to issue TLS certificates for your domain. With no CAA record, any public CA may issue one after validating the domain. Subdomains inherit the closest CAA record above them.

When you'd use it: as a security hardening step. Be careful: if your host uses a different CA (many platforms issue through Let's Encrypt, some use Google Trust Services or others), a CAA record that leaves it out will block certificate renewals. Check your host's docs before adding one.

SRV record: service plus port (briefly)

What it does: points a service to a host and a port, with priority and weight. The name has the form _service._protocol.

The value reads as priority 10, weight 5, port 5223, target host. When you'd use it: chat (XMPP), VoIP (SIP), some Microsoft 365 setups, and Minecraft servers on a custom port. Most web apps never need one.

TTL and "propagation"

TTL (time to live) is how many seconds resolvers and browsers may cache an answer before asking again.

"DNS propagation" is not really the change spreading out. Your DNS host updates within seconds. The delay is old cached copies around the world waiting for their TTL to run out. That's why services say "can take up to 48 or 72 hours": they're allowing for long TTLs and stubborn caches.

Planning a change

A day before you move devatlas.site to a new host, lower the TTL to 300. Wait for the old TTL to expire. Switch the record. Once everything works, raise the TTL again.

You can check what the world sees with dig:

dig devatlas.site A +short          # the IP for the bare domain
dig www.devatlas.site +short        # follows the CNAME to the IP
dig devatlas.site MX +short         # mail servers
dig _dmarc.devatlas.site TXT +short # your DMARC policy
dig @1.1.1.1 devatlas.site A        # ask a specific resolver

On Windows, nslookup -type=MX devatlas.site does the same job.

Which record do I need?

Diagram: A decision chart. Bare domain to an IP: A or AAAA. Bare domain to a platform hostname: ALIAS or a flattened CNAME. Subdomain to a platform: CNAME. Receive email: MX. Prove ownership or set up SPF, DKIM, DMARC: TXT. Limit which certificate authority can issue certificates: CAA. Move the whole DNS to another host: change NS at the registrar. Start from what you want the name to do, then pick the record.

Common mistakes

CNAME on the bare domain

@ CNAME myapp.vercel.app is not allowed, because @ already has NS and SOA records. Use the A record your platform gives you, or a flattened CNAME / ALIAS.

The name gets doubled

Most dashboards add your domain automatically. Typing www.devatlas.site in the Name field can create www.devatlas.site.devatlas.site. Type just www. Check the hint text in your provider's form.

Leaving the Cloudflare proxy on for verification records

CNAMEs that a service needs to see (Resend, some email and SSL checks) must be DNS only (grey cloud). Proxied records are answered with Cloudflare's IPs, so the check fails.

Old records fighting new ones

An old A record and a new CNAME on the same name, or an old AAAA pointing to a dead server, cause random failures. Delete what you are replacing.

Changing nameservers without copying email records

The site works on the new host, but MX and TXT records were left behind, so email silently stops.

Testing too soon, from one place

Your laptop may still have the old answer cached. Use dig @1.1.1.1 or dig @8.8.8.8, or an online checker, and remember the old TTL.

Quick self-check

Why can't you put a CNAME on devatlas.site itself?

Answer: A CNAME can't share its name with any other record, and the bare domain must have NS and SOA records. Use an A record, or a flattened CNAME / ALIAS from your DNS host.

You want docs.devatlas.site to point to a Vercel project. Which record do you add?

Answer: A CNAME on docs, pointing to the target Vercel shows you in the project's Domains settings.

Your MX record has priority 10 for server A and 20 for server B. Which one gets mail first?

Answer: Server A. Lower priority numbers are tried first, and B is the backup.

Which records protect people from spoofing email "from" your domain, and where do they live?

Answer: SPF (a TXT on @), DKIM (a TXT on selector._domainkey, such as google._domainkey) and DMARC (a TXT on _dmarc). DMARC uses the SPF and DKIM results to decide what happens to mail that fails.

You changed an A record an hour ago and some users still hit the old server. Why, and how do you avoid it next time?

Answer: Their resolvers cached the old answer and will keep it until its TTL expires. Next time, lower the TTL (say to 300 seconds) a day before the change.

> 1. A record is one row: name, type, value, TTL. A/AAAA point to IPs, CNAME points to another name.

2. No CNAME on the bare domain. Use A, or a flattened CNAME / ALIAS.
3. MX receives email. TXT proves ownership and carries SPF, DKIM and DMARC, with only one SPF record per name.
4. NS decides who hosts your DNS. Copy every record before you switch.
5. "Propagation" is just caches expiring. Lower the TTL before planned changes.