DNS Records Explained for Website Owners: A, CNAME, MX, TXT, and More

Overview

At a basic level, DNS is the system that tells browsers, mail servers, and other services where to go when someone uses your domain. If your domain is example.com, DNS records decide whether the root domain opens your website, whether www.example.com points to the same place, which servers receive email, and how outside services confirm that you control the domain.

For most website owners, DNS management comes down to understanding a small group of 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 email where incoming mail should be delivered.
• TXT record: stores text used for verification, email authentication, and other service settings.
• NS record: defines which nameservers are authoritative for your domain.
• CAA record: limits which certificate authorities can issue SSL certificates for your domain.

If you remember one principle, make it this: DNS records are precise. Small mistakes like adding the wrong hostname, leaving an old record in place, or copying a value into the wrong field can break website access, email delivery, or both.

Here is a simple way to think about the common record types:

• Use A or AAAA when you are pointing directly to a server IP.
• Use CNAME when a provider gives you a target hostname instead of an IP.
• Use MX when setting up domain email.
• Use TXT when verifying ownership or configuring SPF, DKIM, or DMARC.
• Use NS only when changing DNS authority, usually at the registrar or zone apex level.
• Use CAA when you want tighter SSL issuance control.

Another term you will see often is TTL, or time to live. TTL controls how long resolvers may cache a record before checking for an update. Lower TTL values can help during planned changes because updates may be seen sooner, while higher values can reduce query frequency once records are stable.

If you are connecting a new domain to hosting, this guide pairs well with How to Connect a Domain to Web Hosting: Step-by-Step DNS Guide. If you are planning a broader launch, see How to Launch a Small Business Website: Complete Checklist From Domain to Go Live.

Checklist by scenario

This section gives you a reusable checklist for the most common DNS tasks website owners run into.

1. Pointing a website to hosting

Use this when launching a site on a host, moving from one host to another, or connecting a website builder to your domain.

• Confirm whether your provider wants an A record, a CNAME, or both.
• For the root domain, check whether you should point @ to an IPv4 address with an A record.
• For www, check whether the provider recommends a CNAME such as www -> target.hostingplatform.com.
• Remove outdated A or CNAME records that conflict with the new destination.
• Make sure you are editing the active DNS zone, not an old DNS provider you no longer use.
• Lower TTL before a planned migration if you want faster propagation during the cutover.
• After changes, test both example.com and www.example.com.

A record vs CNAME is one of the most common points of confusion. In simple terms, an A record points directly to an IP address. A CNAME points one hostname to another hostname. If your host gives you an IP, use an A record. If your host gives you a target name, use a CNAME where allowed.

One practical note: the root domain often has stricter rules than subdomains. Many DNS setups allow a CNAME for www but not for the zone apex, which is the bare domain. If your provider expects the root domain to work, follow its exact instructions rather than assuming the same record pattern works everywhere.

2. Setting up business email

Use this when connecting your domain to an email provider.

• Add the required MX records exactly as provided by the email service.
• Check the priority value on each MX record. Lower numbers generally mean higher priority.
• Add any required TXT records for SPF, domain verification, or other provider-specific settings.
• If the email provider includes DKIM records, add them exactly, often as CNAME or TXT records on selector subdomains.
• Add a DMARC TXT record if you want reporting and policy control for domain email.
• Remove old MX records if you are fully switching providers and no longer using the previous service.
• Send a test email in and out after propagation.

MX record setup is usually straightforward, but errors matter. A missing priority, an extra old MX entry, or leaving mail pointed to a former host can lead to split or failed delivery. For website owners, the safest approach is to treat email DNS as a complete set: add everything the new provider requires, then review whether legacy mail records should remain.

If you also need branded inboxes, planning, and setup context, a broader domain and email workflow guide can help alongside this DNS reference, especially if you are handling a launch for a service business or freelance brand.

3. Verifying a domain with a third-party service

Many platforms ask you to prove ownership before they activate a product, connect analytics, or issue sending permissions.

• Look for the exact TXT record verification value provided.
• Copy the host/name field exactly as shown. Some systems want @; others want a specific subdomain.
• Do not add extra quotation marks unless your DNS provider expects them automatically.
• Keep existing TXT records unless the provider specifically says to replace them.
• Wait for propagation, then trigger verification again from the service dashboard.

TXT records are flexible, which is useful, but also easy to mishandle. A domain can have multiple TXT records. That is normal. Problems usually come from putting the value on the wrong host, trimming part of a long key, or pasting the text into the hostname field instead of the value field.

4. Connecting subdomains

Use this when setting up blog.example.com, shop.example.com, app.example.com, or a staging environment.

• Decide whether the subdomain should point to an IP with an A record or to a provider hostname with a CNAME.
• Create the record only for the specific subdomain, not the root domain.
• Check whether the service also needs SSL validation or a separate verification TXT record.
• If the subdomain will be customer-facing, test redirects, canonical behavior, and SSL after DNS resolves.

Subdomains are often safer to change than root records because they do not usually affect the main site or email. That makes them useful for testing services before rolling out broader DNS changes.

5. Migrating a website without downtime surprises

DNS changes often happen during hosting moves. If you are migrating to faster or more managed infrastructure, the DNS plan should be part of the migration plan.

