DNS Record Guide: A, AAAA, CNAME, MX, TXT, SRV, and When to Use Each

Overview

At a practical level, DNS records tell the internet where a service lives and how requests should be handled. A browser loading your site, a mail server delivering to your inbox, and a SaaS platform verifying domain ownership all depend on the right record being present in the right place.

The challenge is not usually understanding one record in isolation. It is understanding the tradeoffs between record types, where they can be placed, and what breaks when you use the wrong one. That is why a checklist approach works well: before adding or editing a record, confirm the goal, the hostname, the expected value, and whether other records already exist at that name.

Here is the short version of the main DNS record types covered in this guide:

• A record: points a hostname to an IPv4 address.
• AAAA record: points a hostname to an IPv6 address.
• CNAME record: makes one hostname an alias of another hostname.
• MX record: tells mail senders which servers receive mail for your domain.
• TXT record: stores text-based data used for verification, email authentication, and policy signals.
• SRV record: identifies a service, protocol, target host, and port for specific applications.

Before going deeper, keep three DNS rules in mind:

1. Hostnames matter. A record at the root domain is different from one at www, mail, or api.
2. Some record types cannot coexist at the same name. Most notably, a CNAME generally should not exist alongside other records on the same hostname.
3. DNS changes are not always instant. Time to Live, caching, and provider behavior all affect propagation. Plan changes accordingly, especially for email and migrations.

If you are connecting a newly registered domain to a hosting account, pair this article with How to Connect a Domain to Web Hosting: Nameservers, DNS Records, and Verification Steps. If you are evaluating providers instead of changing records manually, see Best DNS Hosting Providers Compared for Speed, Uptime, DNSSEC, and API Access.

A record: when you need a hostname to resolve to IPv4

An A record maps a name such as example.com or app.example.com to an IPv4 address like 203.0.113.10. It is one of the most common records for websites, APIs, and self-managed infrastructure.

Use an A record when:

• You have a fixed IPv4 address for a web server or load balancer.
• Your hosting provider specifically tells you to point the domain to an IP.
• You are setting the root domain and cannot use a standard CNAME there under your DNS provider's rules.

Watch for: IP changes during migrations, firewall restrictions, and the need to add multiple A records if you are distributing traffic across more than one endpoint.

AAAA record: the IPv6 equivalent

An AAAA record works like an A record, but for IPv6. If your provider supports IPv6, this record lets resolvers reach the service over newer address space.

Use an AAAA record when:

• Your infrastructure has a stable IPv6 address.
• You want dual-stack support alongside IPv4.
• Your provider documents IPv6 connectivity for the hostname.

Watch for: partial deployments. If IPv6 is published but not fully routed or filtered correctly, some visitors may hit failures that are hard to reproduce.

CNAME record: when one hostname should follow another

A CNAME makes one hostname an alias of another hostname. For example, www.example.com may point to site.hostingplatform.net.

Use a CNAME when:

• A SaaS or hosting platform gives you a target hostname rather than an IP.
• You want one subdomain to inherit the resolution of another name.
• You prefer to avoid hardcoding an IP that may change behind the scenes.

Watch for: CNAME limitations. A CNAME usually should not be used on the same name as MX, TXT, A, or AAAA records. It also often cannot be placed at the zone apex unless your DNS host provides a special flattening or alias feature.

MX record: where mail for the domain should be delivered

MX records tell other mail systems which servers accept inbound mail for your domain. They use priorities, so lower values are typically preferred over higher ones.

Use MX records when:

• You want to receive email at addresses such as user@example.com.
• You are moving from one email host to another.
• You are setting up a primary and backup mail path.

Watch for: MX records point to hostnames, not IPs in normal practice. Those hostnames should resolve correctly with A or AAAA records. Also remember that changing MX without updating related TXT records for authentication can create delivery issues.

TXT record: verification and email policy workhorse

TXT records are flexible and widely used. In modern DNS operations, they often carry domain verification strings, SPF policy data, and keys or policy markers used by email systems and third-party platforms.

Use TXT records when:

• A service asks you to verify ownership of a domain or subdomain.
• You need to publish SPF policy or other mail-related text values.
• You are enabling integrations that rely on signed or policy-based DNS lookups.

