DNS Records Explained: A Beginner Guide to A, CNAME, MX, TXT, and Nameservers

Overview

At a practical level, DNS is the system that tells the internet where your domain should send traffic. When someone visits your site, sends you an email, or a service checks your domain for verification, DNS records provide the instructions.

For beginners, the hard part is not usually adding a record. It is understanding which record type belongs to which job, where to edit it, and how to avoid conflicts. The challenge grows over time because DNS setups are rarely static. You may change hosting, move email to another provider, add a CDN, launch a subdomain, or connect a form tool that asks for a TXT record. That is why DNS works well as a living reference: the fundamentals stay the same, but your specific record set changes as your site grows.

Here is the simplest way to think about the record types in this article:

• A record: points a domain or subdomain to an IPv4 address.
• CNAME: points one hostname to another hostname.
• MX record: tells email systems where to deliver mail for your domain.
• TXT record: stores text-based instructions often used for verification, email authentication, and policy.
• Nameservers: decide which DNS provider is authoritative for your domain’s zone.

If you only remember one principle, make it this: nameservers decide where DNS is managed, and the individual records decide how services behave. Many DNS problems happen because a user edits records in one dashboard while the domain is actually using nameservers from another provider.

This distinction matters whether you registered your domain separately, bought hosting elsewhere, or are using a website builder. If you need a broader refresher on domain choices before editing anything, it helps to review How to Choose a Domain Name for Your Business or Blog and Best Domain Registrars Compared: Pricing, Renewal Fees, and Free Extras.

Before we go deeper, here is a quick plain-English example. Suppose your website is hosted with one company, your email is handled by another, and a third service verifies your domain for sending newsletters. You might have:

• An A record for example.com pointing to your web server IP
• A CNAME for www.example.com pointing to the main domain or host target
• MX records for your email provider
• TXT records for SPF, DKIM, or domain verification
• Nameservers set to the provider where all these DNS records are managed

Nothing about that setup is unusual. In fact, it is typical. The important part is keeping it organized and reviewing it whenever infrastructure changes.

What to track

This section gives you a practical checklist. If you treat DNS as something to monitor instead of something you touch once and forget, you will avoid many preventable outages.

A records

An A record maps a hostname to an IPv4 address. In most small business or creator setups, the root domain—sometimes written as @ in DNS dashboards—uses an A record to point to a hosting server.

Track these details:

• The hostname being pointed, such as @, blog, or shop
• The destination IP address
• Whether a matching www record is also configured
• TTL, if your provider exposes it

Watch for common issues:

• Old IP addresses left behind after a hosting migration
• Conflicting A records for the same hostname
• Forgetting to update the root domain while only updating www

If you are comparing hosting environments before making DNS changes, see Shared Hosting vs Managed WordPress Hosting: Which Should You Choose? and Best Web Hosting for Beginners: Plans, Pricing, and Features Compared.

CNAME records

A CNAME creates an alias from one hostname to another hostname. This is common for www, app subdomains, or third-party platforms that want you to point pages.example.com to a service-managed target.

Track these details:

• The alias hostname, such as www or app
• The target hostname it points to
• Whether the hostname also has another record type assigned

Watch for common issues:

• Creating a CNAME where an A record already exists for the same hostname
• Using a CNAME at the root domain when your provider does not support that pattern
• Pointing a CNAME to an outdated onboarding target from an old SaaS tool

The short version of the A record vs CNAME question is this: use an A record when you need to point directly to an IP address, and use a CNAME when you need one hostname to follow another hostname.

MX records

MX records control incoming email delivery. If you use business email setup with domain-based addresses like hello@yourdomain.com, your MX records must match your email provider’s instructions exactly.

Track these details:

• Each MX server hostname
• Priority values
• Whether old MX records from a previous provider still exist
• Whether email authentication TXT records were added alongside MX

Watch for common issues:

• Mixed MX records from two different email providers
• Wrong priority order
• Email working on one device but failing broadly because DNS is only partially updated

MX record setup often fails not because the MX values are difficult, but because users forget the supporting TXT records used for authentication and verification.

TXT records

TXT records are flexible and widely used. They commonly power domain verification, SPF, DKIM, DMARC, and service-specific ownership checks.

Track these details:

• The hostname or name field, such as @ or a provider-specific selector
• The exact text value
• What service the record belongs to
• Whether it is temporary verification or a long-term requirement

Watch for common issues:

• Accidentally replacing an existing SPF record instead of merging valid mechanisms where appropriate
• Leaving obsolete verification TXT records that create clutter
• Copying values with missing characters, quotation changes, or line-break problems

TXT record DNS changes deserve extra care because one domain can collect many of them over time. If you do not label them somewhere outside the DNS dashboard, it becomes hard to remember which service each one supports.

Nameservers

Nameservers determine who is authoritative for your DNS. If your registrar says the domain uses your host’s nameservers, then DNS edits generally need to happen in the host’s DNS zone, not at the registrar. This is why nameservers explained is really about control: they answer the question, “Which system should I trust as the source of truth?”

Track these details:

• The current nameserver set at the registrar
• Which provider owns those nameservers
• Whether DNSSEC or related security features are tied to that setup
• When nameservers last changed

Watch for common issues:

