DNS Record Types Explained

The A record is the most fundamental DNS record. It answers the question: 'What IP address does this domain point to?' When you set up a website, you create an A record pointing your domain to your web server's IPv4 address. You can have multiple A records for the same domain to distribute traffic across multiple servers — a technique called round-robin DNS load balancing. The A record is also what controls where subdomains like www.example.com or app.example.com resolve. Every domain serving a website needs at least one A record.

The AAAA record is the IPv6 equivalent of the A record. As the internet transitions from IPv4 (which only provides ~4.3 billion addresses) to IPv6 (which provides 340 undecillion addresses), adding AAAA records alongside A records ensures your site is accessible to users on IPv6-only networks. Major ISPs in many countries have largely moved to IPv6 for residential customers. Modern web servers and CDNs support both protocols simultaneously. If a visitor's device prefers IPv6, it will use the AAAA record; otherwise, it falls back to the A record.

A CNAME record creates an alias — it says 'this name is the same as that other name'. The most common use is making www.example.com point to example.com, so both work. CNAMEs are also extensively used by SaaS platforms: when you set up a custom domain on Shopify, Netlify, GitHub Pages, or HubSpot, they give you a CNAME record to create. Important limitation: a CNAME record cannot coexist with other records at the same name. This means you cannot create a CNAME for the root domain (example.com) because the root must also have NS and SOA records — use an ALIAS or ANAME record (supported by some providers) for root domain aliasing.

The MX record is what allows your domain to receive email. When someone sends an email to you@example.com, the sending mail server looks up the MX record for example.com to find where to deliver it. Each MX record includes a mail server hostname and a priority number. Lower priority numbers are preferred — if priority 10 is available, it is tried before priority 20. Having multiple MX records with different priorities creates redundancy: if the primary mail server is unavailable, email queues at the backup server instead of bouncing. Without valid MX records, your domain cannot receive email at all.

TXT records are multipurpose text records that hold human-readable or machine-readable string data. Originally intended for informational notes, TXT records have become critical for email deliverability and domain ownership verification. Three email authentication systems all rely on TXT records: SPF (Sender Policy Framework) lists which mail servers are authorized to send email for your domain; DKIM (DomainKeys Identified Mail) publishes a public cryptographic key used to verify email signatures; DMARC (Domain-based Message Authentication) defines the policy for handling emails that fail SPF or DKIM. TXT records are also used by Google Search Console, Microsoft, and hundreds of other platforms to prove you control a domain.

NS records are among the most important in your DNS configuration. They tell the rest of the internet which DNS servers hold the authoritative records for your domain. NS records are set at your domain registrar (the company you bought the domain from) and point to your DNS provider's nameservers. When you switch DNS providers — for example, from GoDaddy DNS to Cloudflare DNS — you update the NS records at your registrar. Until the NS records propagate, your new DNS configuration will not be active. Every domain must have at least two NS records for redundancy, and most providers assign four. NS records cannot be changed at the DNS provider level — they must be changed at the registrar.

The SOA (Start of Authority) record is automatically created by your DNS provider and contains administrative metadata about the DNS zone. It includes the primary nameserver hostname, the zone administrator's email address (written with a dot instead of @), a serial number that increments with every zone change, and several timing parameters: refresh interval (how often secondary nameservers check for updates), retry interval (how long to wait after a failed refresh), expire time (when secondary data becomes invalid if primary is unreachable), and minimum TTL for negative caching. You typically do not edit SOA records manually — your DNS provider manages them automatically. However, seeing the serial number can help verify whether a DNS change was published.

PTR records perform the opposite function of A records: instead of mapping a domain to an IP, they map an IP address to a domain name. This is called reverse DNS lookup. PTR records are stored in a special zone called in-addr.arpa (for IPv4) or ip6.arpa (for IPv6). They are set by whoever controls the IP address — typically your hosting provider or ISP, not your domain registrar. PTR records are critical for email deliverability: receiving mail servers verify that the IP address your mail server sends from has a PTR record pointing to a hostname, and that hostname's A record points back to the same IP. Mail servers without proper PTR records are frequently blocked or spam-filtered.

SRV records specify the hostname and port number of servers for specific services and protocols. They follow a naming convention: _service._protocol.domain. The record includes a priority, weight (for load balancing among equal-priority records), port number, and target hostname. SRV records are commonly used for VoIP (SIP protocol), XMPP instant messaging, Microsoft Teams and Skype for Business, and various other services. When setting up Microsoft 365 or Google Workspace, your email provider may require SRV records in addition to MX records for services like Autodiscover (email client configuration) or Federation.

CAA records are a security mechanism that tells certificate authorities (CAs) whether they are permitted to issue SSL/TLS certificates for your domain. This prevents unauthorized SSL certificate issuance — a known attack vector where an attacker tricks a CA into issuing a certificate for a domain they do not own. A CAA record specifying only Let's Encrypt means no other CA can issue a certificate for your domain. Without any CAA record, any accredited CA can issue certificates, which is the default behavior. The tag 'issue' restricts which CA can issue standard certificates, 'issuewild' restricts wildcard certificates, and 'iodef' specifies a URL or email for violation reports.