Technology

What Are DNS Records? A Step‑by‑Step Beginner’s Guide to A, AAAA, CNAME, MX, TXT and SRV

If you own a domain name or plan to launch a website, you will run into DNS records very quickly. They decide where your website lives, which server receives your email, and how third‑party tools verify that you actually control a domain. Misconfigured DNS is one of the most common reasons we see sites not loading or emails going missing on our infrastructure at dchost.com. The good news: you don’t need to be a network engineer to manage the basics. Once you understand what a DNS record is and what each common type does, most everyday tasks—like pointing a domain to your hosting, setting up email, or verifying your site with a service—become straightforward. In this guide, we’ll walk through the key DNS record types (A, AAAA, CNAME, MX, TXT and SRV) using simple language, real‑world examples, and practical steps you can follow on any DNS control panel.

İçindekiler

What Is DNS, and What Exactly Is a DNS Record?

The phone book of the internet

DNS (Domain Name System) is like a phone book for the internet. Humans like names such as example.com; computers use IP addresses like 203.0.113.10 or 2001:db8::10. DNS converts domain names into IP addresses so browsers and email servers know where to connect.

A DNS record is a single entry in that phone book. It says something like:

  • “For example.com, go to IP address 203.0.113.10.”
  • “For email to @example.com, use mail server mail.example.com.”
  • “For blog.example.com, just treat it as another name for example.com.”

Every one of these statements is stored as a DNS record of a specific type (A, AAAA, CNAME, MX, etc.). Together, they form the DNS “zone” for your domain.

Where your DNS records live

Your DNS records are stored wherever your domain’s nameservers point. That might be:

  • Your domain registrar’s DNS panel
  • Your web hosting provider’s DNS (for example, via cPanel, DirectAdmin or a custom panel at dchost.com)
  • A dedicated DNS provider or a CDN that also offers DNS

When you change DNS settings, you’re usually editing records on one of these systems. If you’d like to go deeper into choosing between hosting DNS and an external DNS service, we’ve written about how to choose the right nameserver and DNS strategy.

How DNS Records Work Behind the Scenes

The basic DNS lookup flow

When someone types www.example.com into their browser, this roughly happens:

  1. The browser asks the operating system for the IP of www.example.com.
  2. The OS asks a recursive DNS resolver (usually your ISP or public DNS).
  3. The resolver follows the chain: Root → TLD (.com) → your domain’s nameservers.
  4. Your nameserver replies with the DNS records (e.g. an A record with an IP).
  5. The resolver caches the answer based on the record’s TTL (time‑to‑live).

The important part for you: the final answer (which IP, which mail server, etc.) comes directly from the DNS records you manage in your DNS panel.

TTL: how long DNS records are cached

Every DNS record has a TTL (Time‑To‑Live) value in seconds. It tells resolvers how long they can safely cache the answer before asking again. For example:

  • 300 seconds = 5 minutes
  • 3600 seconds = 1 hour
  • 86400 seconds = 24 hours

When you make changes, old answers may stay in caches until the TTL expires. That’s why DNS changes can appear “slow” to propagate. For more detailed strategies on using TTL values—especially when planning a migration—take a look at how to use TTL for fast DNS propagation and zero‑downtime migrations.

Common record fields you’ll see in a DNS panel

Most DNS interfaces show something like:

  • Type: A, AAAA, CNAME, MX, TXT, SRV, etc.
  • Name / Host: The subdomain, e.g. @ (root), www, mail.
  • Value / Target: IP address, hostname, or other data.
  • TTL: Cache time for resolvers.
  • (Sometimes) Priority: Used by MX and SRV records.

A and AAAA Records: Pointing Your Domain to a Server

What A and AAAA records do

A records map a hostname to an IPv4 address (e.g. 203.0.113.10).

AAAA records map a hostname to an IPv6 address (e.g. 2001:db8::10).

These are the core records that make your website reachable. If they are wrong, your site simply will not load.

Typical examples

Type   Name   Value            TTL
A      @      203.0.113.10     3600
A      www    203.0.113.10     3600
AAAA   @      2001:db8::10     3600
AAAA   www    2001:db8::10     3600

Here:

  • @ represents the root domain example.com.
  • www represents www.example.com.
  • Both resolve to the same server over IPv4 and IPv6.

Step‑by‑step: point a domain to your hosting or VPS

  1. Log in to the DNS panel where your nameservers point.
  2. Find the DNS zone for your domain (e.g. example.com).
  3. Locate existing A/AAAA records for @ and www.
  4. Update the IPs to match the ones from your hosting or VPS at dchost.com.
  5. Set a reasonable TTL (e.g. 900–3600 seconds).
  6. Save and wait for propagation.

