DNS Record Types Explained: Practical Guide to A, AAAA, MX, CNAME, TXT, SRV and CAA

When you change hosting, launch a new site or move email to a new provider, almost everything comes down to one thing: getting your DNS records right. A single typo in an A record or MX record can make your website disappear or bounce every email your customers send. The good news is that once you understand what A, AAAA, MX, CNAME, TXT, SRV and CAA records actually do, DNS stops feeling like black magic and becomes a predictable, repeatable part of your workflow.

In this guide, we’ll walk through each of these DNS record types with practical, real‑world examples from the kinds of setups we see every day at dchost.com: small business websites, online stores, SaaS projects and agency stacks. You’ll see how the records fit together, what can safely be changed, and which mistakes you really want to avoid. By the end, you’ll be able to read any DNS zone and say, “I know what every one of these records is doing – and I know how to fix it if something breaks.”

Why DNS Records Matter for Your Website and Email

DNS (Domain Name System) is the address book of the internet. Every time someone visits your domain or sends you an email, their device asks DNS questions like “What IP address is example.com?” or “Which mail server handles email for this domain?” The answers come from the DNS records you (or your hosting team) configure.

From a hosting perspective, DNS is the glue that connects four main pieces: your domain name, your web server, your email platform and your SSL certificates. If you’re not fully clear on how those pieces fit together, it’s worth reading our article about how domain, DNS, server and SSL work together in a typical hosting setup. Once you see the big picture, individual DNS records make much more sense.

In this article, we’ll focus on the seven record types you’ll touch most often when you run websites and email: A, AAAA, MX, CNAME, TXT, SRV and CAA. We’ll also highlight how to change them safely and how to plan your DNS so migrations and rebuilds are much less stressful.

Core DNS Concepts Before You Edit Anything

Before diving into individual record types, a few core DNS concepts will save you a lot of headaches.

Zone vs. Record

A DNS zone is the configuration for a domain (for example, example.com) stored on one DNS provider or nameserver set. Inside that zone live multiple records like A, MX, CNAME, TXT, etc. When you edit DNS in a hosting panel or registrar interface, you’re editing records in that zone.

Root (@) vs. Subdomain

• @ usually means “the root of the domain”, e.g. example.com.
• Anything like www, shop or api is a subdomain, e.g. www.example.com, shop.example.com.

Many DNS mistakes come from mixing up whether a record should be set on the root (@) or on a subdomain (like www).

TTL (Time To Live)

Every DNS record has a TTL, which tells other DNS resolvers how long they can cache the answer. A high TTL (e.g. 4 hours) means changes propagate more slowly but reduce DNS traffic. A low TTL (e.g. 5–15 minutes) means faster changes but more lookups.

We recommend learning how to use TTL strategically – for example, lowering TTL before a migration and raising it afterwards. Our detailed guide on DNS TTL best practices for A, MX, CNAME and TXT records covers concrete values and scenarios.

Propagation and Caching

When you change a DNS record, it doesn’t update instantly everywhere. Resolvers that previously cached the old record may keep using it until its TTL expires. That’s why you often hear “DNS changes can take up to 24 hours”. In practice, many changes are visible much sooner, but you must expect some overlap.

If DNS propagation still feels fuzzy, you’ll find it useful to read our article on what DNS propagation is, why it can take hours and how to speed it up using TTL.

A and AAAA Records: Pointing Your Domain to a Server

A and AAAA records are the most fundamental DNS records for a website. They map a hostname (like example.com or www.example.com) to an IP address.

• A record: points to an IPv4 address, e.g. 203.0.113.10.
• AAAA record: points to an IPv6 address, e.g. 2001:db8::1234.

Typical A/AAAA Record Examples

• @ A 203.0.113.10 – example.com opens the website on your server.
• www A 203.0.113.10 – www.example.com goes to the same site.
• @ AAAA 2001:db8::1234 – dual‑stack: your root domain also works over IPv6.

On shared hosting, your A record usually points to the IP of the hosting server. On a VPS, dedicated server or colocated server at dchost.com, it points directly to your own server’s public IP.

Dual‑Stack: Using A and AAAA Together

Modern setups increasingly use both A (IPv4) and AAAA (IPv6) for the same hostname. Clients that support IPv6 will prefer it, others will fall back to IPv4. Dual‑stack improves reach and future‑proofs your domain, especially as IPv6 adoption keeps rising globally.

