DNS Records Cheat Sheet: A, AAAA, CNAME, MX, TXT, SRV, and NS

Overview

If you manage a domain and hosting setup, DNS is the layer that tells the internet where requests should go. It maps your domain name to the correct web server, mail provider, verification service, or application endpoint. That sounds abstract until you are in a registrar dashboard trying to connect a domain to web hosting, point email to Microsoft 365, verify a sender service, or move a site without downtime.

The most useful way to think about DNS is as a zone file made of instructions. Each record answers a different question:

• A: what IPv4 address should this hostname use?
• AAAA: what IPv6 address should this hostname use?
• CNAME: which other hostname is this alias pointing to?
• MX: which mail servers receive email for this domain?
• TXT: what text-based metadata or verification token should be published?
• SRV: which service is available on which host and port?
• NS: which name servers are authoritative for this zone?

A few evergreen rules matter more than provider-specific screenshots:

1. Edit DNS at the provider that hosts your DNS zone, which may be your registrar or a separate DNS hosting provider.
2. Know the difference between the root domain and a subdomain. The root is usually shown as @. A subdomain might be www, blog, or shop.
3. Plan for propagation. Some changes appear quickly, but global resolution can take time depending on TTL and caching.
4. Record the old values before you change anything.
5. When using a service like Microsoft 365, domain ownership often needs to be verified first, usually with a TXT record. Microsoft also notes that some registrars support Domain Connect, which can automate verification and record setup; otherwise, you add records manually at your registrar or DNS host.

If you want a more beginner-focused walkthrough for domain and hosting changes, see How to Connect a Domain to Web Hosting: DNS Records Explained for Beginners.

DNS records cheat sheet

Use this as a quick lookup table before you edit.

A record explained

An A record points a hostname to an IPv4 address. This is one of the most common DNS records in web hosting. If your root domain should load a website from a server with an IPv4 address, you usually use an A record.

Typical use: Point @ to your web server IP.

Good fit for: Root domains, direct server hosting, static server endpoints.

Watch for: If your hosting provider changes IP addresses during a migration, the old A record will keep traffic going to the old server until updated.

AAAA record explained

An AAAA record does the same job as an A record, but for IPv6. Not every project needs it, but many modern hosts support IPv6.

Typical use: Publish IPv6 access for a hostname already served over IPv6.

Good fit for: Dual-stack environments that support both IPv4 and IPv6.

Watch for: Do not publish an AAAA record unless the destination actually serves your site correctly over IPv6.

CNAME record explained

A CNAME maps one hostname to another hostname. It does not point directly to an IP. This makes it useful when a provider wants you to point a subdomain to a managed service endpoint that may change behind the scenes.

Typical use: Point www to another hostname, or connect a subdomain to a SaaS platform.

Good fit for: CDN endpoints, hosted shops, landing page tools, managed services.

Watch for: A CNAME usually should not coexist with other record types on the same exact hostname. Also, the root domain often cannot be a plain CNAME at many DNS providers, though some providers offer flattening or alias features that behave similarly.

MX record explained

MX records control where inbound email for your domain is delivered. They do not send email by themselves; they tell other mail servers which destination hosts should accept mail for your domain.

Typical use: Point your domain's email to Microsoft 365, Google Workspace, or another mail provider.

Good fit for: Any business using email on a custom domain.

Watch for: MX records include priorities. Lower numbers are generally tried first. If you switch email providers, remove obsolete MX records once the new setup is confirmed, or mail flow can become inconsistent.

TXT record explained

TXT records carry text values used for verification, email authentication, and service policies. They are among the most overloaded record types in DNS.

Typical use: Domain ownership verification, SPF, DKIM-related publishing, DMARC, and third-party service verification.

Good fit for: Email security, admin verification, analytics and platform setup.

Watch for: Long TXT values are easy to paste incorrectly. Also avoid publishing multiple conflicting SPF policies.

SRV record explained

SRV records specify the location of a service by naming the host and port that provide it. They are less common for basic website launches but still important for some communications and directory tools.

