Every domain on the internet is held together by DNS, and most of the time it works invisibly. But when it breaks -- when email stops arriving, a site goes unreachable, or an SSL certificate refuses to validate -- you need to read what your DNS records are actually saying. This guide covers every major record type, what the values mean, and how to track down the problems developers and site owners actually encounter.
Photo by Brett Sayles on Pexels
What DNS Records Actually Do
DNS is a distributed database that translates human-readable domain names into the IP addresses, mail servers, and service endpoints that machines use. When someone types a domain into a browser, the operating system queries a resolver, which walks a chain of authoritative nameservers until it finds an answer.
Each answer comes back as a DNS record -- a typed key-value pair with a time-to-live (TTL) that tells resolvers how long to cache it. The Domain Name System was defined in 1983 and has been extended many times since, which is why the list of record types is so sprawling. You rarely need all of them, but knowing what each one is responsible for saves real time when something goes wrong.
The A and AAAA Records
An A record maps a hostname to an IPv4 address. An AAAA record does the same for IPv6. These are the foundation of every website. When a browser resolves example.com, it reads the A record to find the server to connect to.
example.com. 300 IN A 203.0.113.5
A few things to check when debugging: if you have multiple A records pointing to different IPs for round-robin load balancing, confirm all IPs are reachable. If you recently migrated servers, an old A record cached at a long TTL is the most common reason some users still hit the old box while others see the new one. The number in the second column -- 300 in this example -- is the TTL in seconds.
CNAME Records
A CNAME (canonical name) is an alias that points one hostname to another hostname rather than directly to an IP. It tells resolvers to resolve the target name instead.
Common uses are www.example.com pointing to example.com, or app.example.com pointing to a Heroku or Vercel hostname. The important constraint: a CNAME cannot share a name with any other record at that label. A label with a CNAME cannot also have an MX or TXT record. If your DNS provider supports CNAME flattening (also called ALIAS or ANAME records), you can use CNAME-like behavior at the zone apex without this restriction.
MX Records
MX records control where email for your domain is delivered. Each MX record has a priority number (lower means more preferred) and a mail server hostname.
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
Misconfigured MX records cause email to bounce, get deferred, or disappear with no error at all. When diagnosing email problems, looking up just the MX record rarely tells the full story -- you also need to check whether the listed mail server hostnames have valid A records, and whether SPF and DMARC policies are in place. A DNS Lookup tool that consolidates all record types and adds email health diagnostics gets you to the problem faster than running separate queries for each type.
TXT Records
TXT records hold arbitrary text, but in practice they carry four categories of structured data you'll interact with regularly.
SPF (v=spf1 ...) lists IP ranges and hostnames authorized to send email for your domain. A missing SPF record is the most common reason transactional emails land in spam. Be careful of the lookup limit: SPF allows a maximum of ten DNS lookups in a single evaluation chain, including all nested include: directives. Exceeding ten causes a permerror that fails authentication.
DKIM (v=DKIM1; k=rsa; p=...) publishes a public key at a subdomain like mail._domainkey.example.com. Receiving mail servers use this key to verify your email sender's cryptographic signature. If DKIM fails, check that the subdomain your mail provider specified is correct and that the key hasn't expired.
DMARC (v=DMARC1; p=reject; ...) defines a policy telling receivers what to do when SPF and DKIM checks fail: reject, quarantine, or just report. Without a DMARC record, spoofed emails that fail SPF and DKIM will still be delivered to inboxes.
Domain verification tokens: Google Search Console, Mailchimp, Stripe, and many other platforms verify domain ownership by asking you to publish a specific TXT string. These are safe to leave in place after verification.
Photo by 饿狐网www_ewhooo_com on Pixabay
NS Records
NS (nameserver) records define which DNS servers are authoritative for your zone. These live at your domain registrar and at the zone apex. If your NS records point to the wrong nameservers after a migration, none of your other records will be found -- the resolver never reaches your zone. After moving to a new DNS host, confirm both the registrar NS entries and the zone NS entries match.
SOA Records
The Start of Authority record appears exactly once per zone and carries metadata: the primary nameserver, a contact address encoded as admin.example.com (with the first dot substituting for @), and timing parameters including a serial number. The serial number increments with every zone change. If two of your authoritative nameservers report different serial numbers, one is still propagating the most recent changes. Comparing serials is a quick sanity check when records seem inconsistent across locations.
CAA Records
CAA (Certification Authority Authorization) records restrict which certificate authorities are permitted to issue SSL/TLS certificates for your domain.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
Without a CAA record, any CA can issue certificates for your domain. With one, only the listed CAs can. If your SSL certificate renewal fails with a CAA validation error, confirm the CA your certificate service uses is present in the record. The CAA record specification is defined in RFC 6844.
How to Read a Raw DNS Response
When you query DNS directly with dig or nslookup, responses follow this format:
; <<>> DiG 9.18.0 <<>> example.com MX
;; ANSWER SECTION:
example.com. 3600 IN MX 10 aspmx.l.google.com.
example.com. 3600 IN MX 20 alt1.aspmx.l.google.com.
Each line is: name TTL class type rdata. The TTL column shows how many seconds this result stays cached downstream. A TTL of 3600 means resolvers cache the answer for one hour. A TTL of 300 means changes propagate within five minutes once the old cached answers expire.
Querying all record types individually takes time and forces you to mentally assemble the picture. The EvvyTools DNS Lookup tool runs queries for A, AAAA, CNAME, MX, TXT, NS, SOA, and CAA simultaneously, adds plain-English annotations, and includes email health checks -- useful for a fast, comprehensive view without eight separate terminal commands.
Photo by Paul Seling on Pexels
Common Diagnostic Scenarios
Email Not Arriving or Landing in Spam
- Check MX records: do they exist, and do the listed hostnames resolve to IP addresses?
- Check SPF: is it missing, or does the lookup chain exceed ten hops?
- Check DMARC: is there a policy record at
_dmarc.example.com? - Check DKIM: is the key published at the exact subdomain your mail provider specified?
- Confirm none of your MX hostnames are CNAMEs -- RFC 2821 prohibits MX records pointing to CNAME targets, and some mail servers reject them.
Site Unreachable After a Migration
- Confirm the A record at the new host is correct.
- Check the TTL on the old A record -- if it was 86400 (24 hours), some resolvers still hold the cached old IP.
- Verify NS records at the registrar point to the correct nameservers.
- If using a CDN with a CNAME at the apex, confirm the CNAME is being flattened to an IP correctly.
SSL Certificate Errors
- Check CAA records: is the issuing CA listed, or is a conflicting record blocking it?
- Confirm the A or CNAME record for the certificate's hostname resolves to the correct server -- HTTP-based certificate challenges require the server to be reachable.
"Ninety percent of the domain problems I debug come down to a stale TTL or an MX record deleted during a migration. Pulling all record types at once cuts the time to identify the issue from twenty minutes to two." - Dennis Traina, founder of 137Foundry
Understanding TTL and Propagation
TTL is set per record, not per zone. When planning a migration, reduce the TTL on the records you intend to change to 60 to 300 seconds at least 24 to 48 hours before the change. That way, the old cached records expire quickly once you make the switch. After the new records are live and verified, raise the TTL back to something reasonable like 3600 or 86400.
"DNS propagation" taking 48 hours is a common misconception. What propagates is not the record itself -- it is the expiry of cached answers at each resolver. If you pre-reduced your TTL, changes propagate in minutes. If you forgot to lower the TTL, you wait for the old TTL to expire before resolvers fetch the new answer. The DNS specification in RFC 1035 defines how resolvers are required to handle TTLs if you want the authoritative source.
Putting It Into Practice
The fastest diagnostic workflow for any DNS problem:
- Look up all record types at once rather than one at a time.
- Note the TTLs -- are they short enough that recent changes have propagated?
- For email issues, run an email health check alongside the standard DNS query.
- For web issues, trace the full A/CNAME resolution chain to the final IP.
- For certificate issues, check CAA before contacting your CA support team.
If you need additional web tooling, the EvvyTools tools directory includes tools for meta tag inspection, schema validation, and other web infrastructure checks alongside DNS. More diagnostic walkthroughs are in the EvvyTools blog.
DNS is straightforward once you know which record type handles which concern. The hard part is remembering which one to check first. The scenarios above cover the majority of real-world problems -- keep them handy the next time something breaks.
Photo by Budget Bizar on Pexels
