DNS records connect a domain to websites, email systems, verification services, and security controls. This practical DNS record guide explains what A, AAAA, CNAME, MX, TXT, and CAA records do, when to use each one, what can conflict, and how to check your work before changing a live domain.
Overview
The Domain Name System, or DNS, translates human-readable names such as example.com into the technical destinations used by browsers, mail servers, certificate systems, and other services. A DNS record is one instruction within that system. Each record has a name, a type, a value, and sometimes a time to live (TTL), which tells DNS resolvers how long they may cache the result.
DNS is not the same as web hosting. A hosting provider stores and serves website files or application responses; DNS tells visitors where to find that service. Similarly, registering a domain gives you control of the name, but it does not automatically configure website hosting, email delivery, or SSL. These systems must be connected with the appropriate records.
Use this reference when launching a website, adding a subdomain, changing email providers, verifying a third-party service, or reviewing the security of an existing domain. If you are moving a website or host, pair this guide with the website hosting migration checklist so DNS, email, and SSL changes are handled together.
DNS record reference table
| Record | What it does | Typical use | Important consideration |
|---|---|---|---|
| A | Maps a name to an IPv4 address. | Pointing a domain or subdomain to a web server. | Use an IPv4 address only; do not enter a hostname. |
| AAAA | Maps a name to an IPv6 address. | Making a website or service reachable over IPv6. | The address must be a valid IPv6 address, not an IPv4 address. |
| CNAME | Points one hostname to another hostname. | Connecting a subdomain to a hosted platform or canonical hostname. | A CNAME generally cannot coexist with other records at the same name. |
| MX | Specifies mail servers for a domain. | Receiving email for addresses such as name@example.com. | Priority values determine the order in which mail servers are tried. |
| TXT | Stores text associated with a domain or hostname. | Email authentication, service verification, and security policies. | Copy the value exactly; quotation marks and spaces may matter in the provider interface. |
| CAA | States which certificate authorities may issue certificates for a domain. | Adding control around SSL/TLS certificate issuance. | It must be compatible with the certificate authority used by your hosting or certificate workflow. |
Checklist by scenario
When publishing a website
- Confirm which hostname should load the site: the root domain,
www, or another subdomain. - Ask the hosting provider whether it requires an A record, AAAA record, CNAME, or a combination.
- For an A record, enter the provider's IPv4 address in the value field. For an AAAA record, enter the supplied IPv6 address.
- If the provider gives a hostname rather than an IP address, use a CNAME where the DNS design permits it.
- Decide which hostname is canonical and redirect the alternative at the web-server or hosting layer. DNS alone does not create an HTTP redirect.
- Confirm that SSL hosting is enabled for every hostname visitors will use. A DNS change can point traffic to a server, but it does not by itself issue or install a certificate.
For a new small-business site, document the final records alongside the hosting account and certificate settings. The cloud hosting selection guide can help separate DNS responsibilities from the capabilities of the hosting platform.
When setting up email
- Collect the exact MX hostnames and priority values from the email provider.
- Remove obsolete MX records only after confirming that the replacement service is ready. Multiple providers should not be left configured accidentally.
- Check whether the provider also requires TXT records for SPF, DKIM, or domain verification.
- Keep email authentication records at the name specified by the provider. An SPF record, for example, is usually published at the domain level, while DKIM commonly uses a selector-based hostname.
- Test both inbound and outbound email after the DNS changes are visible. A website loading successfully does not prove that mail is configured correctly.
Do not place website destinations in MX records or mail servers in A records. Each record type has a distinct role, even when the same provider manages several services.
When verifying a service or subdomain
- Identify the exact record type and host name requested by the service.
- Preserve punctuation, capitalization where relevant, underscores, hyphens, and the complete value.
- Check whether your DNS control panel automatically appends the domain name. Some interfaces expect only
_service; others expect the full hostname. - Wait for the record to become visible to external resolvers before repeatedly changing it.
- Remove one-time verification records only when you understand whether the service will need them again for renewal or account recovery.
When adding domain security controls
- List every service that may request or renew an SSL/TLS certificate.
- Before adding a CAA record, confirm the certificate authority identifier required by that service.
- Use the least permissive rule that fits your actual certificate workflow, but document the decision so a future administrator understands it.
- Test certificate issuance or renewal in a controlled way after the change.
- Review related TXT-based email security records and verification records for unexpected changes.
CAA records are a control for certificate issuance, not a replacement for HTTPS, certificate renewal, secure application configuration, or access controls. Treat them as one layer in a broader website security checklist.
What to double-check
Record name: The root domain is often shown as @, but notation varies between DNS hosting providers. A record for www is different from a record for the root domain.
Value format: A and AAAA records require IP addresses. CNAME and MX records require hostnames. TXT values are text strings and may be split or displayed differently by different interfaces. Follow the receiving service's format exactly.
Trailing dots: Fully qualified hostnames may appear with a final dot, such as mail.example.net.. Some control panels add or remove this notation automatically. Avoid duplicating the domain, such as mail.example.net.example.com.
Conflicts: A CNAME at a hostname generally cannot sit alongside an A, AAAA, MX, or TXT record at that same hostname. A common error is creating a CNAME for www while an old A record for www remains.
TTL and propagation: TTL affects caching, so different users may see old and new answers for a period after a change. Do not assume that a successful result from one resolver means every network has updated. Use a DNS propagation checker and query more than one location when troubleshooting.
Authoritative DNS: Make changes at the provider named by the domain's authoritative nameservers. Editing records at a registrar or hosting account that is not authoritative will have no effect on the public domain.
Change control: Record the previous value, new value, reason, date, and person or system making the change. This simple log makes rollback safer and helps distinguish a DNS problem from a hosting, application, or certificate problem.
Common mistakes
- Using a CNAME at the root without checking provider support: The root domain has special DNS behavior, and not every provider handles a root alias in the same way. Follow the DNS provider's documented method.
- Leaving old MX records in place: Mail may be delivered inconsistently or to an inactive service when old and new destinations remain together.
- Publishing several SPF records: SPF is normally represented by one policy at a given name. Combine authorized senders according to the email provider's instructions rather than creating separate competing policies.
- Copying a TXT value inaccurately: A missing character, extra domain suffix, or incorrect selector can cause verification or email authentication to fail.
- Expecting DNS to fix an SSL error: DNS must point traffic to the right service, but the certificate must also cover the requested hostname and be correctly installed or managed.
- Changing nameservers and records at the same time without a plan: A nameserver change moves authority for the entire DNS zone. Prepare the complete zone at the destination before switching.
- Editing live records without a rollback: Save the prior configuration and lower TTL ahead of a planned migration only when the timing and provider behavior are understood.
If a site is unreachable after a change, check in this order: authoritative nameservers, the exact record name and type, the returned value, hosting availability, firewall or access rules, and finally the SSL certificate for the requested hostname. This sequence prevents treating every failure as a propagation problem.
When to revisit
Review DNS records before a hosting migration, email-provider change, domain renewal, new subdomain launch, certificate renewal, or major application deployment. It is also sensible to review the zone before seasonal planning cycles when traffic, staffing, or business-critical workflows may change.
During each review, confirm that every A, AAAA, CNAME, MX, TXT, and CAA record has a current owner and a documented purpose. Remove records that are no longer needed, but first verify that they are not supporting an overlooked service, certificate renewal process, or email sender.
When workflows or tools change, revisit provider-specific syntax and automation. A deployment platform may replace an IP address with a hostname; an email platform may add a new verification or authentication record; a security process may introduce CAA requirements. Keep the DNS zone aligned with the systems that actually use it.
For a planned cutover, use the domain pointing checklist, verify the new site before changing traffic, and monitor both web requests and email after the change. For ongoing reliability work, the website uptime and performance checklist provides a useful companion review.
Final action checklist: identify the authoritative DNS provider; export or document the current zone; classify each record by purpose; confirm the exact values with the relevant hosting, email, or security provider; make one planned change at a time; verify results from outside your local network; and record what changed. That process keeps DNS understandable, reduces avoidable SSL and email failures, and gives the next administrator a reliable starting point.
