DNS Records Explained: How to Configure A, CNAME, MX, TXT, and NS Records

Overview

The Domain Name System (DNS) translates human-readable names such as example.com into technical destinations such as IP addresses, mail servers, and authoritative name servers. DNS management is therefore part of the operating layer for a website, not just a one-time domain registration task.

Most DNS providers use a zone editor where each record has a name or host, a record type, a value, and a time to live (TTL). The exact labels vary between control panels, but the underlying concepts are consistent. Before changing anything, record the current configuration and identify which service owns DNS authority. A domain registrar, website hosting provider, cloud platform, or dedicated DNS provider may be responsible for the authoritative zone.

Use this basic record map as a starting point:

• A: Points a hostname to an IPv4 address. Commonly used for a website or server.
• AAAA: Points a hostname to an IPv6 address. Use it only when the destination is configured for IPv6.
• CNAME: Aliases one hostname to another hostname. Common for subdomains managed by hosted platforms.
• MX: Specifies which mail servers receive email for a domain.
• TXT: Stores text-based verification and email security policies, including SPF, DKIM-related data, and DMARC.
• NS: Identifies the authoritative name servers for a domain or delegated subdomain.

DNS records do not install an SSL certificate, move website files, or create an email mailbox by themselves. They direct traffic to systems that perform those functions. For broader diagnosis, see How to Troubleshoot DNS Issues and DNS Propagation Explained.

Checklist by scenario

Publishing a website with an A or AAAA record

1. Confirm the hosting provider's required IP address. Copy it exactly; do not substitute a control-panel address or a temporary address.
2. Set the host to @, a blank value, or the provider's equivalent for the root domain.
3. Set the record type to A for IPv4 or AAAA for IPv6.
4. Point www to the intended destination. This may be a CNAME to the root domain or a separate A record, depending on the hosting provider.
5. Remove conflicting records only after confirming they are no longer needed.
6. Verify that the hosting account is configured to answer for the domain and that the SSL certificate includes every hostname visitors will use.

Do not add an AAAA record merely because IPv6 is available in a control panel. If the server or firewall does not serve the site over IPv6, some users may receive a connection failure while IPv4 users continue to see a working site.

Connecting a subdomain with a CNAME record

1. Obtain the exact target hostname from the hosted service, such as a platform-specific address.
2. Enter only the subdomain in the host field, for example app for app.example.com.
3. Choose CNAME and enter the target hostname without adding an IP address.
4. Check whether the provider requires a separate verification record or a custom-domain activation step.
5. Confirm that no A, AAAA, or conflicting CNAME record already exists for the same hostname.

A CNAME points to another name, not directly to an IP address. A common configuration error is placing a full domain name in a control panel that automatically appends the zone name, creating an unintended hostname. Check how the provider handles trailing dots and fully qualified names before saving.

Setting up domain email with MX records

1. Get the complete list of inbound mail servers from the email provider.
2. Create one MX record for each required server.
3. Enter the provider-supplied priority or preference value. Lower numbers generally indicate higher delivery preference, but follow the provider's instructions.
4. Remove old MX records only when the mailbox migration is complete and the new service is ready.
5. Add the provider's recommended TXT records for SPF, DKIM, and DMARC where applicable.
6. Send test messages in both directions and inspect message authentication results in the receiving mailbox.

MX records control where incoming mail is delivered; they do not configure every part of outbound email authentication. SPF is usually published as a TXT record, while DKIM commonly uses a provider-specific selector hostname and DMARC uses a record at _dmarc. Avoid publishing multiple independent SPF policies for the same domain. Consolidate authorized senders into one policy when the provider's syntax allows it.

Completing service verification with TXT records

1. Copy the verification host and value exactly, including underscores, punctuation, and capitalization where relevant.
2. Check whether the value should be entered with or without quotation marks. Most control panels add TXT formatting automatically.
3. Leave unrelated TXT records in place unless the service documentation specifically says to replace them.
4. Wait for the record to become visible, then run verification from the service dashboard.
5. After verification, document the purpose and owner of the record.