If you’re planning to add IPv6 to your infrastructure, our articles on rising IPv6 adoption and its impact on hosting and our practical IPv6 setup guide for VPS servers will help you design a clean dual‑stack DNS plan.

Common A/AAAA Mistakes

• Forgetting www: You update example.com but leave www.example.com pointing to the old server, so some visitors hit the wrong site.
• Wrong IP address: One digit off in an A record can point your domain at someone else’s server (or a dead IP).
• Mixing A and CNAME on the same name: Many DNS providers won’t let you do this; even if they do, it leads to undefined behaviour. Pick one type per hostname.
• Adding AAAA without testing IPv6: If your server’s IPv6 isn’t configured correctly (firewall, web server, reverse proxy), some users may see timeouts while IPv4 users are fine.

MX Records: Making Email Deliver to the Right Server

MX (Mail Exchanger) records tell the world which server(s) accept email for your domain. Whenever someone sends an email to [email protected], their mail server looks up MX records for example.com and delivers the message according to the priorities you set.

How MX Records Work

• Each MX record has a priority (a number) and a target hostname (not an IP address).
• Lower numbers = higher priority. A server will try priority 10 first, then 20, then 30, etc.

Example basic MX setup:

• @ MX 10 mail.example.com.
• mail A 203.0.113.20

Here, email for @example.com goes to mail.example.com, which then resolves via an A record to your mail server IP.

Multiple MX Records for Redundancy

For higher availability, you can add backup MX servers with higher priority values:

• @ MX 10 mail1.example.com. (primary)
• @ MX 20 mail2.example.com. (secondary)

If mail1 is down, senders will try mail2. This is especially valuable for larger organisations or when you self‑host email on a VPS or dedicated server.

MX Record Pitfalls

• Pointing MX directly to an IP: MX targets must be hostnames with A/AAAA records, not raw IPs.
• Forgetting to update MX during migrations: You move mailboxes to a new platform but leave MX pointing to the old server, so users think “email is lost”.
• No reverse DNS or SPF/DKIM/DMARC: Even if MX is correct, missing authentication records will hurt deliverability.

If you’re managing your own email (on shared hosting or a VPS), you’ll want to combine correct MX records with email authentication. Our guide on SPF, DKIM and DMARC basics for small businesses explains how the TXT records for these standards work alongside MX.

CNAME Records: Creating Aliases for Hostnames

CNAME (Canonical Name) records let you create an alias: “this hostname is really that other hostname”. DNS resolvers then follow the alias and resolve the target’s A/AAAA records.

Typical CNAME Uses

• Pointing www to the root: www.example.com → example.com.
• CDN or external service: static.example.com → mycdn.example-cdn.net.
• Third‑party tools: news.example.com → pages.email-provider.com, status.example.com → statuspage.vendor.net.

Example:

• www CNAME example.com.
• blog CNAME blogs.hosted-platform.net.

Rules and Limitations of CNAME

• No other records on the same name: If www has a CNAME, it can’t also have A, AAAA, MX, TXT or SRV records.
• Usually not at the root: Most DNS providers don’t allow a CNAME at @ (the zone apex), because the root often needs NS, SOA and other records.
• CNAME is an alias, not a redirect: Browsers still show the original hostname in the URL bar. HTTP redirects (301/302) are handled by your web server, not DNS.

Security Note: Orphaned CNAMEs and Subdomain Takeover

If you point a CNAME to a third‑party platform and later cancel that service without deleting the DNS record, an attacker may be able to register that target and hijack the subdomain – a “subdomain takeover”.

If you use many external services, it’s worth reading our guide on subdomain takeover and orphaned DNS records and the hidden risks for your brand and SEO. We also recommend periodic DNS audits, especially for agencies managing many client domains.

TXT Records: Verification, SPF, DKIM, DMARC and More

TXT records are free‑form text blobs attached to a hostname. Originally intended for “any text”, they’ve become the standard home for all sorts of policies and verifications, especially for email and web services.

Common TXT Record Uses

