DNS Records Explained: A, CNAME, MX, TXT, and More for Your Website

Overview

The Domain Name System (DNS) translates human-readable names such as example.com into the destinations computers use to reach a service. DNS records are stored by a DNS provider, which may be your domain registrar, web hosting company, or a separate DNS hosting provider.

Before changing a record, identify where the domain’s authoritative nameservers point. Editing DNS at the wrong provider will not change the live domain. You can usually find the active nameservers in your registrar account or by using a DNS lookup tool.

Each record has a name, type, value, and often a time to live (TTL). The name identifies the host, the type determines how the record is interpreted, and the value specifies the destination or instruction. A TTL controls how long DNS resolvers may cache the answer before checking again.

The core DNS record types

• A record: Points a hostname to an IPv4 address. It is commonly used for a website or server, such as @ pointing to 203.0.113.10.
• AAAA record: Points a hostname to an IPv6 address. Use it when your hosting environment provides IPv6 connectivity.
• CNAME record: Aliases one hostname to another hostname. For example, www can point to example.com or to a provider-specific hostname. A CNAME points to a name, not an IP address.
• MX record: Specifies which mail servers receive email for a domain. MX records include a priority value; lower numbers generally indicate higher delivery preference.
• TXT record: Stores text instructions or verification data. Common uses include email authentication, domain ownership checks, and SSL certificate validation.
• NS record: Identifies the nameservers responsible for a domain or delegated subdomain. Nameserver changes affect where the rest of the DNS zone is managed.
• CAA record: States which certificate authorities may issue SSL/TLS certificates for a domain. Configure it only when you understand the certificate workflow it needs to support.
• SRV record: Identifies the hostname and port for a particular service. Some collaboration, voice, and directory services use SRV records.

For most website launches, the essential records are A or AAAA for the root domain, a CNAME or A record for www, MX records for email, and TXT records for verification and email security.

Checklist by scenario

Scenario 1: Connect a domain to web hosting

1. Confirm the hosting provider’s required destination: an IPv4 address, IPv6 address, or hostname.
2. For the root domain, create the requested A and/or AAAA record. Some DNS panels label the root host as @; others leave the name field blank.
3. Decide how www.example.com should work. A CNAME to the root domain is common, but follow the host’s instructions if it requires a separate A record.
4. Remove conflicting records for the same name. An A record and CNAME record cannot normally coexist for one hostname.
5. Confirm the hosting account recognizes both the root domain and any desired subdomains.
6. Enable SSL in the hosting control panel after DNS points to the correct service. Certificate issuance may require the domain to resolve first.

For a broader launch sequence, see How to Connect a Domain to Web Hosting: DNS Records, SSL, and Propagation Checklist.

Scenario 2: Set up business email

1. Obtain the email provider’s MX hostnames and priority values.
2. Remove old MX records if you are moving providers, unless the new provider specifically requires a mixed configuration.
3. Add the provider’s TXT verification record if requested.
4. Configure email authentication records, such as SPF and DKIM, using the exact values supplied by the mail provider.
5. Add a DMARC TXT record after reviewing the provider’s guidance and choosing a reporting or enforcement approach appropriate for your domain.
6. Send test messages in both directions and check whether replies, forwarding, and attachments work as expected.

Do not create multiple independent SPF records. If several services send mail, combine their authorized mechanisms into one valid SPF record according to their documentation.

Scenario 3: Add a subdomain

Choose the subdomain name, such as app, shop, docs, or staging, and then use the record type required by the destination. An A record is appropriate for a fixed server IP. A CNAME is useful when a service gives you a hostname that may change behind the scenes. Keep production and testing subdomains clearly separated, and avoid pointing a sensitive subdomain at an unmaintained service.

Scenario 4: Complete verification or SSL validation

Copy the verification record exactly, including the host name, value, punctuation, and any required quotation handling. A provider may ask for a TXT record at the root domain or a CNAME under a generated validation hostname. Do not replace existing TXT records unless the instructions explicitly say to do so. After validation succeeds, document whether the record can be retained or removed.

What to double-check

• Authoritative DNS: Make changes at the provider listed by the active nameservers, not necessarily the company where the domain was registered.
• Host field format: DNS panels differ. One may expect www, while another expects www.example.com. Follow the panel’s format to avoid duplicating the domain name.
• Trailing dots: Some systems display fully qualified hostnames with a final dot. Preserve it when required, but do not add one blindly to every value.
• Existing records: Export or record the current zone before editing. This is especially important when the domain already supports email, APIs, verification services, or multiple environments.
• TTL and propagation: Lowering TTL before a planned migration can help future changes refresh sooner, but cached answers may still remain available for a while. DNS propagation is not an instant global switch.
• SSL coverage: Confirm the certificate includes every hostname visitors will use, such as the root domain and www. DNS correctness alone does not guarantee HTTPS is configured.
• Email continuity: Before changing MX records, identify every system that sends or receives mail. Website contact forms, billing platforms, support tools, and marketing systems may need separate authentication records.

Use a DNS propagation checker as one source of evidence, but also test from more than one network or resolver. A successful lookup does not prove that the web server, SSL certificate, or application is configured correctly.

Common mistakes

• Editing the wrong DNS zone: The change appears saved, but the public domain never changes because another provider is authoritative.
• Using a CNAME at the root when the provider does not support it: Root-domain aliasing has provider-specific behavior. Use the documented method, which may involve A records or an alias-type record.
• Leaving stale records behind: Old A, MX, or verification records can send traffic or email to an outdated service and make troubleshooting difficult.
• Creating duplicate or conflicting records: Multiple A records may distribute traffic, while conflicting CNAME and A records can invalidate the intended configuration.
• Expecting DNS to fix an application problem: If DNS resolves correctly but the site returns an error, check the hosting virtual host, firewall, application configuration, and SSL setup.
• Changing nameservers without a zone migration: Moving DNS management can remove records that were not recreated at the new provider. Copy the complete zone first, then switch nameservers.
• Ignoring documentation: Third-party platforms often require exact record names and values. Guessing is slower than following the provider’s current setup instructions.

If you are changing registrars as well as DNS providers, keep the DNS zone active until the new arrangement is verified. The domain transfer without downtime checklist can help separate registrar work from DNS work.

When to revisit

Review DNS whenever a service, hosting environment, domain, or email workflow changes. Revisit it before a website migration, seasonal campaign, product launch, SSL renewal process, or planned nameserver change. It is also worth checking after team members change roles or when an old third-party service is retired.

Keep a simple DNS change record with the date, hostname, record type, old value, new value, reason, and person responsible. For important domains, store a current zone export securely and review it on a regular schedule. Remove obsolete records only after confirming that no active service depends on them.

Before each change, use this short action checklist:

1. Identify the authoritative DNS provider.
2. Write down the current records and intended outcome.
3. Confirm the exact values from the destination provider.
4. Check for conflicting records before saving.
5. Lower TTL only when a planned change justifies it.
6. Test DNS resolution, HTTPS, website behavior, and email separately.
7. Record the final configuration and remove temporary validation records when appropriate.

DNS is easiest to manage when it is treated as documented infrastructure rather than a one-time setup task. A careful record of what each entry supports makes future domain registration, hosting changes, security reviews, and service migrations safer and faster.