• Audit current records before changing anything.
• Save screenshots or export the zone if your DNS provider supports it.
• Lower TTL in advance if you control the current DNS zone.
• Confirm the new host is fully ready before switching records.
• Keep email records intact unless you are intentionally migrating email too.
• Check SSL issuance after the new records resolve.
• Monitor the site from multiple networks if possible.

If you are evaluating platforms as part of a migration, see Best Website Platforms for Service Businesses Compared and Best Hosting for SEO: What Matters for Rankings, Speed, and Uptime.

6. Tightening SSL and certificate control

Not every small site needs this immediately, but it is useful to understand.

• Add a CAA record if you want to specify which certificate authorities may issue SSL certificates for your domain.
• Check whether your host or CDN uses a particular certificate authority before restricting issuance.
• Review wildcard and subdomain needs before finalizing the record.

CAA records are a control layer, not a traffic routing layer. They do not point visitors anywhere. They simply help define who can issue certificates.

What to double-check

Before you save any DNS change, run through this short review. It prevents most avoidable issues.

• Are you in the right DNS provider? If your nameservers point elsewhere, changes at the registrar may do nothing.
• Are you editing the right hostname? Root, www, and subdomains are separate records.
• Is the record type correct? An A record value should be an IP. A CNAME value should be a hostname.
• Is there a conflicting record already present? A stale record can override or confuse the intended setup.
• Did you preserve unrelated records? Website changes should not accidentally remove MX or TXT records needed for email.
• Is the TTL appropriate? Use lower values during planned changes and more stable values later if desired.
• Did you follow provider formatting exactly? Especially important for DKIM, verification tokens, and CNAME targets.

It also helps to know what not to touch. Nameserver changes are larger than normal record edits because they move authority for the whole zone. If a host asks you to update nameservers, pause and review the implications. A nameserver change can disconnect website, email, and verification records if the new DNS zone is incomplete.

For readers comparing launch options, the cost and maintenance side of hosting may matter just as much as DNS simplicity. Related guides include Website Hosting Pricing Comparison: What Small Businesses Actually Pay and Web Hosting Pricing Comparison 2026: Entry, Renewal, SSL, Backups, and Migration Fees.

Common mistakes

Most DNS problems are not complicated. They are small copy-and-paste or planning errors with outsized effects.

Changing nameservers when a simple record edit would do

Many providers offer two methods: change nameservers to let them manage DNS, or keep your current DNS provider and add specific records. Both can work, but they are not equivalent. If you switch nameservers without recreating your full zone, you can break web, email, and other services at once.

Confusing the root domain with www

example.com and www.example.com often require separate records. Configuring one does not automatically configure the other.

Leaving old MX records active

When moving email providers, leftover MX records can cause inconsistent delivery. Review all mail-related records as a group, not one by one in isolation.

Overwriting existing TXT records

A domain can have multiple TXT records. Replacing an SPF, verification token, or DMARC record without understanding its purpose can cause side effects. Add carefully and document what each TXT entry is for.

Ignoring propagation and caching

DNS updates are not always visible everywhere immediately. Check whether the change has propagated before assuming the record is wrong. A low TTL can help for planned changes, but cached results may still linger for some users or networks.

Using the wrong value format

Some DNS systems automatically append the domain name; others expect a fully qualified target. Some accept a trailing dot and some hide it. Follow the instructions from your DNS provider and service provider together, especially for CNAME, MX, and TXT entries.

Making several major changes at once

If you switch hosting, nameservers, email, and CDN settings in one session, troubleshooting gets harder. Change one layer at a time when possible, then confirm it works before moving on.

If your site is new, also review Website Builder SEO Checklist for New Sites so your DNS setup and launch tasks support discoverability from day one. Freelancers building personal or client-facing sites may also find How to Build a Freelance Portfolio Website That Wins Clients useful once the domain side is handled.

When to revisit

DNS is not a one-time task. Revisit your records whenever the underlying services or workflows change. A short review at the right moment prevents avoidable outages and verification failures.

Revisit DNS before:

• Launching a new website or redesign
• Migrating to a new hosting platform
• Switching email providers
• Adding a CDN, security layer, or third-party app
• Creating new subdomains for shop, blog, app, staging, or regional sites
• Renewing security practices for SSL and email authentication
• Seasonal planning cycles when you expect higher traffic or team changes

Revisit DNS after:

• Any service dashboard says verification failed
• Email deliverability changes unexpectedly
• SSL does not issue or renew as expected
• Your registrar, host, or DNS provider changes interface or workflow
• You inherit a domain with unknown past settings

Use this practical maintenance routine:

1. Export or document your current zone.
2. Label each important record by purpose: website, www, email, verification, SSL, subdomains.
3. Remove entries you are certain are obsolete.
4. Keep a note of which provider owns each critical service.
5. Test the website, email, and key subdomains after any update.

If you want a simple working habit, make a DNS review part of every launch checklist and every hosting or email change request. DNS records do not need daily attention, but they do reward careful review whenever something connected to your domain changes.

As a final rule of thumb: if a provider gives you DNS instructions, do not just paste the values. First identify what the record is for, what hostname it affects, and whether it conflicts with an existing record. That small pause is often the difference between a clean launch and an avoidable support ticket.