Typical use: Services that need protocol, priority, weight, port, and target host details.

Good fit for: Voice, messaging, federation, directory and application service discovery.

Watch for: The naming format is stricter than other record types, so copy provider values carefully.

NS record explained

NS records identify which name servers are authoritative for a domain or delegated subdomain. These records matter at the highest level because they determine where DNS is managed.

Typical use: Point your domain to a DNS provider, or delegate a subdomain to a separate DNS zone.

Good fit for: Changing DNS hosts, advanced infrastructure, separating environments.

Watch for: Changing NS records can shift control of your whole zone. This is not a routine edit like changing an A record. Treat it as an infrastructure change.

Checklist by scenario

Most DNS edits happen for a reason, not in isolation. Use the scenario checklists below before you save changes.

Scenario 1: Point a website to a hosting server

• Confirm whether the host expects an A record, an AAAA record, a CNAME, or a combination.
• Check whether you are editing the root domain or www.
• If the provider gave you an IP address, use A or AAAA as instructed.
• If the provider gave you a hostname, use a CNAME where appropriate.
• Lower the TTL before a planned migration if you want faster rollback options.
• Keep the previous record values until the new site is confirmed.
• Verify that SSL certificate setup is complete after DNS resolves to the new host.

Related reading: Best Web Hosting for Small Business Websites 2026 and Best WordPress Hosting for Blogs, Portfolios, and Business Sites 2026.

Scenario 2: Connect custom domain email

• Add the provider's MX records exactly as supplied.
• Complete ownership verification, often with a TXT record.
• Add or review SPF, DKIM, and DMARC-related TXT records as recommended by your email provider.
• Remove old MX entries after confirming the new provider is active.
• Test both inbound and outbound email from multiple addresses.
• If using Microsoft 365, check whether your registrar supports Domain Connect; if not, add records manually where your DNS is hosted.

For a deeper email setup walkthrough, see How to Set Up Custom Domain Email for Your Business.

Scenario 3: Set up www and non-www correctly

• Choose your preferred canonical version: example.com or www.example.com.
• Point the root domain with A/AAAA or provider-supported aliasing.
• Point www with a CNAME if your host recommends it.
• Set a redirect at the web server, application, or CDN layer so visitors always land on one version.
• Confirm that your SSL certificate covers both hostnames.

Scenario 4: Verify a domain for a SaaS tool

• Read the provider instructions closely; most use a TXT or CNAME record.
• Enter the exact host label. Some dashboards want only the prefix, not the full domain.
• Do not delete the verification record immediately after success unless the provider explicitly says it is temporary.
• Document why the record exists so future cleanup does not break the integration.

Scenario 5: Migrate DNS or move to a new registrar

• Remember that domain registration and DNS hosting are related but not always the same thing.
• Export or copy your full zone before making changes.
• Recreate all needed records at the new DNS host before switching NS records.
• Compare old and new zone files line by line.
• Only change NS records when you are sure the new zone is complete.
• Check website, email, verification records, and subdomains after the cutover.

If you are evaluating providers before a move, see Best Domain Registrars Compared 2026: Pricing, Renewal Costs, Privacy, and Transfer Policies.

Scenario 6: Delegate a subdomain to another team or service

• Use NS records for subdomain delegation when separate DNS control is needed.
• Make sure both parties agree on the delegated zone name.
• Document who owns ongoing maintenance.
• Test only the delegated subdomain, not just the parent domain.

What to double-check

DNS changes fail less often because of complexity than because of small mismatches. Before saving any record, review these items.

1. Are you editing the right DNS host?

Your domain registrar may also host your DNS, but not always. If your NS records point to another provider, that external provider is usually where the live zone must be edited.

2. Are you using the correct host/name format?

Some dashboards want www. Others want the full hostname. Some use @ for the root domain. A perfectly correct value in the wrong field format can still publish the wrong record.

3. Did you choose the right record type?

