DNS Records Explained: A, AAAA, CNAME, MX, TXT, and When to Use Each

Overview

If you only remember one thing, make it this: DNS records do different jobs, and most problems come from using the right record type in the wrong place, or the wrong value in the right place.

Here is the short version of the main record types:

• A record: points a hostname to an IPv4 address.
• AAAA record: points a hostname to an IPv6 address.
• CNAME record: points one hostname to another hostname.
• MX record: tells the internet which mail servers handle email for a domain.
• TXT record: stores text values commonly used for domain verification, email authentication, and service configuration.

In practical terms:

• Use A when you have an IPv4 server address.
• Use AAAA when you also want IPv6 support.
• Use CNAME when a provider gives you a target hostname instead of an IP.
• Use MX when setting up inbound email.
• Use TXT for ownership verification, SPF, DKIM, DMARC, and other service-specific instructions.

A few DNS basics help everything else make sense:

• Hostname means the name you are configuring, such as www.example.com or api.example.com.
• Root or apex domain usually means the bare domain, such as example.com without a subdomain.
• TTL means time to live. It is how long resolvers may cache the answer before checking again.
• Propagation is the slow-looking period after a change where some resolvers still show old answers because of caching.

One of the most common questions in DNS basics is a record vs cname. The rule of thumb is straightforward: if you need a hostname to resolve directly to an IP, use an A or AAAA record; if you need one hostname to alias another hostname, use CNAME. The important limitation is that a CNAME usually should not coexist with other records on the same hostname.

That matters most at the root domain. Some DNS providers support special behavior for root-domain aliasing, but the underlying principle stays the same: follow your provider's supported method instead of forcing a plain CNAME where it does not belong.

Checklist by scenario

This section gives you a reusable decision checklist for the cases that come up most often.

1. Point a domain or subdomain to a web server

Use this when you are launching a site, moving hosts, or routing traffic to an app server.

• If your host gives you an IPv4 address, create an A record.
• If your host gives you an IPv6 address, create an AAAA record.
• If your host gives you a target hostname, create a CNAME for the relevant subdomain.

Example decisions:

• www.example.com to host.platform.example → use CNAME.
• app.example.com to 203.0.113.10 → use A.
• api.example.com to 2001:db8::10 → use AAAA.

Checklist:

• Confirm whether you are editing the root domain or a subdomain.
• Read the host's instructions carefully; many managed platforms want CNAME for www and a separate approach for the root.
• Remove old conflicting records for the same hostname.
• Set a reasonable TTL if you expect to revisit the change soon.
• Verify the result with DNS lookup tools from more than one network if possible.

If the site is part of a broader performance review, DNS is only one layer. After resolution is correct, it helps to review delivery and rendering work too, such as the guidance in Core Web Vitals Checklist: How to Improve LCP, INP, and CLS.

2. Send a subdomain to another hostname

This is the classic CNAME case and one of the simplest DNS setups when supported by your provider.

Use CNAME when:

• You are connecting www, docs, status, or another subdomain to a third-party service.
• The provider explicitly gives you a canonical target like customer.vendor-host.com.

Checklist:

• Create the CNAME only on the exact hostname the provider specifies.
• Do not add an A record for the same hostname unless the provider explicitly documents that pattern.
• Make sure the target is a hostname, not an IP address.
• Check for trailing dot behavior in your DNS interface; some panels add it automatically and some do not.

3. Set up inbound email for a domain

Email requires more than one record type. For receiving email, the core record is MX.

MX record explained simply: it tells sending mail systems where mail for your domain should go.

Checklist for MX record setup:

• Get the exact mail server hostnames from your email provider.
• Create the required MX records at the domain level, usually for the root domain.
• Use the provider's specified priority values.
• Remove old MX records if you are fully migrating providers.
• Do not point MX directly to an IP address; MX points to hostnames.

In most real setups, MX is only part of the picture. You will usually also add TXT records for SPF, DKIM, and often DMARC.

Typical supporting records:

• SPF in a TXT record to declare which servers may send mail for your domain.
• DKIM in a TXT record to publish a public key used for message signing.
• DMARC in a TXT record to define policy and reporting for authentication failures.

If email delivery matters to your business, treat DNS changes here like deployment changes: review them carefully, document the old state, and verify after rollout. The mindset is similar to a release checklist in CI/CD Pipeline Checklist: What to Validate Before Every Production Deploy.

4. Verify a domain with a third-party service

This is where TXT record explained becomes especially useful. Many platforms ask you to add a TXT record to prove you control the domain.

Common verification use cases:

• Search and webmaster tools
• Email platforms
• CDNs and hosting platforms
• Identity or SSO providers
• API and SaaS integrations

Checklist:

• Use the exact hostname requested; some verifications belong on the root domain, others on a subdomain.
• Paste the TXT value exactly as given.
• Do not merge unrelated TXT values unless your provider documentation says to.
• Wait for caching to expire before retrying verification.
• Keep a note of why the record exists so it is not removed later during cleanup.

5. Support both IPv4 and IPv6

If your infrastructure supports both protocols, configure both A and AAAA records.

