Understanding DNS record types
DNS record types are the building blocks that tell the internet how a domain should behave. When someone opens a website, sends an email, verifies a service, or connects an application to a hostname, DNS is usually the first system involved. Many domain and hosting problems that look complicated are actually simple DNS mistakes: an A record points to the wrong IP, an MX record is missing, a CNAME conflicts with another record, or a TXT value is entered with the wrong syntax. That is why understanding DNS records is useful not only for administrators, but also for website owners, developers, and anyone who manages domains.
In practical terms, DNS is like a distributed address book. Instead of asking people to remember numeric IP addresses, DNS allows them to use names such as example.com or mail.example.com. But DNS does much more than translate names into IPs. It also tells mail servers where to deliver email, proves domain ownership for external services, publishes anti-spam policies, and supports subdomains and basic service discovery. If you manage a domain through Domain Registration, host a website on Hosting, or run custom services on Virtual Servers, you will work with DNS records sooner or later.
The most important thing to remember is that DNS works as a zone of records, not as one single setting. A domain can have many records at the same time, and each serves a specific purpose. The root domain may use an A record for the website, MX records for mail, TXT records for SPF and verification, and several subdomains with their own separate configuration. Understanding the common record types makes troubleshooting much easier, because you begin to see DNS as a structured system instead of a random list of values in a control panel.
The A record is the most familiar one. It points a hostname to an IPv4 address. If your website runs on a server with IP 203.0.113.10, an A record for example.com can point to that address. The AAAA record works the same way, but for IPv6. In practice, if a browser asks where example.com lives, the DNS server answers with the IP from the A or AAAA record.
example.com. 3600 IN A 203.0.113.10 example.com. 3600 IN AAAA 2001:db8::10
The CNAME record is different. It does not point directly to an IP address. Instead, it says that one hostname is an alias of another hostname. For example, www.example.com can be a CNAME to example.com, or shop.example.com can be a CNAME to an external SaaS platform hostname. CNAME is convenient because if the target changes its IP, you do not need to update the alias itself. However, a hostname with a CNAME should not also have conflicting records like A, MX, or another CNAME at the same label.
www.example.com. 3600 IN CNAME example.com.
The MX record controls email delivery. It tells other mail servers which mail host is responsible for receiving mail for your domain. If someone sends a message to info@example.com, the sending server checks the MX records for example.com and then connects to the mail server listed there. MX records usually include a priority value, where lower numbers mean higher priority. A common mistake is creating an MX record without also making sure the referenced mail hostname itself resolves through an A or AAAA record.
example.com. 3600 IN MX 10 mail.example.com. mail.example.com. 3600 IN A 203.0.113.20
TXT records are extremely flexible. In modern DNS they are often used for verification and policy publication. Services such as Microsoft 365, Google, and certificate providers ask you to add a TXT record to prove domain ownership. Email protection also depends on TXT records. SPF is published through TXT and tells the world which servers are allowed to send mail for your domain. Because TXT values can be long, the most common mistakes are broken spacing, missing quotation marks, or publishing the record under the wrong hostname.
example.com. 3600 IN TXT "v=spf1 mx ip4:203.0.113.20 -all" _acme-challenge.example.com. 3600 IN TXT "verification-token"
Closely related to email are DKIM and DMARC. DKIM uses TXT records under a selector, such as default._domainkey.example.com, to publish the public key used to verify signed messages. DMARC is usually placed at _dmarc.example.com and tells receiving servers what to do if SPF or DKIM checks fail. Together, MX, SPF, DKIM, and DMARC form the practical DNS foundation for business email. When people complain that mail goes to spam, DNS is often part of the answer.
The NS record defines which name servers are authoritative for the domain or a delegated subdomain. At the registrar level, NS records tell the internet where the domain’s DNS zone lives. Inside a zone, NS can also delegate a subdomain to another DNS provider or internal server. The SOA record contains administrative zone metadata such as the primary authoritative server and serial number used for zone updates.
example.com. 3600 IN NS ns1.provider.net. example.com. 3600 IN NS ns2.provider.net.
Another common record is PTR, used for reverse DNS. Unlike an A record, which maps a name to an IP, PTR maps an IP back to a hostname. Reverse DNS is especially important for mail servers, because many receiving systems check whether the sender IP has a meaningful PTR record. Unlike regular DNS records, PTR is usually controlled by the IP provider rather than by your normal DNS zone editor.
There are also specialized records that appear less often but are still useful. SRV records help clients locate services with host and port information. CAA records define which certificate authorities are allowed to issue SSL certificates for your domain. Many small websites never need to edit them manually, but larger infrastructures often use them to reduce mistakes and tighten control.
_sip._tcp.example.com. 3600 IN SRV 10 5 5060 sip.example.com. example.com. 3600 IN CAA 0 issue "letsencrypt.org"
How to read DNS correctly and avoid common mistakes
When working with DNS, the most important habits are consistency and patience. Always confirm the hostname, the record type, the target value, and the TTL. TTL defines how long resolvers may cache the answer. If you change an A record and do not see the effect immediately, that does not always mean the change failed; it may simply still be cached. Before a migration, administrators often lower TTL in advance, make the change, verify traffic, and then increase TTL again later.
One of the most common mistakes is mixing records at the same label incorrectly. For example, a hostname should not have both a CNAME and an A record at the same time. Another frequent problem is forgetting the difference between the root domain and a subdomain. A TXT or MX record published at the wrong label can look correct in the panel but still fail completely in real use. Email-related DNS is especially unforgiving: even a small formatting error in SPF, DKIM, or DMARC can break validation.
A practical way to verify DNS is to query it directly. Tools such as nslookup, dig, or online DNS checkers help confirm whether the record is published and visible from outside. For example, checking an A record or MX record directly can quickly show whether the issue is DNS itself or something else, such as a web server misconfiguration or a firewall problem.
nslookup example.com nslookup -type=MX example.com dig example.com A dig example.com TXT
If you manage websites, email, and external services under one domain, DNS becomes much easier when you document changes. Keep a simple record of which subdomains exist, what each record is for, and which services depend on them. DNS is not difficult because individual records are mysterious. It becomes difficult only when nobody remembers why the records were added in the first place.
In the end, understanding DNS record types means understanding the logic behind domain behavior. A and AAAA connect names to servers, CNAME creates aliases, MX directs mail, TXT publishes verification and policy data, NS and SOA define authority, PTR handles reverse lookups, and specialized records like SRV or CAA solve more focused tasks. Once these roles are clear, DNS panels stop looking confusing and start looking predictable.