Watch for: exact formatting. Extra spaces, missing quotes in some control panels, duplicate SPF-style policies, and publishing a TXT at the wrong hostname are all common causes of failed verification.

SRV record: service discovery for specific protocols

SRV records are less common for basic websites but very useful for applications that need to advertise both a target host and a port. They are often used by communication platforms, directory services, and other protocol-driven systems.

Use an SRV record when:

• A vendor gives you a service name, protocol, priority, weight, port, and target.
• You are configuring software that performs service discovery through DNS.
• You need clients to find the right host and port automatically.

Watch for: naming conventions. SRV records usually include a service and protocol prefix such as _service._tcp. A small typo in the service label or port value can make the record useless.

Checklist by scenario

Use this section before making changes. Start with the outcome you want, then confirm the record type, name, value, and dependencies.

Scenario 1: Pointing a website to a server

• Identify whether the provider gave you an IP address or a target hostname.
• If you received an IPv4 address, use an A record.
• If you received an IPv6 address, use an AAAA record.
• If you received a platform hostname such as customer.host.net, use a CNAME for a subdomain like www.
• Confirm whether the root domain also needs to resolve. If so, check whether your DNS host supports apex aliasing or whether you need A/AAAA records instead.
• Decide whether both example.com and www.example.com should work, and document which one is canonical at the application level.
• Set a sensible TTL before major changes if you expect to adjust records again during a migration.

For a broader launch workflow, see Website Launch Checklist: Domain, Hosting, DNS, SSL, Email, and Backups.

Scenario 2: Setting up email for the domain

• Add the provider's MX records exactly as supplied, including priorities.
• Verify that the MX targets themselves resolve correctly.
• Add required TXT records for verification and email policy.
• Check whether the provider expects a hostname like mail.example.com to exist with A or AAAA records.
• Review old MX records and remove them only when the cutover is intentional.
• Test both inbound and outbound delivery after changes propagate.

If you are still choosing a provider, Best Email Hosting for Custom Domains: Workspace, Microsoft 365, Zoho, and Alternatives can help frame the decision.

Scenario 3: Verifying a domain with a SaaS platform

• Confirm whether the service wants a TXT record or a CNAME.
• Copy the hostname exactly; some providers want the root, others a prefixed label.
• Check whether your DNS panel automatically appends the zone name to the host field.
• Make sure there is no conflicting CNAME if the hostname already has other records.
• Wait for propagation, then run the service's verification check again.

Scenario 4: Moving web hosting without changing the domain registrar

• Lower TTL in advance if your DNS provider allows it and if the move is scheduled.
• Decide whether you will update A/AAAA records or repoint a CNAME.
• Keep email-related records unchanged unless the email service is moving too.
• Verify SSL coverage on the new environment before switching traffic.
• After cutover, test the site, redirects, forms, APIs, and any CDN behavior.

For a full cutover plan, read Website Migration Checklist: Moving Hosts Without Downtime or SEO Loss.

Scenario 5: Publishing a service that needs a custom port or protocol

• Confirm whether the application uses SRV records.
• Collect the service label, protocol, priority, weight, port, and target hostname.
• Ensure the target hostname resolves with A or AAAA records.
• Validate firewall and listening-port configuration on the target service.
• Test with a client that actually performs SRV lookups, because not all applications do.

Scenario 6: Running dual-stack IPv4 and IPv6

• Publish an A record and an AAAA record only if both paths are production-ready.
• Test reachability over IPv6 from more than one network.
• Confirm that SSL, redirects, and origin firewall rules behave identically over both protocols.
• If issues appear only for some users, temporarily removing a broken AAAA record is often safer than leaving partial IPv6 support in place.

What to double-check

Before saving a DNS change, pause and verify these details. Most DNS incidents come from small mismatches, not from obscure protocol failures.

