A Record vs CNAME vs MX vs TXT: DNS Records Explained for Domain Owners

Overview

If you have ever opened your registrar or DNS dashboard and seen a list of records with unfamiliar labels, you are not alone. DNS can look more complicated than it is because the record types use short names for very different jobs. The simplest way to understand them is to think of DNS as a directory for your domain.

Each record type answers a different question:

• A record: What IPv4 address should this name point to?
• CNAME record: What other hostname is this name an alias of?
• MX record: Which mail servers should receive email for this domain?
• TXT record: What text-based instructions or proof should be attached to this name?

For most domain owners, these four record types cover the majority of day-to-day tasks. You will use an A record to point a domain to a web server, a CNAME to connect a subdomain to another service, MX records to set up email delivery, and TXT records for verification, email security, and service configuration.

That makes this less of a technical trivia topic and more of an operations skill. A wrong record can take down a homepage, break email delivery, or stop a SaaS tool from verifying your domain. A correct record change, by contrast, can connect a new host or platform in a few minutes.

Before going further, keep two rules in mind:

1. Know what hostname you are editing. Changing the root domain, often shown as @, is different from changing www, mail, or another subdomain.
2. Know where DNS is actually hosted. Your domain registrar may not be the place where your DNS records are managed. If your nameservers point to another provider, that provider controls the active zone file. If you are unsure, see Nameserver vs DNS Record Changes: What to Edit and When.

How to compare options

The right DNS record is not a matter of preference. It depends on the service you are connecting and what kind of answer DNS needs to provide. When comparing A records vs CNAME records, or deciding whether an email setup needs MX and TXT records, use this checklist.

1. Start with the service type

Ask what you are trying to connect:

• Website or server: usually A record, sometimes CNAME for a subdomain
• Email receiving: MX record
• Verification or email authentication: TXT record
• Subdomain pointed at a platform: often CNAME

The provider's setup instructions usually tell you what record to create, but it helps to understand why. That way, you can spot conflicts before they cause downtime.

2. Check whether you are editing the apex or a subdomain

The apex, or root domain, is the bare domain such as example.com. A subdomain would be www.example.com or shop.example.com. This matters because many DNS setups treat the apex differently from subdomains.

In practice, CNAME records are commonly used for subdomains, while the apex often uses A records. Some DNS providers offer provider-specific flattening or alias behavior at the apex, but that is an implementation detail rather than a standard CNAME rule. If you are editing the root domain, follow your DNS provider's documented method rather than assuming every CNAME-style feature works the same way everywhere.

3. Watch for record conflicts

One of the most common mistakes is creating a record that conflicts with another record for the same hostname. For example:

• If a hostname is a CNAME, it generally should not also have other record types attached to that same name.
• MX records point to mail server hostnames, not directly to policy text or web destinations.
• TXT records can coexist with many other record types, but they should be carefully labeled and documented so they are not removed by accident.

When a service fails after a DNS update, a record conflict is often one of the first things to check.

4. Consider stability vs flexibility

An A record points directly to an IP address. That is simple and reliable when the IP is stable. A CNAME points to another hostname, which can be useful when the target service may change the underlying IPs over time. Many cloud services prefer CNAME records on subdomains for that reason.

So the practical comparison is often:

• Use A records when you control the server IP and expect it to remain stable.
• Use CNAME records when a provider tells you to alias a hostname they manage.

For email, the comparison is different. MX records control where mail goes, while TXT records often support security and verification around that mail flow. They are usually complementary rather than competing options.

5. Check TTL before making changes

TTL, or time to live, tells resolvers how long they may cache a DNS response. A shorter TTL can help changes propagate more quickly during migrations, while a longer TTL may reduce lookup volume in steady-state setups. You do not need to obsess over the perfect value for every record, but you should be aware that DNS changes are not always visible instantly.

If you are planning a website migration or mail cutover, reducing TTL in advance can make the transition easier. If you are transferring your domain to another registrar, DNS timing also matters; see How to Transfer a Domain Without Website or Email Downtime.

Feature-by-feature breakdown

Here is the practical difference between the main record types domain owners see most often.

A record explained

An A record maps a hostname to an IPv4 address. It is one of the most direct DNS instructions you can create.

Use an A record when:

• You want example.com to point to a web server
• You manage a VPS or dedicated server with a fixed IPv4 address
• Your hosting provider specifically gives you an IP to use

Strengths:

• Simple and predictable
• Works well at the root domain
• Good when you control the destination infrastructure

Limitations:

• If the server IP changes, you must update the record manually
• Less convenient than a provider-managed hostname for some cloud platforms

Example use case: You bought hosting for a company site and your host gave you a server IP. You set an A record for @ to that IP and, if needed, set www to either the same IP or to a CNAME that points to the root hostname depending on your setup.

CNAME record explained

A CNAME record makes one hostname an alias of another hostname. Instead of pointing to an IP directly, it says, in effect, “for this name, use whatever destination the target hostname resolves to.”

Use a CNAME when:

• You are connecting a subdomain to a hosted platform
• A provider gives you a target like custom.hostedservice.com
• You want the provider to manage the underlying IP changes

Strengths:

• Flexible for SaaS and cloud services
• Reduces the need to track IP changes
• Common for www, blog, shop, or campaign subdomains

Limitations:

• Usually not suitable as a standard record at the root domain in the same way as a subdomain CNAME
• Cannot usually coexist with other record types for the same hostname

Example use case: Your landing page platform asks you to point go.example.com to customer.platform.com. That is a typical CNAME setup.

