DNS Records Explained: A Configuration Guide for Reliable, Secure Websites

Overview

DNS, or the Domain Name System, translates human-readable names such as example.com into destinations that computers can use. A domain can have several DNS records at the same time, each serving a different purpose. Your hosting provider may use an A record to point the domain to a web server, while an email provider may require MX, TXT, or CNAME records.

DNS management usually takes place wherever the domain’s authoritative name servers are managed. That may be the domain registrar, a dedicated DNS provider, a hosting platform, or a security and performance service. Before changing anything, identify the active DNS provider and export or record the existing zone configuration. Changing records in an inactive dashboard will not affect the live domain.

DNS changes are also subject to caching. The record’s time to live (TTL) tells resolvers how long they may retain an answer before checking again. A change can therefore appear immediately from one network and remain unchanged from another for a period of time. This is normal, but it makes careful testing important.

For background on the individual record types, see DNS Records Explained: A Practical Guide to A, CNAME, MX, TXT, and More. Use this article as the operational checklist to apply that knowledge safely.

Checklist by scenario

Point a domain to a website

• Confirm whether the host has provided an IPv4 address, an IPv6 address, a hostname, or a combination.
• Use an A record for an IPv4 destination and an AAAA record for an IPv6 destination.
• Use a CNAME record for a hostname-based destination when the provider specifically instructs you to do so.
• Set the record name correctly. The root domain is often represented by @, while www represents the subdomain www.example.com.
• Check whether an existing record conflicts with the new one. A hostname should not generally have a CNAME alongside other record types at the same name.
• Confirm that the hosting platform has also added the domain to the correct site or project. DNS alone does not always complete site configuration.

Set up email for a domain

• Add the email provider’s MX records exactly as documented, including priority values where supplied.
• Remove obsolete MX records only after confirming that they are no longer needed. Leaving an old mail destination can cause inconsistent delivery.
• Add the provider’s requested TXT records for sender authentication, domain verification, or both.
• Check for punctuation, quotation marks, spaces, and line breaks in long TXT values. Some DNS interfaces display or store these differently.
• Test both sending and receiving. A domain can appear verified while mail routing or authentication is still incomplete.

Complete SSL certificate setup

• Make sure the domain and required subdomains resolve to the system that will serve HTTPS.
• If certificate validation uses DNS, add the requested validation record without changing its value.
• Do not delete a validation record until the certificate provider confirms issuance and you understand whether it is needed for renewal.
• After installation, test both the root domain and important subdomains over HTTPS.
• Check redirects, mixed content, and any application settings that still reference an HTTP URL. For a fuller deployment checklist, review the SSL Certificate Setup Guide.

Delegate DNS to another provider

• Copy all required records to the new provider before changing name servers.
• Include less visible records such as verification TXT records, DKIM records, service discovery records, and subdomain records.
• Compare the old and new zones for the root domain, www, mail, and application subdomains.
• Change the domain’s NS delegation only after the new zone is ready.
• Keep the old DNS configuration available until queries consistently return the new provider’s answers.

What to double-check

Before saving a DNS change, verify the record type, name, value, and TTL. A correct value in the wrong field can be just as disruptive as an incorrect value. Pay particular attention to whether the control panel automatically appends the domain name. Entering www.example.com in a field that already appends example.com could create an unintended hostname.

Review the full record set, not just the line you are editing. Common dependencies include:

• Web traffic: A, AAAA, or CNAME records for the root domain and subdomains.
• Email delivery: MX records and the TXT records required by the mail provider.
• Domain verification: TXT or CNAME records used by hosting, analytics, search, or SaaS platforms.
• Security policy: TXT records such as SPF and related email authentication entries, plus CAA records where certificate issuance is restricted.
• Delegation: NS records when a subdomain or entire domain is managed elsewhere.

Use more than one resolver or network when troubleshooting. A DNS lookup tool can show what an external resolver sees, while commands such as dig or nslookup can help compare record types and authoritative answers. For a broader troubleshooting workflow, see Best Online DNS Tools for Troubleshooting Records, Propagation, and Mail Issues.

Common mistakes

• Editing the wrong DNS provider: The registrar may not be authoritative if the domain uses external name servers.
• Replacing instead of adding: Some interfaces allow only one value per entry, while others support multiple values. Follow the provider’s format rather than deleting unrelated records.
• Using a CNAME at the root incorrectly: Root-domain CNAME behavior depends on the DNS provider. Use the provider’s documented method, which may be an alias-style record.
• Leaving duplicate mail records: Old MX records can route messages to an unintended service.
• Assuming propagation is the only problem: A persistent error may indicate a typo, a missing record, conflicting records, incorrect nameserver delegation, or a hosting platform that has not accepted the domain.
• Ignoring IPv6: An incorrect AAAA record can make some users reach the wrong server even when the A record is correct.
• Publishing sensitive data: DNS is public by design. Do not place passwords, private keys, or confidential configuration in TXT records.

When to revisit

Revisit DNS management before a website launch, domain transfer, hosting migration, email-provider change, SSL certificate renewal, or major infrastructure update. It is also worth reviewing the zone before seasonal planning cycles when traffic, campaigns, or operational responsibilities may change.

Keep a simple change record containing the date, person responsible, reason for the change, previous value, new value, and rollback plan. Review the zone when workflows or tools change, especially after adopting a new hosting platform, deployment process, security service, or email system. Remove records that no longer have an owner, but confirm their purpose first.

For the next change, use this sequence: identify the authoritative DNS provider, document the current records, confirm the intended destination, lower the TTL only when it serves a clear migration purpose, make one controlled change, test from multiple locations, and record the result. If the change affects production, prepare a rollback value before editing. This routine makes DNS management more predictable and helps protect website availability, email delivery, and SSL certificate setup.