This is the heart of the a record vs cname confusion. Use A or AAAA when you are given an IP address. Use CNAME when you are told to point to another hostname.

4. Is there already a conflicting record on that hostname?

If www already has an A record, adding a CNAME there may not be valid. Review existing entries before adding new ones.

5. Is the TTL sensible?

A low TTL can help during planned changes. A normal TTL is often fine for stable production records. The important part is understanding that caches may delay what users see after an update.

6. Did you back up the previous state?

Before changing web hosting, domain and hosting connections, or email routing, save screenshots or export the zone. This makes rollback faster.

7. Have you tested more than the homepage?

After an A or CNAME change, test the root domain, www, key subdomains, SSL behavior, and redirects. After MX and TXT changes, test email deliverability and authentication.

8. Are you mixing website and email changes by accident?

Updating A or CNAME records affects web traffic. Updating MX and some TXT records affects email. Many outages happen because someone assumes all DNS records are interchangeable.

Common mistakes

These are the mistakes that appear across registrars, web hosting dashboards, and business website setups.

Using a CNAME at the wrong place

The root domain is where many users trip up. If your provider says to use a CNAME at the apex but your DNS host does not support that directly, you may need the provider's recommended alias or flattening feature instead. When in doubt, follow the DNS host's documented method, not a generic tutorial.

Leaving old MX records in place

During an email migration, stale MX records can keep sending mail to the wrong provider. This is especially risky when switching business email services.

Publishing duplicate or conflicting SPF records

SPF information is typically stored in TXT records, but publishing multiple separate SPF policies for the same hostname can create validation problems. If you are unsure, review the final intended SPF policy rather than stacking new fragments indefinitely.

Changing NS records casually

NS edits can move the entire zone to a different DNS authority. If the new provider does not already have matching records, your site, email, and verification setup can all fail at once.

Deleting "mystery" TXT records

Old TXT entries can look messy, but they may still be tied to email authentication, ownership verification, or service integrations. Clean them up only after confirming they are no longer used.

Ignoring propagation and testing too early

Some DNS checks update quickly while other resolvers still hold cached answers. If a result looks inconsistent, that does not always mean the configuration is wrong. Test from more than one network or resolver before assuming failure.

Forgetting that registration and DNS are separate layers

You can buy domain name services from one company, use DNS somewhere else, and host the website with a third provider. Understanding that separation makes troubleshooting much easier.

When to revisit

DNS is not something you set once and forget forever. Revisit this checklist whenever the underlying services or workflows change.

• Before launching a new site or redesign: confirm A, AAAA, CNAME, redirects, and SSL coverage.
• Before seasonal planning cycles or major campaigns: verify that landing pages, tracking subdomains, and email authentication records still match current tools.
• When changing web hosting: review all website-related records and lower TTLs in advance if needed.
• When moving email providers: audit MX and TXT records together, not separately.
• When transferring a domain or changing DNS hosts: compare the full zone before and after cutover.
• When staff or vendors change: remove stale service records only after confirming ownership and dependencies.
• When security posture changes: review verification records, email authentication, and delegated subdomains.

A practical habit is to keep a simple DNS inventory with five columns: hostname, record type, current value, purpose, and owner. That one document turns DNS from tribal knowledge into maintainable infrastructure.

Final action list before your next edit:

1. Write down what outcome you want: web, email, verification, or delegation.
2. Confirm where authoritative DNS is hosted.
3. Identify the exact host label being changed.
4. Match the provider instruction to the correct record type.
5. Back up the old value.
6. Apply the change once, carefully.
7. Wait, test, and only then clean up old records.

If your broader setup includes registrar choice, hosting architecture, or future migrations, these guides are useful next reads: Free Domain With Hosting: Is It Really Worth It? and Composable Web Stacks: How to Design a Modular Domain, Hosting & CDN Architecture.

Keep this cheat sheet bookmarked. The details of a provider dashboard may change, but the safest DNS workflow stays the same: identify the job, choose the right record, preserve the old state, and test before you assume the change is complete.