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 destinations that computers can use. A DNS provider stores these instructions as records. Your domain registrar may provide DNS management, or you may delegate the domain to a separate managed DNS provider by changing its nameservers.

Before editing anything, identify where the authoritative DNS zone is hosted. Changes made at the registrar will not affect a domain if its active nameservers point to another provider. The guide Nameservers vs DNS Records: Which Should You Change and When explains this distinction in more detail.

DNS records normally include a name or host, a record type, a value, and a time to live (TTL). The host may be written as @ for the root domain, while www refers to www.example.com. Control panels vary: some automatically append the domain name, so check the provider's format before entering a fully qualified hostname.

• A: points a hostname to an IPv4 address.
• AAAA: points a hostname to an IPv6 address.
• CNAME: aliases one hostname to another hostname.
• MX: specifies where email for a domain should be delivered.
• TXT: stores text used for verification, email authentication, and other services.

DNS is separate from web hosting. A hosting account can contain your site files while DNS determines where browsers look for that site. For a broader setup sequence, see How to Connect a Domain to Your Hosting Provider.

Checklist by scenario

Connecting a domain to a website

1. Confirm the hosting provider's required destination. It may provide an IPv4 address for an A record, an IPv6 address for an AAAA record, or a hostname for a CNAME.
2. Check whether the provider expects the root domain, www, or both to be configured.
3. Add the A record for the root domain when the provider supplies an IPv4 address. A typical structure is @ → 203.0.113.10; use the actual address supplied for your account rather than this documentation address.
4. Add an AAAA record only when you have a working IPv6 address and the hosting service is configured to accept IPv6 traffic.
5. For www, use the provider's recommended CNAME or A record. A CNAME might look like www → site.provider.example.
6. Review existing records before replacing them. An old A record can send traffic to a previous server, while an incorrect CNAME can prevent the intended hostname from resolving.
7. Test both the root domain and www, including HTTP and HTTPS. DNS changes alone do not configure TLS, redirects, or the site's canonical hostname. For redirect planning, see How to Set Up Redirects for www, non-www, HTTP, and HTTPS Correctly.

Setting up custom email

1. Collect the exact MX hostnames and priorities from your email provider.
2. Remove obsolete MX records only after confirming that no active mailbox still depends on them. Multiple providers should not be mixed casually.
3. Add each required MX record. A lower preference number generally indicates higher delivery priority, but follow the provider's documented values.
4. Add the provider's TXT records for domain verification, SPF, DKIM, and DMARC where applicable. These records serve different purposes and should not be treated as interchangeable.
5. Check whether an SPF record already exists. A domain should have one consolidated SPF policy rather than several separate SPF TXT records. Follow the email provider's instructions when combining authorized senders.
6. Send a test message to and from an external mailbox. Check delivery, authentication results, and whether replies return to the expected address.

Verifying a third-party service

Website platforms, analytics systems, certificate services, and developer tools may ask for a TXT, CNAME, or occasionally an A record. Copy the requested host and value exactly, including punctuation. Some services request a record at the root, while others request a unique subdomain such as verify or a generated token.

Do not delete a verification record after setup unless the service explicitly says it is temporary. Keep a short inventory of what each unusual record is for, particularly when several teams manage the same domain.

What to double-check

• Authoritative provider: Confirm the active nameservers before making edits. If you recently completed a domain registration or domain transfer, verify which DNS service is authoritative.
• Record name: Ensure the panel expects @, a blank value, or the full domain for the root. Entering the domain twice can create an unintended hostname.
• Record value: Remove accidental spaces and use the exact IP address or hostname provided. Some TXT values require quotation marks in command-line tools but not in web control panels.
• Conflicts: A hostname cannot normally have a CNAME alongside other data records at the same name. Check for duplicate A, AAAA, or CNAME entries.
• TTL: A lower TTL can make planned changes easier to roll back, but cached answers may still remain until their previous TTL expires. Set a deliberate value rather than changing TTL repeatedly during an incident.
• IPv6 behavior: An incorrect AAAA record can cause some users to reach the wrong server even when the A record is correct. Remove or correct it if IPv6 is not serving the site.
• Email authentication: Verify that SPF, DKIM, and DMARC values match the current sending services. A website migration may not affect email, but changing DNS can affect both if records are overwritten.

Propagation is not a single global event. Different recursive resolvers, devices, and networks may cache answers for different periods. Use more than one DNS lookup method and compare the result with the intended zone. DNS monitoring and uptime monitoring are complementary; the Website Uptime Monitoring Guide covers what to track after resolution is working.

Common mistakes

Changing records at the wrong provider: This is the most basic failure. The visible DNS editor is not necessarily the authoritative one. Start with a nameserver lookup and confirm the provider's zone.

Using an A record when a hostname is required: A records contain IP addresses. If a hosting provider gives you a hostname, use the record type it specifies, commonly CNAME for a subdomain.

Pointing a CNAME at an IP address: A CNAME targets another hostname, not an IPv4 or IPv6 address. Use A or AAAA for addresses.

Leaving old email records in place: Mail can continue routing to an old provider if obsolete MX records remain. Review all MX records before completing an email migration.

Creating multiple SPF records: Multiple SPF policies can produce an invalid or unpredictable result. Combine authorized services according to the relevant provider guidance, and keep the final TXT policy within the provider's technical limits.

Testing only one hostname: The root domain, www, mail subdomains, and verification hosts can have different records. Test every name that matters to the launch.

Assuming DNS fixes HTTPS: DNS directs traffic; it does not by itself issue or install an SSL certificate, configure a web server, or redirect HTTP to HTTPS.

When to revisit

Revisit your DNS checklist before a website launch, hosting migration, domain transfer, email-provider change, or major infrastructure update. Also review it before seasonal planning cycles if your business adds temporary landing pages, marketing platforms, or new sending tools.

When workflows or tools change, update your DNS inventory. Record the hostname, type, purpose, destination, owner, and date of the last review. Keep a copy of the intended zone configuration in a secure location, but do not store credentials in the same document. A backup strategy for hosting does not automatically preserve DNS settings; the Cloud Hosting Backup Strategy explains why separate recovery planning matters.

Before making a change, use this short action list:

1. Write down the current records and the intended result.
2. Confirm the authoritative nameservers and the provider's exact instructions.
3. Lower the TTL only when there is a clear reason and enough time for the previous cache to expire.
4. Change the smallest possible set of records.
5. Check authoritative answers and public resolver results.
6. Test the website, email sending and receiving, verification services, and HTTPS.
7. Document what changed and restore any temporary TTL or verification settings when appropriate.

For larger sites or systems with failover requirements, compare managed DNS features such as monitoring, access controls, change history, and recovery options. The guide to Managed DNS vs Registrar DNS provides a framework for that decision.