DNS Records Explained: How to Manage A, CNAME, MX, TXT and More

When you launch a new website or move a service to a new server, the most critical step that often causes confusion is not the code or the server itself – it is the DNS configuration. A single incorrect record can make your site unreachable, break email delivery, or cause SSL warnings for days. In my work designing hosting architectures and managing data center environments, I see the same patterns over and over: people are comfortable with domains and hosting, but DNS records feel like a black box. In this article, we will break down A, CNAME, MX, TXT and other key records in clear language, walk through practical management workflows, and share real-world tips you can apply immediately on your own domain, whether you host on your own infrastructure or use a provider like DCHost.

What DNS Actually Does

DNS (Domain Name System) is often described as “the phone book of the internet”, but that description is incomplete. DNS is more like a distributed database that translates human-readable names into technical details that browsers, mail servers and other systems need to talk to each other.

When someone types example.com into a browser, several steps happen:

The resolver (often your ISP or a public DNS service) asks the DNS hierarchy: “Who is responsible for example.com?”
The authoritative nameservers for example.com reply with records such as A, AAAA, MX, etc.
The resolver caches the answer for the duration of the record’s TTL (Time To Live).

If any of these records are wrong or missing, your site, API or email may fail. Understanding how these records work is essential, just like understanding the relationship between your domain and hosting. For more background on that angle, you can read the detailed article on the relationship between domain names and hosting.

Core Concepts: Zones, Records and TTL

DNS Zone

A DNS zone is the part of the DNS namespace that a particular DNS provider or server is responsible for. For example, the zone for example.com typically contains records for:

example.com (the root or apex)
www.example.com
mail.example.com
api.example.com

When you manage DNS via your registrar, your hosting panel or a provider like DCHost, you are essentially editing this zone file.

Records and Types

Each line in the zone is a record. A record has four main parts:

Name: which hostname this record applies to (e.g., www or @ for the root).
Type: A, CNAME, MX, TXT, etc.
Value: destination IP address, hostname, or other data.
TTL (Time To Live): how long resolvers cache this record, usually in seconds.

TTL and Propagation

TTL controls how quickly changes spread across the internet. For example:

TTL 300 (5 minutes): faster propagation, more DNS traffic.
TTL 3600 (1 hour): good balance in most cases.
TTL 86400 (24 hours): stable but slow to update.

Before big changes (like moving a site to a new server), I typically lower TTL to 300–600 seconds a day in advance, then raise it again after the migration. This approach is especially useful when following a detailed plan like the HTTPS migration checklist without losing SEO.

A and AAAA Records: Pointing Your Domain to Servers

A records and AAAA records are the backbone of your website’s reachability.

A Record (IPv4)

An A record maps a hostname to an IPv4 address.

Name: @ (root) or www
Type: A
Value: 203.0.113.10 (example IPv4)

Typical usage scenarios:

Point example.com to your web server’s IPv4 address.
Point api.example.com to a separate backend server.
Point panel.example.com to your control panel or management interface.

On infrastructure managed through a provider like DCHost, you will usually get one or more IPv4 addresses that you then reference in your DNS A records.

AAAA Record (IPv6)

An AAAA record maps a hostname to an IPv6 address.

Name: @ or www
Type: AAAA
Value: 2001:db8::10 (example IPv6)

Best practices:

If your server has IPv6, create both A and AAAA records for future-proofing.
Ensure firewalls and web server configs are correctly set for IPv6 traffic.
Monitor access logs to verify both IPv4 and IPv6 traffic are served correctly.

CNAME Records: Aliases Without Breaking Things

A CNAME record creates an alias from one hostname to another. Instead of pointing directly to an IP, it points to another hostname that eventually resolves to an IP.

How CNAME Works

Example configuration:

Name: www
Type: CNAME
Value: example.com.

This means www.example.com simply follows whatever the A/AAAA records of example.com are. If you ever change the server IP, you only update the root A record.

CNAME Dos and Don’ts

Do use CNAME for subdomains like blog.example.com pointing to a hosted blog platform.
Do use CNAME for service integrations (e.g., status.example.com pointing to an external status page provider).
Do not create a CNAME at the zone apex (for example.com) unless your provider explicitly supports “ANAME” or “ALIAS”-style records.
Do not mix CNAME with other record types on the same name (e.g., CNAME and MX together are invalid for the same hostname).