• Editing DNS in the wrong place
• Changing nameservers without recreating all required records first
• Moving the website successfully but breaking email because MX and TXT records were not copied over

This is especially common during site launches, hosting changes, or domain transfers. If you are also deciding between builder-based and hosting-based setups, Best Website Builders for Beginners Compared can help you understand where DNS responsibilities tend to sit.

Your personal DNS inventory

The most useful thing to track is not just the records themselves, but a simple inventory. Keep a document or spreadsheet with:

• Hostname
• Record type
• Value
• Purpose
• Provider or service owner
• Date added or changed
• Whether removal would break something

This turns DNS from a memory test into a maintainable system.

Cadence and checkpoints

DNS does not need daily attention, but it does benefit from a repeatable review cadence. A monthly or quarterly check is usually enough for small sites, especially if multiple services are connected to the same domain.

Monthly quick check

Once a month, spend five to ten minutes reviewing the essentials:

• Does the domain resolve to the correct website?
• Does www behave the way you expect?
• Can you send and receive business email?
• Have any recent tools or services asked you to add verification records?
• Do your nameservers still point to the intended provider?

This quick pass catches silent drift—small changes that nobody documents and everyone forgets.

Quarterly deeper review

Every quarter, do a more complete DNS audit:

• Compare live records against your DNS inventory
• Remove obsolete records that are clearly no longer needed
• Confirm that MX, SPF, DKIM, and related email settings still match your current provider
• Review subdomains created for campaigns, tools, or staging environments
• Check whether a recent hosting move changed your expected A record targets

This is also a good time to review broader infrastructure decisions, especially if your site has outgrown its original setup.

Before any major change

Always check DNS before:

• Migrating hosting
• Connecting a new website builder or landing page tool
• Changing email providers
• Transferring a domain to another registrar
• Launching a new subdomain for an app, store, or portal

Take a full snapshot first. Even a plain copy-and-paste export of current records is better than relying on memory.

After any major change

After an update, verify:

• Website loads on the root domain and www
• Email still sends and receives correctly
• SSL issuance or renewal is still working if your host manages it
• Third-party services that depend on TXT or CNAME verification still show connected status

DNS changes can take time to propagate, so avoid stacking multiple unrelated edits unless necessary. Make one clear change set, document it, then test.

How to interpret changes

Not every DNS difference is a problem. The key is knowing which changes are expected and which ones suggest risk.

When a change is probably normal

• Your host gives you a new IP after a planned migration and you update the A record intentionally
• A service asks you to add a verification TXT record for a new integration
• You move DNS management to a new provider and update nameservers as part of a planned transfer

These are expected changes, provided they are documented and tested.

When a change deserves a closer look

• An A record points to an unfamiliar IP and nobody on your team knows why
• Your MX records include servers from more than one provider without a deliberate migration plan
• A CNAME target references a service you no longer use
• Nameservers change unexpectedly after a registrar or account update
• You have duplicate or conflicting TXT records related to email policy

In practical terms, DNS problems often reveal themselves through symptoms rather than obvious errors in the dashboard. A site may load inconsistently, email may fail only for some recipients, or a service may report that domain verification is missing even though you remember adding a record months ago.

That is why context matters. Interpreting DNS changes is easier when you track the service relationship behind each record. If you see a TXT entry and know it belongs to your newsletter platform, you can decide whether it should stay. If you do not know what it does, removal becomes risky.

A simple interpretation framework

When reviewing any DNS record, ask four questions:

1. What service does this support?
2. Is that service still active?
3. Does the record match the provider’s current documented format?
4. Would deleting or changing it affect web traffic, email, or verification?

If you cannot answer those questions, mark the record for investigation rather than changing it immediately.

For WordPress users, DNS interpretation matters during migrations and performance work too. A site issue that looks like WordPress trouble may actually be a DNS mismatch after moving environments. That is one reason hosting and DNS should be reviewed together, not in isolation.

When to revisit

The practical rule is simple: revisit DNS on a schedule, and also revisit it every time your stack changes. You do not need to obsess over it, but you do need a repeatable habit.

Revisit this topic monthly or quarterly if:

• Your site supports a business, portfolio, or lead generation workflow
• You use custom email on your domain
• You connect multiple services like forms, newsletters, booking tools, or CDNs
• You manage domains for more than one project

Revisit immediately if:

• You change hosting or server IPs
• You change nameservers
• You transfer the domain to another registrar
• You switch email platforms
• You add or remove important subdomains
• A service asks you to verify domain ownership again
• Your site or email stops working after what seemed like a minor dashboard change

To make this article useful as a recurring checkpoint, end each DNS session with a short action list:

1. Confirm where DNS is actually managed by checking nameservers.
2. Export or copy your current records before editing anything.
3. Review A, CNAME, MX, and TXT records against your current providers.
4. Label each record in your own inventory with its purpose.
5. Test website and email after every change.
6. Set a calendar reminder for the next monthly or quarterly review.

If you do that consistently, DNS becomes much less intimidating. You stop treating it like hidden infrastructure and start treating it like a maintainable part of your website system.

For most site owners, that is the real goal of learning DNS records explained: not memorizing every technical edge case, but knowing enough to make safe changes, ask better questions, and keep your domain, website, and email aligned over time.