If your IPs include IPv6, you can also follow our detailed IPv6 setup and configuration guide for VPS servers to ensure everything is correctly configured on the server side.

When to use AAAA (IPv6)

IPv6 adoption is growing quickly, and having AAAA records is becoming a best practice. Many visitors and networks prefer IPv6 when available. As long as your hosting or VPS has IPv6 correctly configured and firewalled, adding AAAA records improves compatibility and future‑proofing.

CNAME Records: Aliases for Easier DNS Management

What a CNAME record does

A CNAME (Canonical Name) record makes one hostname an alias of another hostname. The alias does not point directly to an IP; it simply says “use the other name’s records.”

Example:

Type   Name        Value              TTL
A      @           203.0.113.10       3600
CNAME  www         example.com.       3600

Here, www.example.com uses whatever IPs example.com resolves to. If you later change the A/AAAA records of example.com, www automatically follows.

Good uses for CNAME records

  • Pointing www to the root domain.
  • Creating aliases like blog.example.com that follow another hostname.
  • Setting up third‑party services that ask you to create a CNAME to their hostname.

Where CNAME is not allowed

There are two important rules:

  • You cannot have a CNAME and any other record type (A, MX, TXT, etc.) for the same name.
  • Traditionally, you cannot use CNAME at the root (@) of your domain. Some DNS providers offer special features (ALIAS/ANAME/flattening) to simulate this, but it is not a standard CNAME.

If you’re interested in deeper tricks like CNAME at the apex and ALIAS/ANAME records, we’ve covered them in more detail in our article on CNAME at the domain root and when to use CNAME‑like features safely.

MX Records: Making Email Reach the Right Server

What MX records do

MX (Mail Exchanger) records tell the world which mail servers handle email for your domain. When someone sends an email to [email protected], their mail server looks up the MX records for example.com and connects to those servers.

An MX record does not contain an IP address directly. It points to a hostname, which then must have A/AAAA records.

Typical MX configuration

Type  Name   Priority  Value               TTL
MX    @      10        mail.example.com.   3600
A     mail   203.0.113.20                  3600

Here:

  • Emails to @example.com go to mail.example.com.
  • mail.example.com resolves to IP 203.0.113.20.

Priority and multiple MX records

The priority field lets you define order and redundancy:

MX  @  10  mail1.example.com.
MX  @  20  mail2.example.com.
  • Mail servers try priority 10 first.
  • If it’s down, they try priority 20 as a backup.

This is how you build more resilient email setups with backup MX servers or split delivery. For more advanced email redundancy designs, see our guide to email redundancy with multiple MX, backup MX and split delivery.

Step‑by‑step: switch your domain’s email to a new provider

  1. Get the MX records and hostnames from your new email provider or from your mail server on your dchost.com VPS/hosting.
  2. In your DNS panel, locate existing MX records for @.
  3. Replace them with the new MX entries and priorities.
  4. Ensure each MX hostname has a valid A/AAAA record.
  5. Optionally lower TTL beforehand to make the switch quicker.
  6. Wait for propagation and test sending/receiving email.

Remember that good email delivery needs more than just MX. You also need SPF, DKIM and DMARC, which we’ll touch on shortly when we discuss TXT records.

TXT Records: Verification, SPF, DKIM and More

What a TXT record is

A TXT record stores arbitrary text under your domain. It’s extremely flexible, so many standards use it to publish policies, security settings, and ownership proof.

Common uses of TXT records

  • SPF (Sender Policy Framework) to list allowed mail senders.
  • DKIM public keys for email signing.
  • DMARC policies to tell receivers how to handle suspicious emails.
  • Domain ownership verification for search engines, SaaS platforms or CDN services.

SPF example

Type  Name  Value                                              TTL
TXT   @     "v=spf1 ip4:203.0.113.20 include:_spf.example.net ~all"  3600

This says: “Only the listed IP and included hosts are allowed to send mail for this domain; everything else is questionable.”

Domain verification example

Type  Name              Value                                 TTL
TXT   @                 "google-site-verification=abcdef..."  3600
TXT   _acme-challenge   "random-token-for-ssl-issue"          300

Different services ask you to create TXT records with specific names and values. Once visible in DNS, they confirm you own the domain.

We have a dedicated guide that goes deeper into email TXT records—SPF, DKIM and DMARC—especially for cPanel and VPS users: you can learn how to configure SPF, DKIM and DMARC step‑by‑step for your own domain.