• SPF (email sender policy): defines which servers are allowed to send email for your domain.
• DKIM (email signatures): stores public keys used to verify that emails weren’t tampered with.
• DMARC: tells receivers how to treat messages that fail SPF/DKIM and where to send reports.
• Service verification: search engines, analytics tools and SaaS platforms often ask you to add a TXT record like google-site-verification=... or service=12345abcd.

Example SPF record:

• @ TXT "v=spf1 a mx include:mail-provider.net -all"

Email providers read this to decide whether a given sending IP is authorised to send as @example.com.

TXT Record Best Practices

• Multiple TXT records are allowed: You can have separate TXT records for SPF, verification and other uses on the same hostname.
• Watch SPF DNS lookup limits: Overly complex SPF records with many include: mechanisms can hit the 10‑lookup limit and break SPF entirely.
• Keep a documentation file: For each TXT record, note which service requested it and when. This makes cleanup easier when you stop using a tool.

For a step‑by‑step walkthrough of SPF, DKIM and DMARC and how they live inside your TXT records, see our guide on SPF, DKIM and DMARC for cPanel and VPS email or, if you prefer a business‑level view, the article we mentioned earlier about email authentication for small businesses.

SRV Records: Directing Services to the Right Port

SRV (Service) records are less common for basic sites, but essential in some application stacks. They answer the question: “For this service, on this domain, which host and port should I use?”

SRV Record Structure

An SRV record has this structure:

_service._proto.name.  TTL  priority  weight  port  target

• _service: the service name (e.g. _sip, _xmpp).
• _proto: _tcp or _udp.
• name: the domain name the record applies to (e.g. example.com).
• priority and weight: similar to MX; used for load balancing and failover between multiple targets.
• port: the TCP/UDP port number (e.g. 5060 for SIP).
• target: the hostname of the server providing the service; that hostname must have A/AAAA records.

Example SRV Use Cases

• VoIP / SIP services: Clients discover the SIP server and port for a given domain.
• Chat protocols (XMPP): SRV points clients to the correct host and port for messaging servers.
• Some Microsoft services: Autodiscover and other protocols rely on SRV for service discovery.

A simplified SRV example for a SIP service might look like:

• _sip._tcp.example.com. 3600 10 60 5060 sip1.example.com.
• _sip._tcp.example.com. 3600 20 20 5060 sip2.example.com.

Here, sip1 is preferred, but sip2 acts as backup or load‑sharing depending on your client configuration.

CAA Records: Controlling Which CAs Can Issue SSL Certificates

CAA (Certification Authority Authorization) records are a security control for your SSL/TLS certificates. They tell certificate authorities (CAs) which providers are allowed to issue certificates for your domain.

Why CAA Records Matter

Without CAA, in theory any publicly trusted CA could issue a certificate for your domain (subject to normal validation). If an attacker tricks or compromises a CA, they could obtain a certificate you never asked for. A well‑designed CAA policy drastically reduces that risk by saying “only these specific CAs may issue for this domain”.

Simple CAA Examples

• @ CAA 0 issue "letsencrypt.org" – only Let’s Encrypt can issue certificates for your domain.
• @ CAA 0 issue "zerossl.com" – only ZeroSSL can issue.
• @ CAA 0 iodef "mailto:[email protected]" – tell CAs where to report policy violations.

Many organisations combine free CAs for routine certificates and commercial CAs for EV/OV or specialised use. In that case, you list all allowed CAs with multiple CAA records.

If you’re running a corporate or B2B site where trust and compliance matter, CAA fits into a larger picture of TLS and brand assurance. We cover this in our article on SSL and trust architecture for B2B corporate websites, including HSTS preload and CAA. For a deeper technical dive specifically on CAA syntax and multi‑CA strategies, see our in‑depth CAA records guide.

Putting It All Together: Example DNS Setups

Scenario 1: Simple Business Website with Hosted Email

Let’s say you host your website on a shared hosting or VPS plan at dchost.com and use a separate, specialised email service.

• Website
  • @ A 203.0.113.50 (your dchost.com web server)
  • www CNAME example.com. (alias www → root)
• Email
  • @ MX 10 mx1.mailservice.net.
  • @ MX 20 mx2.mailservice.net.
  • @ TXT "v=spf1 include:spf.mailservice.net -all"
  • _dmarc TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
  • selector1._domainkey TXT "v=DKIM1; k=rsa; p=..."
