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

Overview

The Domain Name System (DNS) translates human-readable domain names into information that browsers, mail servers, and other services can use. When someone visits example.com, DNS helps determine which server should receive the request. When someone sends mail to that domain, DNS identifies the mail provider responsible for receiving it.

DNS records are managed wherever the domain's authoritative nameservers point. That may be your domain registrar, hosting company, or a separate DNS provider. Before adding a record, confirm that you are editing the correct DNS zone. A change made in the wrong dashboard will not affect the live domain.

Common records have different jobs:

• A: Points a hostname to an IPv4 address, usually for a website or server.
• AAAA: Points a hostname to an IPv6 address. It is not interchangeable with an A record.
• CNAME: Points one hostname to another hostname, often for a hosted website, app, or subdomain.
• MX: Specifies which mail servers receive email for a domain.
• TXT: Stores text used for domain verification, email authentication, and other instructions.
• NS: Identifies the authoritative nameservers for a domain or delegated subdomain.

DNS changes are separate from hosting, SSL, and application settings. A correct A record can direct visitors to a server, but the server still needs the website configured for the domain. Similarly, an MX record can identify a mail provider, but mail authentication and mailbox settings may require additional records.

If you are connecting a new site, first review the broader DNS settings guide for connecting a domain and fixing common errors. For a complete site setup sequence, use the beginner-friendly website building guide.

Checklist by scenario

Scenario 1: Connect a domain to a website

1. Find the hosting provider's required destination. This may be an IPv4 address for an A record, an IPv6 address for an AAAA record, or a hostname for a CNAME.
2. Open the DNS management area for the authoritative provider.
3. Add an A record for the root or apex domain if an IP address is supplied. In many dashboards, the host field is shown as @ or can be left blank.
4. Add a CNAME for www if the host requires it. The value should be the exact hostname supplied by the hosting provider.
5. Remove or replace conflicting records only after recording the original values. An apex hostname generally should not have multiple unrelated A records unless the provider specifically instructs you to use them.
6. Save the changes, then configure the domain inside the hosting account. DNS alone does not always complete the connection.

Example: an A record might use host @ and value 203.0.113.10. A CNAME might use host www and value sites.example-host.com. These are illustrative formats; always use the destination supplied for your own service.

Scenario 2: Set up email with MX records

1. Obtain the mail provider's complete MX record list, including each server name and priority.
2. Add each record at the root domain, commonly represented by @.
3. Enter priority values exactly. A lower number commonly represents higher preference, but follow the provider's instructions rather than guessing.
4. Remove old MX records if the domain is being moved to a new mail provider. Leaving old and new destinations together can send messages to different systems.
5. Add the provider's recommended TXT records for email authentication or domain verification when required.
6. Test both sending and receiving after the records have had time to update.

Do not use an A record where an MX record is required. MX values normally point to mail-server hostnames, not directly to an IP address. Also check whether the provider requires a trailing dot in a fully qualified hostname; many dashboards add it automatically.

Scenario 3: Verify a domain or service with TXT

1. Copy the exact host or name provided by the service. It may be @, a short label, or a name beginning with an underscore.
2. Choose TXT as the record type.
3. Paste the complete value without changing punctuation, quotation marks, spaces, or capitalization unless the service says otherwise.
4. Save the record and return to the verification service.
5. Keep the TXT record if it is used for an ongoing function, such as email authentication. Remove temporary verification records only when you are certain they are no longer needed.

Scenario 4: Create a subdomain

For a subdomain such as blog.example.com, add the label blog in the host or name field. Use an A record when the subdomain should point directly to an IP address, or a CNAME when it should follow another hostname. Then configure the destination service to recognize the subdomain and issue an SSL certificate for it if needed.

Scenario 5: Change nameservers

NS changes are made at the registrar or parent DNS provider, not usually as ordinary records inside the existing zone. Copy the complete nameserver set from the new DNS provider, save it at the registrar, and confirm that the new provider contains all required records before switching. Missing records can interrupt the website, email, verification services, or subdomains after the delegation changes.

What to double-check

• Correct zone: Confirm the domain, environment, and DNS provider before editing.
• Hostname format: Some dashboards expect www, while others expect www.example.com. Avoid duplicating the domain if the interface appends it automatically.
• Record conflicts: A hostname should not have a CNAME alongside other record types. Check for an existing record with the same name before adding one.
• Root-domain behavior: A standard CNAME is generally not used at the apex. Some DNS providers offer special alias or flattened records; use those only according to that provider's documentation.
• TTL: Time to live controls how long resolvers may cache a response. A shorter TTL can make planned changes easier to adjust, but it does not guarantee instant worldwide updates.
• SSL configuration: If DNS resolves correctly but the browser shows a certificate warning, inspect the hosting or certificate configuration separately.
• Verification from more than one place: Check the DNS provider's saved record and use an independent DNS lookup tool or command such as dig to compare the result.

DNS propagation is often described as a single event, but cached answers can differ by resolver, location, and record. If one network shows the new value while another shows the old value, caching may be the explanation. Avoid repeatedly changing the record while waiting; each change can make diagnosis harder.

Common mistakes

Editing the wrong nameservers: A registrar may display DNS controls even when the domain uses another provider's nameservers. Check the active NS records before assuming that dashboard is authoritative.

Adding the domain twice: If a provider asks for mail and the dashboard automatically appends .example.com, entering the full domain can create an unintended name such as mail.example.com.example.com.

Leaving old MX records in place: During an email migration, old MX records may continue receiving messages. List the records first, then remove obsolete entries according to the migration plan.

Replacing all TXT records: A domain can need several TXT records for different services. Add the new value without deleting unrelated verification or authentication records.

Assuming DNS fixes application errors: If DNS lookup returns the expected destination but the site displays a server error, WordPress error, redirect loop, or database failure, continue with application and hosting troubleshooting. The website troubleshooting checklist can help separate these layers.

Changing records without a record of the old state: Save a copy or screenshot of existing records before making changes. This provides a practical rollback reference and makes handoffs easier.

When to revisit

Return to this checklist whenever a domain changes hosting, email provider, registrar, nameserver delegation, or verification service. Revisit it before a planned launch, domain migration, seasonal campaign, or major website redesign so DNS, SSL, email, and subdomains can be tested together.

Use this short action list before closing a DNS task:

1. Write down the intended hostname, record type, value, and priority or TTL.
2. Confirm which nameservers are authoritative.
3. Export or record the current zone before editing.
4. Add only the records required by the service.
5. Check for conflicts, especially duplicate CNAMEs and obsolete MX records.
6. Verify the result from an independent lookup and test the real website, email flow, or service verification.
7. Document what changed, when it changed, and which provider supplied the values.

DNS records are easy to overlook after a successful launch, but they remain part of the site's operating foundation. Keeping a current record inventory and repeating these checks whenever tools or workflows change will make future domain and hosting work safer and faster.