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
- 1 What Is DNS, and What Exactly Is a DNS Record?
- 2 How DNS Records Work Behind the Scenes
- 3 A and AAAA Records: Pointing Your Domain to a Server
- 4 CNAME Records: Aliases for Easier DNS Management
- 5 MX Records: Making Email Reach the Right Server
- 6 TXT Records: Verification, SPF, DKIM and More
- 7 SRV Records: Directing Traffic to Specific Services
- 8 Putting It Together: Typical DNS Setups for a New Website
- 9 Common DNS Mistakes and How to Avoid Them
- 10 Security and Advanced Topics Worth Knowing
- 11 Summary: Getting Comfortable with DNS Records
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 address203.0.113.10.” - “For email to
@example.com, use mail servermail.example.com.” - “For
blog.example.com, just treat it as another name forexample.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:
- The browser asks the operating system for the IP of
www.example.com. - The OS asks a recursive DNS resolver (usually your ISP or public DNS).
- The resolver follows the chain: Root → TLD (.com) → your domain’s nameservers.
- Your nameserver replies with the DNS records (e.g. an A record with an IP).
- 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:
300seconds = 5 minutes3600seconds = 1 hour86400seconds = 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 domainexample.com.wwwrepresentswww.example.com.- Both resolve to the same server over IPv4 and IPv6.
Step‑by‑step: point a domain to your hosting or VPS
- Log in to the DNS panel where your nameservers point.
- Find the DNS zone for your domain (e.g.
example.com). - Locate existing A/AAAA records for
@andwww. - Update the IPs to match the ones from your hosting or VPS at dchost.com.
- Set a reasonable TTL (e.g. 900–3600 seconds).
- 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
wwwto the root domain. - Creating aliases like
blog.example.comthat 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.comgo tomail.example.com. mail.example.comresolves to IP203.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
- Get the MX records and hostnames from your new email provider or from your mail server on your dchost.com VPS/hosting.
- In your DNS panel, locate existing MX records for
@. - Replace them with the new MX entries and priorities.
- Ensure each MX hostname has a valid A/AAAA record.
- Optionally lower TTL beforehand to make the switch quicker.
- 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.
_sipfor SIP/VoIP) - Protocol (e.g.
_tcpor_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
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
- At your domain registrar, set the nameservers to the ones provided by dchost.com.
- Wait for nameserver changes to propagate (often 1–24 hours).
- Log into your hosting control panel; DNS records for your domain are usually auto‑created.
- 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
- Keep your registrar’s nameservers.
- 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 orexample.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.