SRV Records: Directing Traffic to Specific Services

What an SRV record does

SRV (Service) records tell clients where to find a specific service (like VoIP, chat, or directory services) for your domain. They include:

  • Service name (e.g. _sip for SIP/VoIP)
  • Protocol (e.g. _tcp or _udp)
  • Priority and weight (to choose between multiple servers)
  • Port number
  • Target hostname

Typical SRV record format

_service._proto.name.  TTL  IN  SRV  priority weight port target.

Example for a SIP service:

Type  Name               Priority  Weight  Port  Target
SRV   _sip._tcp          10        60      5060  sip1.example.com.
SRV   _sip._tcp          10        20      5060  sip2.example.com.

Clients that understand SRV (like some VoIP phones, chat apps or Microsoft services) can automatically discover servers and load‑balance between them.

When you’ll see SRV records

SRV records are common when:

  • Setting up enterprise services like Microsoft 365, Lync/Skype for Business or similar tools.
  • Using SIP‑based VoIP providers that support DNS‑based discovery.
  • Integrating services like XMPP chat or certain game servers.

Usually, you just copy‑paste SRV details from the service documentation into your DNS panel. Once added, clients automatically find the right host and port.

Putting It Together: Typical DNS Setups for a New Website

Scenario 1: New website on shared hosting at dchost.com

Let’s say you’ve registered example.com and purchased a shared hosting plan from dchost.com. Here are two common approaches.

Option A: Use dchost.com nameservers

  1. At your domain registrar, set the nameservers to the ones provided by dchost.com.
  2. Wait for nameserver changes to propagate (often 1–24 hours).
  3. Log into your hosting control panel; DNS records for your domain are usually auto‑created.
  4. Verify that A/AAAA, MX and basic TXT records are in place.

This is the simplest for beginners: we manage most of the DNS details for you.

Option B: Keep registrar DNS, point to dchost.com IPs

  1. Keep your registrar’s nameservers.
  2. In the registrar DNS panel, create or edit:
  • A record for @ → your hosting IP (from dchost.com).
  • A or CNAME record for www → either the IP or example.com.
  • MX record(s) to the mail server you’re using (dchost.com hosting or external).

This gives you more direct control, but you must keep everything in sync.

Scenario 2: Website on a VPS + separate email provider

Assume you have a VPS at dchost.com for your app and an external email service.

  • On the VPS side: configure your web server (Nginx/Apache) and get the server IPs.
  • DNS configuration (at registrar or DNS provider):
Type  Name   Value / Target            Notes
A     @      <VPS IPv4>                Main site
AAAA  @      <VPS IPv6>                Optional, but recommended
CNAME www    example.com.              Alias to root
MX    @      <email-provider-host>.    From provider docs
TXT   @      "v=spf1 include:... ~all" SPF from provider

This cleanly separates web hosting (your VPS) from email hosting (your provider), all controlled via DNS records.

Common DNS Mistakes and How to Avoid Them

1. Mixing CNAME with other records on the same name

Problem: You add a CNAME for www and also create A/TXT/MX records for www.

Fix: A hostname with a CNAME must not have any other record types. If you need multiple records, replace the CNAME with A/AAAA records instead.

2. Missing A/AAAA records for MX targets

Problem: MX points to mail.example.com, but mail.example.com has no A/AAAA record.

Fix: Always ensure each MX target hostname has valid A/AAAA records, or email delivery will fail.

3. Forgetting about TTL and propagation

Problem: You change an A record and expect the whole world to see it instantly.

Fix: Remember caches respect TTL; lower TTL ahead of a migration and be patient. Our guide on TTL strategies for zero‑downtime moves covers this in practical detail.

4. Typos in hostnames

Problem: An MX record points to mail.exampe.com instead of mail.example.com.

Fix: Copy‑paste hostnames from provider documentation, and double‑check spelling. One misplaced letter can break email or web access completely.

5. Wrong DNS provider panel

Problem: You edit DNS at your registrar, but the domain’s nameservers actually point somewhere else (for example, your hosting or a CDN). Your changes appear to “do nothing.”

Fix: First check which nameservers your domain uses. Always edit DNS in the panel associated with those nameservers.

If your domain refuses to resolve and you’re not sure why, walk through our step‑by‑step guide on diagnosing and fixing common DNS errors such as DNS_PROBE_FINISHED_NXDOMAIN.

Security and Advanced Topics Worth Knowing

DNSSEC: protecting DNS answers from tampering

