Pointing a domain to hosting is straightforward when you know which records to change and which records to leave alone. This reusable managed DNS checklist explains how A, AAAA, CNAME, MX, and TXT records work, when to change nameservers, how to reduce avoidable downtime, and how to verify that a DNS update is working.
Overview
The Domain Name System, or DNS, connects a human-readable domain such as example.com to services on the internet. Your DNS provider stores a zone containing records that tell browsers where to find a website, mail servers where to deliver email, and other services how to verify or connect to the domain.
A managed DNS service is the control panel or provider responsible for hosting and answering queries for that zone. It may be included with a domain registrar, hosting account, CDN, or a dedicated DNS provider. The important distinction is between changing individual records and changing nameservers:
- Changing a DNS record keeps the current DNS provider in place and updates one destination, such as a web server or email service.
- Changing nameservers delegates the entire DNS zone to another provider. The new provider must contain every required record before the delegation changes.
For most website launches, changing an A record or CNAME is the least disruptive approach. Nameserver changes are useful when moving to a new DNS hosting service, but they require a complete inventory of existing records, including records that may not be visible on the website itself.
DNS changes are separate from domain registration and web hosting. A registrar holds the domain registration, a DNS provider publishes the records, and a hosting provider serves the website. One company can provide all three services, but the responsibilities remain different.
Checklist by scenario
When launching a new website
- Confirm the exact domain and hostname you intend to use, such as example.com or www.example.com.
- Ask the hosting provider for the required destination: an IPv4 address, IPv6 address, target hostname, or a provider-specific value.
- Back up or record the current DNS zone before making changes.
- Use an A record when the provider gives you an IPv4 address for the hostname.
- Use an AAAA record only when the provider gives you a valid IPv6 address and the service is configured to accept IPv6 traffic.
- Use a CNAME record when the provider gives you a hostname, commonly for www or a hosted application.
- Decide whether the root domain, the www hostname, or both should be canonical. Configure the other version to redirect through the website or hosting platform where appropriate.
- Confirm that HTTPS is enabled by the hosting provider and that the certificate covers every hostname you plan to use.
When setting up email for a domain
- Keep the existing website records unless your mail provider specifically requires a change.
- Replace or add the provider's MX records exactly as documented. MX records identify the servers that receive mail.
- Add required TXT records for sender authentication, domain verification, or other services.
- Check the priority values on MX records. Lower numerical values generally indicate higher delivery priority, but follow the mail provider's instructions rather than guessing.
- Send a test message to and from the domain after the records have updated. Check both delivery and authentication results.
When transferring a domain or moving DNS providers
- Export or copy the complete current zone, including A, AAAA, CNAME, MX, TXT, SRV, CAA, and any verification records in use.
- Recreate the records at the new DNS provider before changing nameservers.
- Compare the old and new zones line by line. Pay particular attention to email, subdomains, verification tokens, and third-party applications.
- Check whether DNSSEC is enabled. If it is, follow the new provider's DNSSEC process before or during the delegation change; an incomplete DNSSEC migration can make a domain unreachable.
- Change the nameservers at the registrar only after the new zone is ready.
- Keep the old DNS service available until resolvers are consistently receiving the new delegation and all critical services work.
When adding a subdomain
Choose the record type based on the destination. Use an A or AAAA record for a server address, or a CNAME when the destination is another hostname. Examples include app.example.com for an application, docs.example.com for documentation, or status.example.com for a status page. Avoid creating overlapping records for the same hostname unless the provider explicitly supports that configuration.
What to double-check
Record name and zone: DNS control panels represent names differently. A field labeled Host may expect only www, while another may expect www.example.com. Read the panel's example and verify the resulting fully qualified name.
Trailing dots: Some systems display a final dot on a fully qualified hostname, such as target.example.net. Others add it automatically. Do not duplicate the domain by entering a value that the panel will append again.
TTL: Time to live controls how long recursive resolvers may cache a record. A shorter TTL can make planned changes easier to roll back, while a longer TTL can reduce repeated lookups. Lowering TTL shortly before a change does not instantly clear caches that already hold the previous value. Set a sensible value for normal operation and change it ahead of planned migrations when necessary.
Root and www behavior: The root domain and www are separate DNS names. Confirm both resolve as intended, then test whether one redirects to the preferred version. A DNS record alone does not create an HTTP redirect.
Propagation checks: Test from more than one network or DNS lookup service, and inspect the authoritative nameservers as well as a recursive resolver. Results can differ while caches expire. Also test in a browser, with HTTPS, and with the actual application path rather than relying on a successful DNS lookup alone.
Security controls: Restrict access to the DNS account, enable available multi-factor authentication, and review account recovery details. Keep a change log so another administrator can understand why a record exists. If your provider supports DNSSEC, evaluate it as part of the domain's security design and follow the provider's documented key-management process.
Common mistakes
- Changing nameservers without copying the zone: This can remove email, verification records, subdomains, and service integrations even when the main website loads.
- Using a CNAME at the wrong level: A CNAME cannot normally coexist with other records at the same name. Use the record type and hostname specified by the hosting provider.
- Adding an unverified AAAA record: If IPv6 points to an unavailable or incorrectly configured server, some visitors may experience failures even when IPv4 works.
- Deleting MX or TXT records during a website change: Web hosting instructions usually do not replace email instructions. Treat mail records as a separate dependency.
- Assuming propagation means a fixed waiting period: DNS caches, authoritative updates, local networks, and browser behavior can produce different results. Verify the actual records instead of relying on a timer.
- Testing only the homepage: Check login flows, forms, APIs, checkout pages, media, subdomains, and email if those services are part of the launch.
- Editing DNS during a busy launch without a rollback plan: Save the previous values, note the change time, and know which record can be restored if the destination is wrong.
When to revisit
Return to this checklist before a domain transfer, hosting migration, website redesign, seasonal campaign, email-provider change, or nameserver update. It is also worth reviewing after a security incident, a change in ownership, or the addition of a new subdomain or SaaS platform.
For ongoing maintenance, review the DNS zone on a regular schedule that suits the site's risk and complexity. Remove records for retired services, confirm that administrator access is current, and check that important records still match the systems using them. Keep an export or written inventory in a secure location, but do not publish private credentials or sensitive configuration.
Before making the next change, use this short action list:
- Write down the intended hostname, record type, and destination.
- Record the current value and identify dependent services.
- Make the smallest possible change at the current DNS provider.
- Test authoritative and recursive results from more than one network.
- Verify the website, HTTPS, email, and important application paths.
- Document the change and keep the previous value until the result is confirmed.
When the change involves a full DNS-provider move, use the same discipline at zone level: inventory first, build the replacement zone, compare it, then change delegation. This approach makes managed DNS easier to operate and gives you a dependable reference whenever the domain, hosting, or service configuration changes.
