Almost every website outage that isn't the server's fault traces back to a handful of small text entries most owners never look at: DNS records. They are the instructions that tell the internet where your domain's traffic and email should go, and a single wrong character in one of them can take a site offline or silently stop mail from arriving. The good news is that there are only a few record types that matter day to day, and once you can read them, DNS stops feeling like dark magic.
The takeaway up front: DNS records are the entries in your domain's "address book" that map your domain to the servers running your website, email, and other services — and knowing what the common types do is the difference between confidently making a change and breaking your site by accident. This guide walks through each record type you'll actually meet, explains TTL and propagation, and ends with the handful of mistakes responsible for most DNS outages.
What a DNS record actually is
When someone types your domain into a browser, their computer has no idea where "yourdomain.com" physically lives. It asks the Domain Name System — the internet's distributed address book — which answers with the numeric address of the right server. The individual answers live in your domain's zone, a collection of DNS records hosted by whichever provider controls your domain's nameservers (often your registrar or your web host).
Every record shares the same basic shape: a name (which part of the domain it applies to), a type (what kind of instruction it is), a value (where it points), and a TTL (how long the answer may be cached). Read in plain language, a record says: "for this name, of this type, the answer is this value, and you may remember it for this long." That's the entire model. The rest is just knowing which type does what.
The records that point your traffic
A few record types handle the core job of getting visitors to your website.
- A record — maps a name to an IPv4 address (for example,
93.184.216.34). This is the workhorse: your root domain's A record is what sends browsers to your web server. If your site is down and the server is fine, a wrong or missing A record is the first suspect. - AAAA record — the same idea for IPv6 addresses (the longer, colon-separated kind). Modern hosts often provide both; an AAAA record lets IPv6-capable visitors reach you directly. It's a complement to the A record, not a replacement.
- CNAME record — points one name at another name rather than an IP address. A common use is aliasing
www.yourdomain.comtoyourdomain.com, so both resolve to the same place and you only maintain the address in one spot. The important rule: a CNAME can't coexist with other records on the same name, which is why you generally can't put a CNAME on your root domain.
The practical distinction people trip over is A versus CNAME. Use an A record when you have an IP address to point at; use a CNAME when you want a name to follow wherever another name goes — handy when a provider might change the underlying IP without telling you. Point a subdomain at a hosted service (a store, a help desk, a status page) and you'll almost always be given a CNAME target to use.
The records that route your email
Email uses a completely separate set of records from your website. This is why a site can load perfectly while mail quietly fails — the two are wired independently.
- MX record — the "mail exchanger" tells the world which server accepts email for your domain. Each MX record has a priority number; lower numbers are tried first, with higher ones acting as backups. If you use a hosted email provider, they supply the exact MX values to enter, and getting them wrong means inbound mail bounces.
- TXT record — holds arbitrary text, and modern email authentication lives here. SPF (which servers may send mail as your domain), DKIM (a cryptographic signature proving a message wasn't forged), and DMARC (what receivers should do when a message fails those checks) are all published as TXT records. Missing or misconfigured, they don't break sending outright, but they make your legitimate mail far more likely to land in spam.
If you take one thing from this section: changing MX or email-related TXT records affects mail deliverability, not your website, and vice versa. When email breaks, look at MX and TXT; when the site breaks, look at A, AAAA, and CNAME.
The supporting records
A few more types round out a typical zone:
- NS record — names the authoritative nameservers for your domain: the servers that hold the real answers for your zone. These are usually set at your registrar and are what delegate control of your DNS to a given provider. Changing them hands your entire zone to a different host, so treat NS changes with extra care.
- CAA record — specifies which certificate authorities are allowed to issue SSL/TLS certificates for your domain. It's a quiet security win: it narrows who can mint a certificate in your name.
- SOA record — the "start of authority" holds administrative metadata about the zone (the primary nameserver, a contact, and refresh timers). You rarely edit it by hand, but it's always present.
- PTR record — the reverse of an A record, mapping an IP back to a name. It lives with whoever controls the IP block (often your host), and matters mainly for mail servers proving they are who they claim.
TTL and propagation: why changes aren't instant
Two related ideas explain the single most common source of DNS confusion.
TTL (time to live) is a number, in seconds, attached to each record that tells resolvers around the world how long they may cache the answer before checking again. A TTL of 3600 means "remember this for an hour." Higher TTLs reduce lookups and are fine for records that rarely change; lower TTLs (300 seconds, say) make changes take effect faster because caches expire sooner.
Propagation is the visible result: when you edit a record, the new value doesn't reach everyone at once. Resolvers that cached the old answer keep serving it until the TTL expires. That's why a change can look "live" for you and stale for someone else for minutes or hours. The professional habit is to lower a record's TTL a day before a planned change, make the edit, confirm it, then raise the TTL back. If you didn't plan ahead, patience is the only fix — a blank page right after an edit is usually propagation, not a mistake.
The mistakes that cause the most outages
Most DNS pain comes from a short, familiar list:
- Editing more than one record at a time. When something breaks, you can't tell which change did it. Change one record, verify, then move on.
- Confusing A and CNAME. Pointing a root domain at a CNAME, or aliasing a name that also needs other records, produces errors that are hard to spot. Match the record type to what your provider actually gave you.
- Forgetting that email is separate. Migrating a website and moving the A record without carrying over MX and TXT records is a classic way to knock out mail while the site looks fine.
- Leaving the trailing dot off, or fat-fingering a value. DNS is unforgiving of typos. Copy values exactly from your provider rather than typing them.
- Assuming an edit failed because it isn't live yet. Give propagation time before you "fix" a change that was already correct.
A simple discipline prevents nearly all of these: before you touch a live zone, write down what each record currently points to, so you can always put it back.
FAQ
What's 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, which is then resolved to an address. Use an A record when you have an IP to target, and a CNAME when you want a name to automatically follow wherever another name goes — useful for subdomains that point at hosted services whose underlying IP may change.
Why does my website work but my email doesn't (or vice versa)?
Because they use different records. Your website is served through A, AAAA, and CNAME records, while email is routed by MX records and authenticated by TXT records (SPF, DKIM, DMARC). One set can be perfect while the other is broken, so diagnose the failing service by looking at its own record type.
How long do DNS changes take to work?
It depends on the record's TTL — the caching duration in seconds. Changes reach resolvers as their cached copies expire, so a low TTL (say 300 seconds) propagates in minutes while a high one can take hours. Lower the TTL before a planned change to speed things up, and expect a temporary window where some visitors see the old value and some see the new.
What is a TXT record used for?
A TXT record stores free-form text, and today its most important job is email authentication. SPF, DKIM, and DMARC are all published as TXT records that help receiving servers verify your mail is genuine. TXT records are also commonly used to prove domain ownership when you set up services like Search Console or an email provider.
Do I need to understand DNS to run a website?
Not deeply, but a working grasp of the common record types prevents most self-inflicted outages. Knowing that A and CNAME point your site, MX and TXT handle email, and TTL governs how fast changes take effect is enough to make safe edits — and to ask the right question when something breaks.
Next step
DNS records look intimidating until you see the pattern: a name, a type, a value, and a lifespan, repeated a handful of times. Learn the few types that matter — A and AAAA and CNAME for your site, MX and TXT for your mail, NS and CAA for control and security — respect TTL and propagation, and change one record at a time, and you'll avoid nearly every DNS emergency. For where DNS fits in the bigger picture of keeping a domain healthy, see the domain management guide and the walkthrough on connecting a domain to hosting. For more practical, vendor-neutral guidance on domains and search visibility, visit myqsd.com.