• Verification & SSL
  • @ CAA 0 issue "letsencrypt.org"
  • @ TXT "google-site-verification=..." (if needed)

Here, the web and email are cleanly separated: web traffic hits your hosting server, while email goes to the external mail provider. If you later move the website to a different dchost.com server, you only change the A record; email keeps working untouched.

Scenario 2: SaaS App with Multiple Subdomains

Now imagine a SaaS app where you host your main marketing site on one server, the app on another, and a status page on a third‑party provider:

• Main site
  • @ A 203.0.113.100
  • www CNAME example.com.
• App
  • app A 203.0.113.200 (separate VPS cluster)
  • api A 203.0.113.201 (API node)
• Status page
  • status CNAME status.vendor-status.com.
• Email & security
  • @ MX 10 mx1.mailservice.net.
  • @ TXT "v=spf1 include:spf.mailservice.net -all"
  • @ CAA 0 issue "letsencrypt.org"
  • @ CAA 0 issue "zerossl.com" (multi‑CA strategy for automation)

This layout separates concerns clearly: each subdomain can be migrated or scaled independently. If you ever move api to a dedicated cluster or containerised setup, you only update its A/AAAA records.

Practical Workflow for Editing DNS Safely

Knowing what each record does is step one. Step two is having a safe process whenever you change DNS. Here’s a workflow we use and recommend to our customers at dchost.com.

1. Take an Inventory Before You Touch Anything

• Export your current DNS zone if your provider allows it.
• Screenshot or copy all existing A, AAAA, MX, CNAME, TXT, SRV and CAA records into a document.
• Note which systems depend on which records (website, email, third‑party tools).

This gives you a quick rollback path if something goes wrong.

2. Lower TTLs Before Big Changes

Before moving a website or email service, lower the TTL on the relevant records (often to 300 seconds / 5 minutes) 24 hours ahead of time if possible. This ensures caches expire quickly when you make the cutover. Our article on DNS TTL strategy for zero‑downtime migrations walks through this step in detail.

3. Change One Record Group at a Time

• For a web migration, change A/AAAA (and related CNAMEs) first.
• For an email migration, update MX, SPF (TXT), DKIM and DMARC together.
• For SSL changes, review CAA and any DNS‑01 challenge TXT records.

Avoid “big‑bang” edits where you modify many unrelated records at once; troubleshooting becomes much harder.

4. Test from Multiple Networks

After changes, test:

• Using dig or nslookup against your authoritative nameservers.
• From your own connection and from a different network (mobile data, VPN).
• Using online DNS checkers to see what remote resolvers are seeing.

This helps you distinguish between “authoritative DNS is wrong” and “some resolvers still have old cache”. Our guide on DNS propagation and how to interpret mixed results can be handy here.

5. Clean Up Old and Unused Records

Over time, zones accumulate stale CNAMEs, TXT verifications for long‑gone services, old A records and forgotten SRV entries. These aren’t just messy – they can become security risks (e.g. subdomain takeover) or cause confusion during incident response.

• Delete records for services you no longer use.
• Document what each remaining record does.
• Consider enabling DNSSEC on your domains to protect against tampering; our practical guide on what DNSSEC is and when you should enable it explains the trade‑offs.

Summary and Next Steps with Your DNS

A handful of DNS record types do most of the heavy lifting for real‑world websites and email. A and AAAA connect your domain to your hosting servers. MX, SPF, DKIM and DMARC (in TXT records) keep email flowing and authenticated. CNAME makes it easy to integrate third‑party services and CDNs. SRV quietly directs specialised applications to the right host and port. CAA adds a final, important layer of control over who can issue SSL certificates for your domain.

Once you understand how these records work together, DNS stops being something you fear breaking and becomes another tool you can design and reason about. Whether your sites run on shared hosting, managed WordPress, VPS, dedicated servers or colocated hardware with us at dchost.com, a clean DNS architecture will make every future migration, upgrade and security improvement easier.

If you’re planning a move to a new server, splitting web and email, or consolidating many client domains, now is a great moment to audit your DNS zones and fix old mistakes. And if you’d like help mapping records to the right dchost.com hosting, VPS, dedicated or colocation setup, our team can review your current DNS, suggest safer TTL strategies and design a migration plan that keeps your website and email online while everything changes under the hood.