DNSSEC adds cryptographic signatures to your DNS data so resolvers can verify that answers are authentic and not modified in transit. It does not hide or encrypt records, but it prevents certain spoofing attacks.

Enabling DNSSEC usually requires steps both at your DNS provider and your domain registrar (DS records). If you’re interested in hardening your domains, we’ve explained what DNSSEC is and how it makes your website more secure.

Private nameservers and glue records

Some agencies and advanced users prefer to use private nameservers like ns1.yourbrand.com rather than generic names like ns1.provider.com. This requires:

  • Registering the nameserver hostnames at the registrar with “glue” A/AAAA records.
  • Configuring corresponding NS and A/AAAA records in your DNS server.

If you want to run or brand your own nameservers (for example on your dchost.com VPS or dedicated server), our guide on setting up private nameservers and glue records walks through the process.

More record types beyond this beginner’s list

In this article we focused on A, AAAA, CNAME, MX, TXT and SRV—the ones you’ll see most often. There are many more types (NS, CAA, PTR, SOA, etc.). If you’re curious and want a friendly, deeper technical dive including CAA records and real‑world gotchas, read our piece on DNS records from A to SRV and the small mistakes that trip people up.

Summary: Getting Comfortable with DNS Records

DNS feels mysterious until you see it for what it is: a structured list of simple rules. Each record answers one very specific question. A and AAAA records answer “which IP should I connect to?” CNAME answers “which other hostname should I follow?” MX answers “which server receives mail for this domain?” TXT answers “what extra policies or verification tokens apply here?” and SRV answers “where can I find this particular service and on which port?” Once you know which question you’re trying to answer, choosing the right record type becomes much easier.

At dchost.com, we see every level of DNS usage—from small business sites with a handful of A and MX records, to complex agency setups with custom nameservers, DNSSEC, and multi‑provider redundancy. If you’re setting up a new domain, moving to our shared hosting, VPS, dedicated servers or colocation, or simply need someone to sanity‑check your DNS zone, our team can help you plan a clean, resilient configuration from day one. And if you ever get stuck, the guides we’ve linked here will walk you through TTL planning, DNS troubleshooting, security hardening and more, so DNS becomes just another calm part of your stack—not a source of surprises.

Frequently Asked Questions

A DNS record is a single entry in the internet’s "phone book" for your domain. It maps a domain or subdomain to something specific, such as an IP address, a mail server, or a verification token. For example, an A record might say "example.com lives at 203.0.113.10", while an MX record might say "email for @example.com goes to mail.example.com". All these records together form the DNS zone for your domain and control how browsers, email servers and other services reach you.

DNS changes can appear almost instantly in some places and take hours in others. The main factor is the TTL (Time-To-Live) on your records, which tells resolvers how long they can cache old answers. If your A record has a TTL of 3600 seconds (1 hour), you can expect some users to still see the old IP for up to an hour after you change it. For planned migrations, it’s smart to lower TTL ahead of time so changes spread faster. We cover practical TTL strategies in our guide on using TTL for zero-downtime DNS moves.

An A record directly maps a hostname to an IPv4 address (for example, www.example.com → 203.0.113.10) and is used mainly for websites and services. A CNAME record doesn’t store an IP; it makes one hostname an alias of another (for example, blog.example.com → example.com), so it follows whatever IPs the target has. An MX record is used only for email and tells other mail servers which hostname receives email for your domain (for example, @example.com → mail.example.com). That MX target must then have its own A or AAAA record so it resolves to an IP.

You don’t strictly need both, but it’s recommended when possible. A records provide IPv4 connectivity, which is still essential today. AAAA records provide IPv6 connectivity, which is increasingly common as IPv4 addresses become scarce. If your hosting or VPS at dchost.com supports IPv6 and is correctly configured, adding AAAA records lets visitors and networks that prefer IPv6 connect over the newer protocol while still supporting IPv4. This improves compatibility, performance in some regions, and future-proofs your infrastructure.

You can use several methods. Most DNS panels show an overview of your current zone, which is a good starting point. From your own computer, commands like "nslookup", "dig" or "host" let you query specific records (A, AAAA, MX, TXT, etc.) and see exactly what’s published. There are also online DNS lookup tools that display records from different locations. When troubleshooting a site that doesn’t load or email that doesn’t arrive, check that your A/AAAA and MX records point to the right hosts, that each MX target has an A/AAAA record, and that TTL values aren’t causing you to see stale data. For deeper troubleshooting, you can follow our detailed guide on diagnosing common DNS errors such as DNS_PROBE_FINISHED_NXDOMAIN.