DNS Records Explained: A Practical Guide to A, CNAME, MX, TXT, and Nameserver Settings

Overview

DNS, or the Domain Name System, translates human-readable domain names into service-specific destinations. A DNS record is an instruction stored in a domain’s DNS zone. For example, an A record can point a domain to an IPv4 address, while an MX record tells other mail systems where to deliver email.

Before changing anything, identify where DNS is managed. This is usually the provider listed by your domain’s nameservers, but it may be your domain registrar, web host, cloud platform, or a separate DNS provider. Nameservers determine which DNS service is authoritative; DNS records are the individual instructions managed within that service. For a closer comparison, see Nameservers vs DNS Records.

Keep a record of the current zone before editing it. Note the host or name, record type, value, time to live (TTL), and any priority or other fields. Make one logical change at a time, save it, and test the affected service before proceeding.

Common DNS record types

• A: Points a hostname to an IPv4 address. It is commonly used for a website or server with a fixed IPv4 address.
• AAAA: Points a hostname to an IPv6 address. Add it only when the destination is configured for IPv6.
• CNAME: Creates an alias from one hostname to another hostname. It is useful for subdomains such as www, but it should point to a hostname rather than an IP address.
• MX: Specifies the mail servers responsible for receiving email for a domain. MX records include a priority value; lower numbers generally indicate higher priority.
• TXT: Stores text used for domain verification, email authentication, and other service instructions. SPF, DKIM, and DMARC information is commonly published through TXT records, although DKIM may be presented through a provider-specific setup.
• NS: Identifies the authoritative nameservers for a domain or delegated subdomain. These records are normally changed through the domain or DNS provider rather than edited casually inside the zone.
• CAA: Specifies which certificate authorities may issue SSL certificates for a domain. Use it only when you understand the certificate providers your website and services require.

Checklist by scenario

Connecting a domain to web hosting

1. Confirm the hosting provider’s required destination, such as an IPv4 address, IPv6 address, or target hostname.
2. Decide whether the root domain, often written as @, and www should use an A record, AAAA record, or CNAME.
3. Remove or replace conflicting records only after checking what they support. An old A record can send visitors to the previous host.
4. Save the records, allow time for caches to update, and test both the root domain and www version.
5. Complete SSL certificate setup at the hosting provider and test both HTTP and HTTPS. DNS pointing alone does not guarantee that HTTPS is configured.

For a fuller workflow, use the domain-to-hosting DNS setup checklist. If you are moving to a cloud server, the guide to connecting a domain to cloud hosting covers related SSL and troubleshooting steps.

Setting up business email hosting

1. Collect the exact MX hostnames and priority values from your email provider.
2. Remove obsolete MX records unless the provider specifically requires multiple destinations.
3. Publish the provider’s TXT records for domain verification and email authentication exactly as supplied.
4. Check whether a DKIM selector creates a separate hostname, such as a selector beneath _domainkey.
5. Add a DMARC record only after understanding how it will handle messages that fail authentication. Start with a monitoring-oriented approach when appropriate, then tighten the policy after reviewing reports.
6. Send test messages to and from more than one mailbox and confirm that replies, forwarding, and attachments work.

Adding a subdomain

1. Choose a clear hostname, such as blog, docs, shop, or staging.
2. Use an A or AAAA record for a server address, or a CNAME when the service gives you a target hostname.
3. Configure the subdomain inside the destination platform as well. A DNS record does not automatically create a website, application, or mailbox.
4. Apply access controls and SSL to sensitive environments such as staging, administration, and internal documentation.

If you are deciding between a subdomain and a subdirectory, review Subdomain vs Subdirectory before creating a larger site structure.

What to double-check

• Authoritative DNS: Verify the active nameservers before editing records. Changes made in the wrong dashboard will not affect the live domain.
• Record scope: Check whether the provider expects @, a blank name, the full domain, or only a host label. Control panels use different conventions.
• Trailing dots: A fully qualified hostname may be displayed with a trailing dot. Follow the control panel’s format and avoid duplicating the domain accidentally.
• Conflicts: Do not place a CNAME alongside other records for the same hostname when the DNS provider does not allow that combination.
• TTL: Lowering TTL can help before a planned migration, but it does not instantly clear cached answers. Restore a sensible value after the change has settled.
• Email security: Ensure SPF has one coherent policy for the domain and that all legitimate sending services are accounted for. Confirm DKIM signing in the mail platform and review DMARC behavior before enforcing it.
• Testing: Query the record from more than one DNS checker or network, then test the actual website, email flow, verification process, or application endpoint.

Common mistakes

One frequent mistake is changing nameservers when only a single A, CNAME, or MX record needed updating. Nameserver changes can move control of the entire DNS zone and may remove existing website, email, verification, or security records if the new zone is incomplete.

Another is copying a web hosting record into an email setup, or replacing all records with a provider’s sample zone. Before deleting anything, identify what each existing record supports. Unused-looking TXT records may be required for verification or email authentication.

People also often test too soon. DNS answers can be cached at different layers, so one device may show the new destination while another still shows the old one. Check the authoritative response, allow reasonable time for caching, and avoid repeatedly changing values while propagation is still in progress.

Finally, do not treat DNS as a substitute for website security. Use an SSL certificate, keep hosting and applications updated, protect registrar and DNS accounts with strong authentication, and maintain recoverable backups. The website hosting maintenance checklist covers these operational controls.

When to revisit

Revisit your DNS records before a hosting migration, email provider change, domain transfer, seasonal campaign, or major website launch. Review them after adding a SaaS tool, marketing platform, developer service, subdomain, or new email sender. These changes often introduce verification, tracking, authentication, or routing records.

Schedule a periodic review of the DNS zone, particularly for domains used by a business. Confirm that every record has a current purpose, remove obsolete entries after verifying they are no longer needed, and check that registrar contact details, domain renewal settings, DNS access, SSL coverage, and backups are current.

When workflows or tools change, update your internal DNS notes. Record the provider, purpose, owner, expected destination, and rollback plan for important entries. Before making the next change, use this sequence: identify the authoritative nameservers, document the current record, confirm the provider’s exact value, change only the required entry, test the affected service, and keep evidence of the result. That simple process reduces avoidable outages while making future DNS management easier to audit.