DNS Records Explained: A Practical Setup Guide for Websites and Email

Overview

DNS, or the Domain Name System, translates human-readable domain names into destinations that browsers and other services can use. When someone visits example.com, DNS helps determine which server should answer the request. Email providers, certificate services, analytics platforms, and other tools also use DNS records to connect a domain or prove that you control it.

Most domain DNS setup tasks involve one of two places: the registrar, where the domain is registered, or a separate DNS provider, where the domain's authoritative records are managed. If the domain uses custom nameservers, changes must be made at the active DNS provider rather than automatically at the registrar.

Before editing anything, identify the current nameservers and make a backup or written copy of the existing records. A simple table containing the record type, host, value, and TTL gives you a recovery reference if a change produces an unexpected result.

Core DNS records at a glance

• A: Points a hostname to an IPv4 address. It is commonly used for a root domain such as example.com.
• AAAA: Points a hostname to an IPv6 address. Add it only when your hosting destination provides a valid IPv6 address.
• CNAME: Points one hostname to another hostname, such as www.example.com to a platform-provided address. A CNAME generally should not replace the root domain's required A record unless the DNS provider supports a special alias feature.
• MX: Identifies the servers that receive email for a domain. MX records include a priority value; lower numbers are generally preferred when several servers are listed.
• TXT: Stores text used for domain verification and email-related policies, including SPF, DKIM, and DMARC configurations supplied by an email provider.
• NS: Identifies the authoritative nameservers for a domain or delegated subdomain. Changing nameservers can move control of the entire DNS zone.

DNS records do not host website files, create mailboxes, or issue certificates by themselves. They connect a domain to services that perform those jobs.

Checklist by scenario

Connecting a domain to a website or site builder

1. Confirm the domain is active and that you can access its DNS management panel.
2. Read the hosting or website builder's connection instructions. Note whether it requests an A record, an AAAA record, a CNAME, or a combination.
3. For the root domain, enter the exact IP address supplied by the host in an A record when instructed.
4. For www or another subdomain, add the requested CNAME or other record. In many panels, enter only www in the host field rather than the complete domain name.
5. Remove only obsolete records that conflict with the new destination. Do not delete unrelated mail, verification, or subdomain records.
6. Save the changes, allow time for DNS caches to update, and use the host's verification tool or a DNS lookup tool to confirm the expected value.
7. Open both the root domain and the www version. Confirm that the preferred version redirects correctly if your platform supports that setting.

If you are moving an existing site, keep the old hosting active until the new destination has been tested. The migration checklist in How to Migrate a Website to Cloud Hosting can help coordinate DNS changes with content, backups, and testing.

Setting up email for a domain

1. Complete the email provider's domain setup process and copy its required MX records exactly.
2. Delete old MX records only when you are intentionally moving email. Keeping records from two unrelated providers can route messages unpredictably.
3. Add any TXT records requested for domain verification, SPF, DKIM, or DMARC. Treat each value as provider-specific rather than copying a generic example.
4. Check the host field carefully. Some DNS panels expect @ for the root domain, while others leave the field blank or append the domain automatically.
5. Send a test message in both directions and check the email provider's authentication or setup dashboard.

Website DNS and email DNS can coexist. Pointing a domain to a new website does not normally require changing MX records, so keep those services separate unless the provider's instructions say otherwise.

Verifying a service or enabling SSL

1. Copy the verification record exactly, including underscores, punctuation, and capitalization where relevant.
2. Wait for the service to detect the record, then complete verification in that service's dashboard.
3. For SSL certificate setup, confirm that the domain resolves to the intended hosting service and that the certificate covers every required hostname, such as the root domain and www.
4. Enable HTTPS in the hosting or site builder control panel after the platform confirms ownership and issues the certificate.
5. Test the HTTPS version in a private browser window and check that important pages, images, forms, and redirects do not still rely on insecure URLs.

Many managed platforms handle certificate renewal after the initial setup, but you should still monitor the domain and review the platform's renewal requirements.

What to double-check

• Authoritative DNS provider: Verify where the active nameservers point before making edits. A change made at an inactive registrar panel will not affect the live domain.
• Record name: Check whether the panel wants @, a blank value, a short host such as www, or a fully qualified hostname.
• Destination format: A records require IP addresses; CNAME records require hostnames. Do not put an IP address in a CNAME field or a URL beginning with https:// in a DNS value.
• Duplicate records: Look for conflicting A, AAAA, or CNAME records on the same hostname. A hostname cannot usually have a CNAME alongside other standard records.
• MX priority: Preserve the priority values provided by the email service and confirm that old mail servers are removed when appropriate.
• TTL: A lower TTL can make planned changes easier to adjust, but it does not instantly clear every cached answer. Follow the provider's guidance and avoid changing TTL repeatedly without a reason.
• Propagation versus configuration: If some networks show the new result and others show the old one, caching may be involved. If every lookup returns the wrong value, review the record itself or the active nameservers.

For a broader explanation of pointing a domain to a builder or host, see How to Point a Domain to Your Website Builder or Hosting Provider. After DNS changes settle, a website speed test can confirm that the new destination is also performing as expected.

Common mistakes

Changing nameservers when a record change was enough: Nameserver changes can replace the entire DNS zone. Use them only when you intend to move DNS management and have copied all required records.

Adding the domain twice: A panel may automatically append your domain to a host field. Entering www.example.com where it expects www can create an invalid name such as www.example.com.example.com.

Deleting mail records during a website change: Website A or CNAME records and email MX records serve different purposes. Review the full zone before removing anything.

Using a URL as a record value: DNS points to addresses or hostnames, not page URLs. Paths such as /login and protocols such as https:// belong in web settings, not standard A or CNAME values.

Assuming propagation is the only problem: DNS propagation cannot fix a misspelled record, an incorrect IP address, an inactive nameserver, or a service that has not been configured to accept the domain.

Testing only one hostname: Check the root domain, www, any important subdomains, email delivery, and HTTPS separately. Each can have a different record path.

When to revisit

Return to this checklist before a hosting migration, email provider change, rebrand, domain transfer, seasonal campaign, or major website launch. Review it whenever a workflow or service changes, especially if a new site builder, CDN, analytics platform, or security tool supplies new DNS instructions.

Keep a current DNS inventory with the purpose and owner of each non-obvious record. Remove records for services you no longer use, but verify their purpose first. Schedule a short review before high-traffic periods so there is time to lower risk, test redirects, confirm SSL, and validate email.

When a change is needed, use this final sequence: record the current zone, identify the authoritative provider, make the smallest necessary edit, wait for caches to update, verify with independent lookups, and test the actual website or email workflow. If the result is still unclear, pause further edits and compare the live records with the provider's exact setup instructions. That disciplined approach makes domain DNS setup safer and easier to repeat.