In architecture design meetings, I often prefer CNAME for all non-critical subdomains pointing to external services. It reduces the risk of forgetting to update multiple records when IPs change.

MX, SPF, DKIM and TXT: Reliable Email Delivery

Email is where most DNS-related pain appears. If your MX or TXT records are wrong, messages bounce, land in spam, or disappear silently. Let us break down the essentials.

MX Records: Where Your Mail Arrives

MX (Mail Exchanger) records tell the world which servers handle email for your domain.

Name: @ (root)
Type: MX
Priority: 10, 20, etc. (lower is higher priority)
Value: mail.example.com.

Key points:

MX records must point to hostnames, not IP addresses.
Those hostnames must have valid A/AAAA records.
Use multiple MX records with different priorities for redundancy.

TXT Records: SPF, DKIM and Verification

TXT records are generic text fields in DNS. They are heavily used for email security and service verification.

SPF (Sender Policy Framework)

SPF specifies which servers are allowed to send email for your domain. It is stored in a TXT record, for example:

v=spf1 ip4:203.0.113.10 include:mailprovider.com -all

Guidelines:

Define all legitimate sending sources (mail servers, transactional email services, etc.).
Avoid more than 10 DNS lookups in your SPF record.
Use -all (hard fail) only when you are sure your configuration is complete.

DKIM (DomainKeys Identified Mail)

DKIM uses public/private keys to sign your email. The public key is published as a TXT record under a selector, such as:

selector1._domainkey.example.com

Your mail server or provider generates the key pair. You publish the public key in DNS, and receiving servers verify signatures using that key.

DMARC

DMARC builds on SPF and DKIM to tell receivers how to handle failing messages and where to send reports.

Example TXT record at _dmarc.example.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s

For businesses relying heavily on email, I strongly recommend configuring SPF, DKIM and DMARC together. This significantly improves deliverability and reduces spoofing.

Other TXT Use Cases

TXT records are also used for:

Domain ownership verification for SSL certificates.
Search console or analytics verification.
Third-party SaaS integration checks.

When you are working on SSL and HTTPS strategies, you will often combine DNS TXT verification with steps similar to those in the article on what an SSL certificate is and how to choose the right type.

Other Important Records: NS, SOA, SRV, PTR, CAA

Beyond A, CNAME, MX and TXT, there are several other records that matter for more advanced configurations.

NS (Name Server) Records

NS records tell the world which servers are authoritative for your zone.

Set at the registrar level for the domain itself.
Also appear inside the zone as a reference.

You usually do not change NS records every day. However, when you move DNS management (for example, from your registrar’s panel to your hosting provider or to DCHost), updating NS records at the registrar is the key step.

SOA (Start of Authority)

The SOA record contains meta information about the zone:

Primary nameserver.
Responsible email (often with a dot instead of @).
Serial number used for zone transfers.
Refresh, retry and expire timers for secondary nameservers.

In most managed DNS panels you do not need to touch SOA, but in more advanced or self-hosted setups it matters for zone replication.

SRV Records

SRV records specify services with ports and priorities, commonly used by:

VoIP systems.
Chat/IM services.
Some Microsoft and LDAP-based services.

Example: a SIP service might publish where SIP clients should connect without the user manually entering ports and hostnames.

PTR (Reverse DNS) Records

PTR records are the reverse of A/AAAA records. They map IP addresses back to hostnames and live in special reverse zones.

They are especially important for:

Email servers (many spam filters check PTR consistency).
Logging, auditing and compliance.

Reverse DNS is usually managed by whoever owns the IP address range (your hosting provider or data center). If you run your own mail server on a VPS or dedicated server, make sure your provider (for instance, DCHost if you use their infrastructure) sets a PTR record that matches your mail server hostname.

CAA Records

CAA (Certification Authority Authorization) records define which certificate authorities are allowed to issue SSL certificates for your domain.

Example:

example.com. CAA 0 issue "letsencrypt.org"

Benefits:

Reduces the risk of unauthorized certificate issuance.
Improves compliance and security posture.

Practical DNS Management Workflow

Let us look at a simple, repeatable workflow I use in real projects when setting up a new site.

1. Plan the Architecture

Before touching DNS, define what you need:

