What DNS Records Actually Do

When you buy a domain, the registrar gives you a name. But the name does nothing until you tell the global DNS system where it points. DNS records are those instructions: send web traffic here, deliver email there, verify ownership through this string. Get them right and your site loads, your email lands in the inbox, and third-party services authenticate. Get them wrong and people see a parked page or your messages disappear into spam.

The A Record β€” Where Your Website Lives

An A record maps a domain name to an IPv4 address. When someone types example.com into a browser, the browser asks DNS where example.com lives, and the A record returns something like 192.0.2.10. The browser then connects to that server.

  • If you change hosts, you must update the A record before traffic reaches the new server.
  • AAAA records are the IPv6 equivalent. Optional, but adding one helps users on IPv6-only networks.

CNAME β€” Alias One Name to Another

A CNAME (Canonical Name) record points a name to another name. You might point www.example.com to example.com, or shop.example.com to shopify.com.

The strict rule: you cannot have a CNAME at the apex (the bare example.com). Most providers offer ALIAS or ANAME records as a workaround.

MX β€” Where Your Email Goes

MX (Mail Exchange) records tell mail servers where to deliver email for your domain. Each MX has a priority number β€” lower means higher priority. If your top server is unreachable, mail servers try the next one.

  • Google Workspace: 1 smtp.google.com.
  • Microsoft 365: 0 yourdomain-com.mail.protection.outlook.com.
  • Hostinger: 5 mx1.hostinger.com., 10 mx2.hostinger.com.

If you do not send email from your domain, you should still add an SPF TXT record saying nothing is authorized to send. This blocks attackers from spoofing your domain.

TXT β€” Verification, SPF, DKIM, DMARC

TXT records hold arbitrary text. DNS does not interpret them, but other systems do. The four most important uses:

  • Domain verification for Google, Apple, Stripe, Slack and similar services.
  • SPF: "v=spf1 include:_spf.google.com ~all" β€” lists who is authorized to send mail as you.
  • DKIM: a public key the receiving server uses to verify a cryptographic signature on outgoing mail.
  • DMARC: "v=DMARC1; p=quarantine; rua=mailto:[email protected]" β€” tells receivers what to do with mail that fails SPF or DKIM.

SPF, DKIM, and DMARC together are what gets your email out of spam folders. Skip them and deliverability suffers, even with a perfectly configured sending service.

Propagation and TTL

Each record has a TTL (time to live) β€” how long resolvers cache the answer before re-asking. A typical TTL is one hour. After you change a record, expect some users to see the new value immediately and others to see the old one for up to a TTL.

If you know you will change a record soon, lower the TTL to five minutes a day or two in advance. The change will then propagate within minutes when you make it.

The Practical Checklist

  1. A record (and AAAA if your host supports IPv6) pointing to your web host.
  2. MX records pointing to your email provider's specified values.
  3. SPF as a TXT record at the apex.
  4. DKIM TXT records (your email provider gives you the values).
  5. DMARC TXT record at _dmarc.yourdomain.com, starting with p=none for monitoring, then upgrading to quarantine.
  6. Verification TXT records for any third-party services that need them.

That is the foundation. Everything else is service-specific.