TXT records are also used for certificate authority authorization, email policy, cloud service validation, and other administrative controls. A useful inventory should identify each record's purpose rather than treating every TXT value as disposable verification data.

Delegating DNS with NS records

1. Identify the provider that should be authoritative for the domain or subdomain.
2. Copy all required name servers exactly and confirm whether the provider requires additional glue or child-host configuration.
3. Change name servers at the registrar when delegating the whole domain.
4. Use NS records inside the parent zone when delegating a subdomain.
5. Recreate or import the required DNS records at the new authoritative provider before switching traffic.
6. Test the new authoritative answers before retiring the old zone.

Changing NS records changes who answers DNS queries for the zone. It is a larger operational change than editing a single A or TXT record, so plan it with a record inventory, rollback notes, and a maintenance window when practical.

What to double-check

• Authority: Query the domain's NS records or check the registrar to confirm that you are editing the active DNS provider, not an unused zone.
• Names: Check whether the control panel expects @, a blank field, or a relative hostname. Confirm whether it appends the domain automatically.
• Conflicts: A hostname generally should not have an A record and a CNAME at the same time. Review duplicate MX, SPF, and verification entries as well.
• TTL: Lowering TTL before a planned migration can make later changes easier to roll back, but cached answers may still remain until their previous TTL expires.
• Propagation: Check answers from more than one recursive resolver and, when investigating authority, query the authoritative name servers directly. A local cache can show an older result.
• SSL coverage: Confirm that the certificate and web server configuration cover the root domain, www, and any active subdomains.
• Email continuity: Keep old mail routing in place until the new service has been tested and the migration plan says it is safe to remove it.
• Documentation: Record the change, reason, timestamp, expected destination, owner, and rollback value. This is especially useful when several developers or administrators share responsibility.

Common mistakes

Editing DNS at the wrong provider: A registrar may sell a domain while another provider hosts the authoritative zone. Always verify the active NS records first.

Using a CNAME at the zone apex: Traditional DNS does not allow a standard CNAME to coexist with the apex's required records. Use the hosting provider's documented apex method, such as A or provider-specific alias support.

Replacing all TXT records: Multiple services can rely on separate TXT records. Delete only entries that are confirmed obsolete.

Leaving old MX records behind: Mixed mail routing can produce inconsistent delivery. During a migration, define exactly which servers should receive mail and when the old route will be removed.

Assuming propagation is the only cause: A persistent failure may come from an incorrect hostname, an inactive hosting account, an SSL mismatch, a firewall rule, or a domain that is not configured inside the application.

Changing several records without a record of the baseline: Make one related change at a time where possible. Save the previous values so you can distinguish a DNS problem from a later application or hosting change.

When to revisit

Review DNS records whenever a domain, hosting stack, email provider, certificate workflow, or verification process changes. Revisit the zone before seasonal planning cycles or major campaigns if traffic, email volume, or failover requirements will change. A short pre-change audit can prevent an old record from directing visitors or mail to a retired system.

Set a recurring administrative review based on the complexity of the environment. At minimum, compare the live zone with your inventory, confirm that every record has an owner and purpose, remove obsolete verification entries, and check that DNS access is limited to the appropriate administrators. If your website uses cloud storage, backups, or object-storage endpoints, review those hostnames and access controls alongside the DNS inventory; the related operational considerations are covered in this cloud storage security checklist.

Before your next change, use this compact runbook:

1. Write down the intended hostname, record type, value, and reason.
2. Confirm the authoritative provider and export or capture the current zone.
3. Check for conflicts with existing A, AAAA, CNAME, MX, TXT, and NS records.
4. Apply the smallest necessary change and note the time.
5. Test authoritative and recursive DNS answers.
6. Test the affected website, SSL certificate, email flow, or verification service.
7. Record the final state and define when obsolete records can be removed.

Keeping this checklist with your hosting and domain documentation turns DNS management from trial and error into a repeatable site-admin task.