• The exact hostname: Are you editing the root domain, www, mail, or another label?
• The record type: Did the provider ask for A, AAAA, CNAME, MX, TXT, or SRV specifically?
• The value format: IP address, hostname, text string, priority, and port values must match the requirement exactly.
• Conflicts on the same name: A hostname that uses a CNAME generally should not also have A, AAAA, MX, or TXT records.
• TTL: Shorter TTLs can help during migrations; longer TTLs can reduce query volume once the setup is stable.
• Email dependencies: MX changes often need related TXT updates for authentication and verification.
• Root vs subdomain behavior: Many teams accidentally configure www and forget the apex domain, or vice versa.
• Provider panel behavior: Some DNS UIs want a full hostname; others want only the relative label.
• Existing records: Do not overwrite working records for unrelated services such as email, VPN, or staging.

After changes are live, test from the user side, not just from the DNS panel. Load the website in a browser, send a real email, complete the verification step, or connect with the actual client application. If you are checking a new HTTPS endpoint, SSL Certificate Setup Guide: DV vs OV vs EV, Renewal, and Common Errors is a useful companion reference.

Common mistakes

If DNS feels fragile, it is usually because small errors can have large effects. These are the mistakes worth watching for most closely.

Using a CNAME at the wrong place

The classic example is trying to use a standard CNAME at the root domain while also needing other records there. Some DNS hosts offer special apex alias features, but a plain CNAME at the apex is often not the right answer. When in doubt, check provider documentation and your DNS host's capabilities before changing the root.

Breaking email while updating web records

Website and email DNS are related only because they share the same zone. They often use different records entirely. A web hosting migration may require A or CNAME changes, but your MX and TXT records for mail may need to remain untouched.

Publishing incomplete IPv6 support

Adding AAAA records without end-to-end testing can produce intermittent failures that affect only certain users or networks. If IPv6 is not truly ready, do not advertise it yet.

Copying TXT values incorrectly

TXT-based verification fails when values are truncated, pasted into the wrong label, duplicated unnecessarily, or altered by a control panel's formatting rules. Treat these entries as exact strings.

Ignoring propagation and cache behavior

DNS changes may appear updated in one resolver but not another. That does not always mean the change is wrong. Check the authoritative zone, compare results from multiple resolvers, and give caches time to expire before concluding that a configuration failed.

Changing too much at once

During a launch or migration, it is tempting to update nameservers, web records, mail records, and SSL all in one window. That can make troubleshooting harder. If possible, stage changes in a sequence you can verify: DNS, application reachability, HTTPS, then email-related validation.

If you are evaluating hosting before making DNS changes, these comparisons may help narrow the infrastructure decision: Best Web Hosting for Small Business: Uptime, Support, Email, and Total Cost Compared, Shared Hosting vs VPS vs Cloud Hosting: Which Option Fits Your Website in 2026?, and Managed WordPress Hosting Comparison: Performance, Staging, Backups, and Limits.

When to revisit

DNS is not a one-time task. Revisit your records whenever the underlying service changes, before planned migrations, and during routine maintenance windows. A short review at the right time is often enough to prevent downtime or mail disruption.

Use this practical review checklist:

• Before a website launch: Confirm A, AAAA, or CNAME targets; make sure both root and www behave as intended; verify SSL readiness.
• Before changing hosts: Review current records, lower TTL if appropriate, and document rollback values.
• Before switching email providers: Inventory existing MX and TXT records so you do not lose working mail settings during the cutover.
• When adding a new SaaS service: Check whether the requested verification record conflicts with existing records on the same hostname.
• During seasonal planning or major deployments: Audit whether old records still point to active systems, especially staging, legacy mail gateways, and retired third-party tools.
• After team or workflow changes: Reconfirm who controls DNS, where the authoritative zone is hosted, and whether changes are documented.

A good operating habit is to keep a simple DNS inventory with four columns: hostname, record type, current value, and business purpose. That makes future decisions much faster. It also reduces the risk of removing a record that still supports email, verification, or an internal service.

Finally, treat DNS edits like infrastructure changes, not like copy edits. Save a snapshot of the current zone, make one logical change at a time, and validate the result from the perspective of the service you are trying to support. If you do that consistently, A, AAAA, CNAME, MX, TXT, and SRV records stop feeling mysterious and start functioning as the reliable routing layer they are meant to be.

For a practical next step, bookmark this guide alongside How to Connect a Domain to Web Hosting and your own DNS inventory. That combination is usually enough to handle most launch, troubleshooting, and migration tasks without guesswork.