Checklist:

• Confirm the service is actually reachable over IPv6 before publishing AAAA.
• Make sure certificates, firewalls, load balancers, and health checks also support IPv6.
• Test from a client that prefers IPv6 to catch issues early.

Publishing a broken AAAA record can create confusing partial outages. Some users may hit the healthy IPv4 path while others fail over IPv6.

6. Migrate hosting without breaking email

This is a common source of avoidable downtime because teams change web records and email records together without separating concerns.

Checklist:

• Change only the records related to the web application first, usually A, AAAA, or CNAME.
• Leave MX and email-related TXT records unchanged unless the mail provider is also changing.
• Lower TTL ahead of the cutover if your provider and workflow allow it.
• Take a snapshot of the current zone before editing.
• Test the new endpoint before switching DNS.

Think of DNS as an infrastructure map. Web, mail, and verification each have their own records; avoid broad edits when only one service is moving.

What to double-check

Before you save a DNS change or declare success, walk through these checks. This is where most troubleshooting time is won or lost.

Hostname correctness

• Are you editing example.com, www.example.com, or another subdomain?
• Does your DNS provider automatically append the domain name to relative hostnames?
• Did you accidentally create www.www.example.com by entering a full name where only the label was expected?

Record conflicts

• Do you have both an A record and CNAME on the same hostname?
• Did you leave an old MX record in place during a migration?
• Are there duplicate TXT records that confuse the intended service?

Value type

• IP address expected? Use A or AAAA, not CNAME.
• Hostname expected? Use CNAME or MX as instructed, not a raw IP.
• Text token expected? Use TXT exactly as provided.

TTL and timing

• If you changed a record recently, could cached answers still be visible?
• Did you lower TTL early enough before a migration?
• Are you testing from only one resolver that may still cache old values?

Email-specific validation

• Do MX records point to valid mail hostnames?
• Is SPF still a single coherent policy rather than multiple conflicting records?
• Are DKIM and DMARC records published on the exact names your provider expects?

Provider-specific instructions

DNS standards are stable, but control panels and managed platforms vary. Some support root-domain aliasing in a special way. Some auto-format hostnames. Some expect one TXT record per token while others can handle combined values in limited cases. When in doubt, prefer the provider's documented record shape over assumptions based on another dashboard.

Common mistakes

These are the errors that show up again and again in DNS basics, especially during rushed launches and migrations.

Using CNAME at the wrong place

The most repeated mistake in a record vs cname decisions is trying to use CNAME everywhere. CNAME is excellent for many subdomains, but it is not a universal replacement for A and AAAA records. Be especially careful at the root domain.

Publishing AAAA before IPv6 is truly ready

If your service, proxy, or firewall is not fully configured for IPv6, do not publish an AAAA record yet. Partial connectivity is harder to diagnose than a cleanly absent feature.

Changing DNS and forgetting email

Website moves often trigger accidental mail issues because teams overwrite zone files, remove TXT records they do not recognize, or replace MX records without intending to. Always separate web routing changes from mail routing changes.

Assuming verification failure means the TXT record is wrong

Sometimes the record is correct and the issue is timing, hostname placement, or resolver caching. Verify the exact record externally before changing it repeatedly.

Leaving no record ownership notes

Months later, a TXT token or odd hostname may look obsolete and get deleted. Keep brief documentation for records that support vendor verification, security policies, or business-critical routing.

Skipping cleanup after migrations

Old records can create ambiguity and future mistakes. Once a migration is complete and verified, remove unused entries with care. A tidy DNS zone is easier to maintain and safer to edit.

When to revisit

DNS is not a set-and-forget task. Revisit your records whenever the systems behind them change or when uncertainty starts to creep into the zone.

Review DNS when:

• You change hosting providers, load balancers, CDNs, or reverse proxies.
• You launch a new app, environment, or customer-facing subdomain.
• You migrate email providers or adjust email authentication.
• You add a new third-party platform that requires domain verification.
• You enable IPv6 or change network architecture.
• You inherit a domain with undocumented records.
• You are preparing for a seasonal traffic period, product launch, or other high-risk window.

Practical action checklist for your next DNS change:

1. Write down the exact goal: web routing, mail routing, or verification.
2. Identify the exact hostname involved.
3. Choose the record type based on the destination: IP, hostname, mail server, or text token.
4. Snapshot the current DNS zone before editing.
5. Lower TTL in advance if you expect to switch values soon.
6. Make the smallest change that solves the problem.
7. Verify with external lookups, then test the service itself in a browser, mail flow, or provider dashboard.
8. Document why the record exists and when it should be reviewed again.

For developers and site owners, that discipline is usually enough to avoid the most expensive DNS mistakes. DNS does not need to be mysterious. It just needs a clear record choice, careful hostname matching, and a habit of checking what changed. If you are also auditing delivery performance after a move, related guides on florence.cloud such as Lazy Loading Guide for Images, Components, and Third-Party Scripts, How to Reduce JavaScript Bundle Size, and Image Optimization for Web Performance can help you evaluate the layers above DNS once the domain is resolving correctly.