DNS Records Explained: A, CNAME, MX, TXT and Friends
What each DNS record type does, how TTL and propagation really work, and how to fix the DNS problems behind most site outages and email delivery issues.
When a website is unreachable or emails land in spam, the cause is DNS more often than anything else. DNS is not complicated, but it has a few rules that are easy to forget until something breaks. This guide covers the records you will actually meet. You can look up any domain as you read with the DNS lookup tool.
The records that matter
- A and AAAA map a name to an IPv4 or IPv6 address. Most websites need both if the server has IPv6.
- CNAME makes one name an alias of another. It cannot sit next to other records on the same name, which is why you cannot put a CNAME on the bare domain (example.com) in classic DNS.
- MX lists the mail servers for a domain, each with a priority. Lower numbers are tried first.
- NS names the servers that are authoritative for the domain. If these are wrong, nothing else matters.
- TXT holds text and has become the home of email authentication (SPF, DKIM, DMARC) and of domain ownership checks for Google, Microsoft and others.
- CAA restricts which certificate authorities may issue certificates for the domain.
- PTR maps an IP address back to a name. It is set by whoever owns the IP, usually the hosting provider, and mail servers check it.
TTL and “propagation”
DNS does not propagate in the sense of being pushed around the world. Resolvers cache each answer for the TTL (time to live) of the record, in seconds. If the old record had a TTL of 86400, some users may keep seeing the old address for up to a day after you change it. The trick is to lower the TTL to 300 a day before a planned change, make the change, and raise it again afterwards.
Email: SPF, DKIM and DMARC
Since 2024, Gmail and Yahoo require proper authentication for bulk senders, and in practice everyone else benefits too. Three TXT records do the work:
- SPF (v=spf1 …) lists the servers allowed to send mail for your domain. There must be exactly one SPF record, and it must stay under 10 DNS lookups.
- DKIM publishes a public key at selector._domainkey.yourdomain so receivers can verify signatures on your messages.
- DMARC at _dmarc.yourdomain tells receivers what to do when SPF and DKIM fail, and where to send reports.
Choosing “ALL” in our lookup tool shows SPF and DMARC together, which is the quickest health check for a domain’s email setup.
Common problems and their causes
- Site works for you but not for others: an entry in your hosts file, or you are still seeing a cached old record.
- NXDOMAIN: the name does not exist at all. Check for typos and that the domain has not expired.
- Mail rejected after moving providers: the old provider is still in SPF, the new one is missing, or the MX records point to the old servers.
- Certificate cannot be issued: a CAA record that does not include your certificate authority, or an A record still pointing to the old server.
- Two SPF records: this is invalid and makes SPF fail completely. Merge them into one.
Our take
Most DNS disasters we have been called in to fix came from changes made in a hurry, without a record of what was there before. Before editing a zone, export it or at least take a screenshot. Keep the number of people with access to the registrar small and protect that account with two-factor authentication, because whoever controls your DNS controls your website and your email. And when you move a site, change the DNS last, after the new server is fully tested, with a low TTL so you can roll back in minutes.