What Are DNS Records? A Beginner’s Setup Guide

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 can prevent websites from loading or email from reaching the intended server. 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 adapt to your DNS provider’s panel, where it supports the relevant record types.

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 DNS panel, depending on the provider and plan)
• 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. If the answer is not cached, the resolver follows referrals as needed: 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, visitors may fail to connect or reach the wrong server.

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

These IP addresses are documentation examples; use the actual addresses assigned to your server. 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, or create them if absent. If www is already a CNAME to the root domain, it can follow the root’s address records; do not add A/AAAA records alongside that CNAME.
4. Use the IPv4 address assigned by your hosting or VPS provider for A records. Publish AAAA records only for a working IPv6 address on the destination server; remove obsolete AAAA records if the new server has no IPv6 service.
5. Ensure the destination web server is configured to serve your domain and www, including valid certificates if using HTTPS.
6. Set a reasonable TTL (e.g. 900–3600 seconds).
7. 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)

Publish AAAA records when your server and website are reachable over IPv6. Check the IPv6 address, routing, firewall rules, web-server configuration and HTTPS certificate before publishing it. Keeping A records alongside working AAAA records lets clients connect over either protocol. An AAAA record alone does not enable IPv6 on the server; an incorrect one can cause connection failures for clients that try IPv6.

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 alongside ordinary data records such as A, AAAA, MX or TXT for the same name; DNSSEC-related records are an exception.
• You cannot use a standard 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 user@example.com, their mail server looks up the MX records for example.com and connects to those servers.

An ordinary MX record does not contain an IP address directly. It points to a hostname, which must have its own A and/or AAAA records and must not be a CNAME alias.

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.

Multiple MX records can support resilience when the backup mail servers are configured to accept and relay mail for the domain. MX priorities alone do not configure 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 hostnames and priorities from your new email provider or mail-server configuration. Set up the destination mailboxes before switching.
2. In the DNS panel for your authoritative nameservers, locate existing MX records for @. If lowering their TTL, do so at least one existing TTL interval before the switch.
3. Replace them with the new MX entries and priorities.
4. Ensure each MX hostname resolves through an A and/or AAAA record; the email provider normally manages these for its own hostnames.
5. Update SPF, DKIM and DMARC as appropriate for the new sending service, preserving any senders still in use.
6. Keep the old mail service accepting mail while cached MX records expire, and test sending and receiving through the new service before retiring the old one.

Remember that good email delivery needs more than just MX. SPF, DKIM and DMARC are important for outgoing authentication, and some receivers require all three for bulk senders.

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 domain-control verification tokens.

Common uses of TXT records

• SPF (Sender Policy Framework) to list allowed mail senders.
• DKIM public keys for verifying email signatures.
• DMARC policies to request handling of mail that fails both aligned SPF and aligned DKIM authentication.
• Domain-control 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 illustrative policy authorizes the listed IP and IPs that pass the included domain’s SPF policy for this domain’s envelope sender identity, not necessarily the visible From address. ~all gives other senders a softfail result, not an automatic rejection. Replace the example IP and include domain with your actual sending service’s values, and maintain only one SPF TXT policy at this name. Keep DNS-query-causing terms within SPF’s limit of 10 across the entire evaluation, including nested includes and redirects; exceeding this limit produces permerror.

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. The values above are placeholders: use the exact value supplied by the service or ACME client. Successful verification demonstrates control of the relevant DNS name, not legal ownership of 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 support SRV discovery for a service can automatically find its servers and select among them. They try the lowest-numbered priority they can reach first. Among targets with equal priority, weight gives a relative selection preference: the example’s weights of 60 and 20 favor the first target by roughly three to one, not by fixed percentages of actual traffic.

Each ordinary target hostname must have one or more A and/or AAAA records and must not be a CNAME alias. Create the address records for both SIP targets in this example, or confirm that the service provider manages them. A special target consisting only of a dot indicates that the service is unavailable for that name.

When you’ll see SRV records

SRV records are common when:

• Configuring enterprise directory or communications services whose documentation requires SRV discovery.
• 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 available in DNS, clients that support SRV discovery for that service can use the records to find the host and port.

Putting It Together: Typical DNS Setups for a New Website

Scenario 1: New website on shared hosting

Let’s say you’ve registered example.com and purchased a shared hosting plan. Here are two common approaches, depending on which DNS services are available with your chosen plan.

Option A: Use hosting-provider nameservers, if available

1. If your hosting plan includes authoritative DNS, create or review the domain’s zone there before changing nameservers.
2. Verify the required A/AAAA, MX and TXT records, including any existing email and verification records. Do not assume they were auto‑created or copied.
3. Before switching, check whether the parent zone has a DNSSEC DS record for your domain, usually managed through your registrar. If it does, coordinate the transition with the old and new DNS operators and registrar so the parent DS record and the new operator’s signing keys and signatures remain compatible. Leaving an old DS record with incompatible new keys can cause validation failures. Use their supported rollover procedure, or an explicitly coordinated temporary unsigned transition with appropriate DS removal and cache-expiry waits; simply disabling signing is not enough. This is a prerequisite, not a complete DNSSEC migration runbook.
4. Once the zone and any DNSSEC transition are ready, set the domain’s nameservers at your registrar to those assigned by the DNS service.
5. Allow cached delegation information to expire; timing varies. Keep the old DNS zone available during the transition, and verify resolution through the new nameservers and validating resolvers before retiring it.

Using one provider for hosting and DNS can simplify administration, but you still need to verify the zone’s records.

Option B: Keep registrar DNS, point to your hosting IPs

1. Keep your registrar’s nameservers.
2. In the registrar DNS panel, create or edit:

• A record for @ → your hosting IPv4 address (from your hosting provider).
• A or CNAME record for www → either the IP or example.com.
• MX record(s) to the hostnames specified by your email provider, with its supplied priorities.
• SPF, DKIM and DMARC records as appropriate for your sending services; preserve other verification TXT records.

This keeps DNS administration separate from hosting, so update the registrar’s DNS records whenever your hosting or mail-service settings change.

Scenario 2: Website on a VPS + separate email provider

Assume you have a VPS 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): the table below is a schematic checklist, not an importable zone file. Replace all placeholders with actual service values. Supply the email provider’s MX priority as well as its hostname, and use its complete SPF policy rather than the … placeholder. Publish AAAA only if the VPS and website are reachable over IPv6.

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 separates the DNS routing for web hosting (your VPS) from email hosting (your provider). Configure the services themselves too, including outgoing DKIM signing and the provider’s DKIM and DMARC DNS records where applicable.

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 also have A, AAAA, TXT or MX records. 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: Ensure each MX target hostname has a valid A and/or AAAA record. Delivery to a target without an address record cannot succeed, though another working MX target may still receive the mail.

3. Forgetting about TTL and propagation

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

Fix: Lower TTL at least one existing TTL interval before a migration so previously cached records have time to expire. Lowering it at the moment of the switch does not shorten the lifetime of those cached copies. 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. Also check your panel’s hostname format: the trailing dots in these examples mark fully qualified names in zone-file notation. Some panels add the zone name to relative targets, while others handle full names automatically; confirm the saved target is the hostname you intended.

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; protection against spoofed answers depends on resolvers validating the signatures through a trusted chain.

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 and their IP addresses at the registrar where glue is required, such as when the nameservers are within the domain they serve.
• Configuring corresponding NS and A/AAAA records in your DNS server.

If you want to run or brand your own nameservers (for example on a 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 and TXT for website and email setup, plus SRV for service discovery. 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.

For a new domain or hosting migration, plan the required website, email and verification records before making changes. 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.