Main website (www + root domain).
Mail service (own mail server or external provider).
APIs or admin panels on separate subdomains.
External services (status page, helpdesk, marketing tools).

During capacity or security planning, you may also be thinking about VPS hardening and monitoring. DNS planning belongs in that same early architecture phase, alongside tasks like securing your VPS server step by step.

2. Prepare Records with Low TTL

Lower TTL values (e.g., 300–600 seconds) for records you are about to change.
Create or update A/AAAA records for the new web server.
Set CNAMEs for subdomains that should follow the main site.

3. Configure Email DNS

Set MX records to your chosen mail servers.
Add SPF, DKIM and DMARC TXT records according to your provider’s documentation.
Send test messages to different providers and check headers for SPF/DKIM/DMARC alignment.

4. Test Before Switching Traffic

Always test new DNS settings before large user traffic hits them:

Use tools like dig or nslookup to verify records.
Test HTTP/HTTPS access using hosts file overrides or temporary subdomains.
Validate SSL configuration and certificates.

Combining DNS checks with a thorough HTTPS and SSL checklist, such as the one in the HTTP to HTTPS migration checklist in Turkish, reduces production surprises.

5. Monitor and Then Raise TTL

After going live, monitor logs, uptime and email deliverability for several hours.
If everything looks stable, increase TTL for key records (e.g., to 3600 or 14400 seconds) to reduce DNS query load and improve cache efficiency.

Common Mistakes and Troubleshooting Tips

Over the years, I have seen certain DNS mistakes repeat across companies of all sizes. Avoiding these will save you a lot of time.

Misconfigured A and CNAME Records

Using CNAME at the root: Most DNS systems do not allow a CNAME on example.com if other records exist. Use A/AAAA or provider-specific ALIAS/ANAME instead.
Mixing CNAME with other types on the same name: If www has a CNAME, it cannot also have MX, TXT or A/AAAA records.
Pointing MX to an IP: MX must always point to a hostname with its own A/AAAA record.

Forgetting to Update All Environments

In multi-environment setups (production, staging, testing), it is easy to update DNS for one environment and forget others. I recommend maintaining a simple spreadsheet or configuration file documenting:

All subdomains and their purposes.
Target IPs or hostnames.
TTL values.
Who owns the service (team or vendor).

DNS and Security Blind Spots

Unsecured servers behind DNS: DNS might be correct, but the server is misconfigured or insecure. Combine DNS work with reading about web hosting security recommendations to cover both layers.
Forgotten subdomains: Old test or staging subdomains left pointing to abandoned servers can be taken over or exploited.
Lack of CAA records: Without CAA, any trusted CA can issue certificates for your domain, which increases attack surface.

Debugging with Command-Line Tools

When something does not work, command-line tools are your best friends.

dig example.com A: Check A record.
dig example.com MX: Check MX configuration.
dig TXT example.com: Inspect SPF and other TXT records.
dig +trace example.com: Trace resolution from root servers down to your authoritative servers.

Compare what dig shows with what you expect from your control panel. If they differ, either caching (TTL) or misconfiguration is the cause.

Considering Hosting and DNS Together

Finally, remember that DNS does not live in isolation. It is tightly connected to your hosting architecture, server performance and security posture. When you evaluate or migrate hosting providers, or design a setup with DCHost or another platform, DNS routing should be part of the same planning conversation as choosing server resources and security baselines. Articles like how to choose fast and reliable hosting and the broader discussions across this blog can help you think holistically.

Conclusion: Make DNS Your Ally, Not a Mystery

DNS looks intimidating at first glance, but once you understand the key record types and how they interact, it becomes a powerful tool instead of a constant source of risk. A and AAAA records connect your domain to your servers, CNAMEs give you flexible aliases, MX and TXT records make email reliable and secure, and supporting types like NS, SOA, SRV, PTR and CAA complete the picture.

My recommendation is to treat DNS with the same discipline you apply to server hardening or data center redundancy: document your records, plan changes, lower TTLs before migrations, and test thoroughly. If you are comfortable managing your own infrastructure or working with providers such as DCHost, you already have the mindset needed to manage DNS confidently. For an even deeper dive into DNS configuration details, you can also check the full DNS management guide in Turkish. Start with a single domain, experiment in a controlled way, and DNS will quickly become one of the most reliable parts of your stack.