When people search for a record vs cname, the most useful distinction is this: an A record points directly to an IP, while a CNAME points to another hostname. If a provider gives you a hostname target, use CNAME unless their documentation says otherwise. If they give you an IP, use an A record.

MX record explained

MX stands for mail exchange. MX records tell the internet which mail servers should accept incoming email for your domain.

Use MX records when:

• You are setting up business email for @example.com
• You are moving email from one provider to another
• You need to define primary and backup mail routing

Strengths:

• Designed specifically for inbound email routing
• Supports priority values so multiple mail servers can be ordered
• Separates email handling from your website hosting

Limitations:

• MX alone is not enough for modern email setup
• Often needs TXT records for verification and authentication

Example use case: You sign up for a hosted email service. It gives you one or more MX records with priorities. You add those records so mail for your domain is delivered to that provider.

A common mistake is assuming email follows your web hosting destination. It does not. Your website can point to one provider while your MX records point to a completely different service.

TXT record explained

A TXT record stores text data in DNS. That sounds generic, and in a way it is. TXT is used for many purposes: domain verification, email sender policies, DKIM keys, DMARC policies, ownership proofs, and service-specific instructions.

Use TXT records when:

• A provider asks you to verify domain ownership
• You need SPF, DKIM, or DMARC-style email authentication data
• You are connecting marketing, analytics, support, or security tools that validate your domain

Strengths:

• Very flexible
• Widely used for verification and policy configuration
• Essential in many email security setups

Limitations:

• Easy to clutter over time
• Can become hard to audit if multiple tools add similar-looking records

Example use case: Your email provider asks you to add one TXT record to verify the domain and additional TXT records for authentication. Your site builder may also ask for a TXT record to prove ownership before it will issue certificates or activate a custom domain.

When readers search for txt record dns, what they usually need to know is that TXT records rarely send traffic anywhere. Instead, they prove identity, declare policy, or attach configuration metadata to the domain.

Quick comparison table

Related records you may also encounter

Even if this guide focuses on the four most common types, domain owners often see a few others:

• AAAA: like an A record, but for IPv6 addresses
• NS: defines which nameservers are authoritative for the zone
• SRV: used by some services to define host and port combinations
• CAA: limits which certificate authorities may issue TLS certificates for the domain

You do not need all of these to manage a basic site, but they become relevant as your setup grows more complex.

Best fit by scenario

If you are not sure which record to use, match your task to a common scenario.

You are connecting a new website to hosting

If your hosting provider gives you a server IP, use an A record for the root domain. For www, you may use another A record or a CNAME depending on the provider's instructions. If you recently bought a domain and are sorting out hosting choices, compare DNS quality as part of your registrar decision, not just first-year price. Articles like Best Cheap Domain Registrars That Stay Affordable After Year One and Domain Registrar Renewal Pricing Comparison by Extension can help frame the broader ownership costs.

You are pointing a subdomain to a SaaS tool

Use a CNAME if the tool gives you a managed hostname target. This is common for landing pages, documentation portals, storefronts, help centers, and CDN-backed assets.

You are setting up company email

Use MX records for mail delivery and expect to add TXT records as well. In most cases, the MX records determine where mail is received, while TXT records support verification and sender trust.

You are verifying ownership for a service

Use a TXT record when a provider asks you to prove that you control the domain. This is common for search tools, analytics platforms, email platforms, and site builders.

You need both a website and email on the same domain

This is normal and does not require compromise. Your website can use A or CNAME records, while your email uses MX and TXT records. DNS is designed for different services to coexist under the same domain as long as each hostname is configured correctly.

You are troubleshooting a broken setup after a change

Check these in order:

1. Are you editing DNS at the active provider, not just at the registrar?
2. Did you create the record on the correct hostname?
3. Is there a conflicting record already present?
4. Has enough time passed for cached answers to expire?
5. Are the provider's target values copied exactly?

For teams managing many domains, document every change. Portfolio setups can get messy quickly, especially after transfers or platform migrations. If that is your environment, it is worth reviewing registrar tooling as well; Best Domain Registrars for Bulk Domain Management is a useful companion read.

When to revisit

DNS is not a one-time setup. The reason this topic deserves a bookmark is that your record mix changes whenever your stack changes. Revisit your DNS records when any of the following happens:

• You move to a new host, CDN, or website platform
• You switch email providers
• You add a new tool that requires domain verification
• You transfer your domain to a new registrar
• You change nameservers
• You retire an old service and want to clean up stale records
• You investigate deliverability, certificate, or routing issues

A practical maintenance routine looks like this:

1. Export or screenshot your existing DNS zone before major changes.
2. Label records clearly if your DNS provider supports comments or naming conventions.
3. Track which service owns each record so old entries can be removed safely later.
4. Review email-related TXT records together rather than one by one.
5. Audit after migrations to make sure old A, CNAME, MX, and TXT records are not still hanging around.

If your team depends on uptime, pair DNS changes with monitoring and logging. A configuration that looks correct in the dashboard can still fail in the real world because of propagation delays, copy errors, or stale dependencies. For operational follow-up, see Detect DNS Anomalies Before Customers Do: A Real-Time Logging and Incident Playbook.

The short version is this: use A when you need to point a name to an IP, CNAME when you need a hostname alias, MX when you need to receive email, and TXT when you need verification or policy data. That distinction will solve most DNS questions domain owners face. The rest is disciplined execution: edit the right zone, choose the right hostname, avoid conflicts, and document what changed so the next update is easier than the last.