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

Overview

The Domain Name System (DNS) translates human-readable names such as example.com into information that browsers, mail servers, and other services can use. DNS management normally takes place at the provider responsible for your domain's DNS zone. That provider may be your domain registrar, web host, cloud platform, or a separate managed DNS service.

Before changing a record, identify two things: the exact hostname being configured and the service that supplied the target value. A website host might provide an IP address for an A record, while an email provider might provide several MX, TXT, or CNAME values. Copy values carefully and keep a record of the previous configuration before editing a production domain.

Common DNS record types

• A record: Points a hostname to an IPv4 address. It is commonly used for a website or server that has a fixed IPv4 address.
• AAAA record: Points a hostname to an IPv6 address. Add one only when the destination is configured for IPv6 and the address is correct.
• CNAME record: Creates an alias from one hostname to another hostname. It is useful when a service gives you a destination such as app.provider.example instead of an IP address.
• MX record: Tells other mail systems where to deliver email for a domain. MX records include a priority value; lower numbers generally indicate higher delivery preference.
• TXT record: Stores text used for domain verification and email policies, including SPF, DKIM-related configuration, and DMARC. The exact value must come from the relevant service.
• NS record: Identifies the authoritative name servers for a domain or delegated subdomain. Changing NS records is a broader DNS change than editing an individual host record.

DNS labels are entered differently across control panels. Some systems expect the full name, while others automatically append the domain. If you enter www.example.com into a field that already appends example.com, you could accidentally create www.example.com.example.com. Check the panel's instructions or verify the resulting fully qualified name after saving.

Checklist by scenario

Point a domain to a website

1. Confirm whether the host supplied an IPv4 address, IPv6 address, hostname, or a combination.
2. Use an A record for the supplied IPv4 address and an AAAA record for the supplied IPv6 address.
3. Use a CNAME when the host supplied a hostname, often for a subdomain such as www.
4. Configure the root domain and www intentionally. They may require different records or a redirect at the web server.
5. Remove obsolete or conflicting records only after confirming that no active service depends on them.
6. Test both the root domain and important subdomains over HTTP and HTTPS after the change.

For a broader launch sequence, use the WordPress website launch checklist, which covers hosting, SSL, DNS, backups, and performance.

Set up custom email

1. List the current MX records before making changes.
2. Obtain the complete MX values and priorities from the email provider.
3. Remove old MX records only when the provider's migration instructions say to do so. Leaving an old destination can cause inconsistent delivery.
4. Add the provider's TXT records for SPF or domain verification exactly as supplied.
5. Configure DKIM and DMARC according to the provider's instructions, usually using TXT or CNAME records.
6. Send and receive test messages from more than one account, then inspect message headers when troubleshooting.

DNS changes alone do not create mailboxes, aliases, forwarding rules, or user accounts. Those are normally configured inside the email service. For the full email workflow, see How to Set Up a Custom Email Domain.

Verify ownership or connect a third-party service

1. Identify whether the service requests a TXT record, CNAME record, or another record type.
2. Enter the exact host or name, including any required underscore such as _acme-challenge or _service.
3. Preserve quotation marks only if the DNS control panel specifically requires them.
4. Do not replace existing TXT records unless the service explicitly instructs you to do so. Multiple TXT records may be valid.
5. Complete verification in the third-party dashboard after saving the DNS change.

Delegate a subdomain or change DNS providers

1. Document all current records and identify services that rely on them.
2. Lower the TTL in advance if you have planned the migration and the provider supports that workflow.
3. Recreate required records at the new authoritative DNS provider.
4. Change NS records only after the new zone is complete and tested.
5. Check website, email, verification, and security records after delegation.

For a deeper comparison of providers and control models, read Managed DNS vs Registrar DNS.

What to double-check

• Record conflicts: A hostname generally should not have a CNAME alongside other record types. Follow your DNS provider's rules for any special alias feature.
• Root-domain behavior: The root, or apex, domain may be handled differently from subdomains. Do not assume a CNAME is supported at the apex.
• IPv6 readiness: An incorrect AAAA record can direct some visitors to an unreachable destination even when the A record works.
• MX priority: Confirm both the mail destination and priority. A typo in either can affect delivery.
• TXT formatting: Long values may be displayed in segments by a control panel. Do not alter the content while copying it.
• TTL and propagation: TTL controls how long resolvers may cache a response. A change may appear quickly in one location and remain cached elsewhere until the previous TTL expires. Propagation is not a single global switch.
• Authoritative answers: Test the name servers that are actually authoritative for the domain, not only the records shown in a hosting dashboard.

Useful checks include querying the record from more than one DNS resolver, using the provider's DNS diagnostics, and testing from a network outside your normal office or home connection. If you recently moved a domain or changed name servers, review the domain transfer checklist as well.

Common mistakes

• Editing the wrong DNS zone: A domain can be registered with one company while its authoritative DNS is hosted elsewhere.
• Using an IP address in a CNAME: CNAME targets are hostnames. Use A or AAAA records for IP addresses.
• Leaving old mail records in place: Multiple unrelated MX destinations can produce unpredictable delivery during a provider change.
• Overwriting SPF: SPF is normally published as a single policy for a domain. Adding separate SPF TXT records can invalidate the policy; combine authorized senders according to the email provider's instructions.
• Forgetting the trailing dot: Some interfaces expect a fully qualified target with a trailing dot, while others add it automatically. Follow the interface's format rather than guessing.
• Changing several variables at once: Edit one related group, record the change, and test before making another change. This makes rollback and diagnosis easier.
• Assuming DNS changes affect SSL immediately: A certificate authority or hosting platform may require its own validation step after DNS is correct.

When to revisit

Review your DNS records before launching a website, moving web hosting, changing email providers, renewing an important service, or adding a platform such as a CDN, payment system, monitoring tool, or marketing service. Also revisit the zone after a domain transfer or name-server change, because the active DNS provider may not be the one you originally used.

Before seasonal planning cycles or major traffic campaigns, confirm that website records, email authentication, SSL validation, and domain renewal details are documented and current. Remove records for retired services, but keep a dated change log so that a later administrator can understand why each record exists.

When a problem appears, use this order: confirm the authoritative name servers, query the exact hostname and record type, compare the answer with the service's required value, allow for caching, and then test the application itself. For performance-related DNS decisions, see How to Speed Up DNS. A careful, documented workflow is usually safer than repeatedly editing records until a result appears.