DNS changes can look inconsistent even when the configuration is correct. This guide explains what propagation means, how to verify A, CNAME, MX, and nameserver changes, how to separate caching from configuration errors, and when to revisit your DNS records during routine domain management.
Overview
The Domain Name System (DNS) connects human-readable names such as example.com with services such as web servers, mail providers, and verification systems. When you edit a DNS record, the change does not instantly appear to every resolver or device. Instead, recursive DNS resolvers may continue using a cached answer until its time to live (TTL) expires and they request a fresh response.
This process is commonly called DNS propagation. It is not a single broadcast that reaches the internet at a fixed time. Different resolvers, networks, operating systems, browsers, and security tools can refresh information at different points. A DNS propagation checker can therefore show different answers by location without proving that one result is wrong.
There are two separate questions to ask after a change:
- Is the authoritative DNS configuration correct? This is the answer published by the nameservers responsible for the domain or zone.
- Are recursive resolvers seeing the new answer? This depends on caching, TTL values, and the resolver’s refresh behavior.
Keeping these questions separate makes DNS troubleshooting faster. If the authoritative answer is wrong, waiting will not fix the configuration. If it is correct but some public resolvers still return the old value, time and cache expiry may be the only remaining factors.
What to track
Maintain a simple record of each DNS change. Include the domain or hostname, record type, old value, new value, TTL, change time, reason, and the person or system that made the edit. This change log is especially useful during hosting migrations, email setup, SSL validation, and incident response.
A and AAAA records
An A record maps a hostname to an IPv4 address. An AAAA record maps it to an IPv6 address. Check that the address belongs to the intended server and that no obsolete record is still directing some users elsewhere. If IPv6 is enabled but the service is not configured correctly, some visitors may experience failures even though IPv4 tests pass.
CNAME records
A CNAME points one hostname to another hostname, often for a hosted service, staging environment, or application platform. Confirm the target spelling and whether the provider expects the record at the root domain or at a subdomain such as www. A CNAME target should resolve successfully, and it should not be combined with incompatible records at the same name.
MX and email-related records
MX records identify the mail servers responsible for receiving email. Check the hostname and priority values, and verify that the referenced mail hostnames have the required address records. Email providers may also require TXT records for SPF, DKIM, or domain verification. A website can work normally while email remains broken, so test these records separately. For broader setup considerations, see Business Email on Your Domain.
Nameserver and delegation records
Nameservers tell the parent DNS system which servers are authoritative for a domain. A nameserver change is different from editing a record inside an existing DNS zone. Before changing delegation, copy or recreate every required record at the new DNS provider, including web, email, verification, redirects, and subdomains. Missing records at the new provider can cause failures as soon as resolvers begin using the new delegation.
Use a DNS propagation checker as one view of the change, not as the only test. Compare results from multiple resolvers and query the authoritative nameserver directly when possible.
Cadence and checkpoints
Use a repeatable workflow whenever you change DNS:
- Record the intended state. Write down the exact hostname, type, value, TTL, and purpose before editing.
- Confirm the authoritative provider. Check which nameservers are delegated for the domain. Editing the wrong DNS dashboard will not change the active zone.
- Review the complete zone. During a nameserver migration, compare all important records rather than copying only the website record.
- Query authoritative answers. Confirm that the responsible nameserver returns the new value. If it does not, inspect the record name, value, zone, and save status.
- Check several recursive resolvers. Use a propagation checker or command-line queries against different resolvers. Record the time and results.
- Test the service itself. Open the site, send and receive a test email, complete a verification flow, or test the application endpoint depending on the change.
- Monitor after the change. Keep the old configuration documented until the expected cache period has passed and dependent services are confirmed.
For a website move, reduce avoidable risk by preparing the destination first and following a documented guide to pointing a domain to cloud hosting. DNS is only one part of a migration; the application, database, firewall, SSL certificate, and redirects must also be ready.
Review important zones monthly or quarterly, even when no incident is active. Confirm that records still point to services you recognize, unused subdomains have been removed or protected, TTL values reflect operational needs, and access to the DNS account is limited to the right administrators.
How to interpret changes
Only some locations show the new value: this usually indicates cache differences, provided the authoritative answer is correct. Continue checking at intervals rather than repeatedly changing the record.
No location shows the new value: verify that you edited the authoritative zone, used the correct hostname, and saved the record. Also check whether the record is masked by another record, delegated to another zone, or subject to provider-specific formatting.
The site works, but email does not: inspect MX and related TXT records independently. A web A record does not control mail delivery.
Some users reach the old server indefinitely: look for multiple A or AAAA records, a proxy or CDN layer, application-level redirects, local DNS caching, or a resolver that has not refreshed its cache. Do not assume DNS is the only layer returning the old destination.
A nameserver change causes broad failures: compare the old and new zones. Missing MX, TXT, verification, or subdomain records are common causes. Check the registrar’s delegation status as well as the new provider’s authoritative responses. For account and delegation safeguards, review this domain security checklist.
TTL is a caching instruction, not a guaranteed deadline. Lowering a TTL before a planned change can help future cache refreshes, but resolvers may already hold the previous answer under an earlier TTL. Make changes carefully and allow for overlap where the service permits it.
When to revisit
Revisit this workflow whenever you change hosting, email, a CDN, SSL validation, nameservers, domain ownership, or a major application endpoint. Also review DNS after a team member leaves, a provider account changes, a security incident occurs, or a domain is transferred. A domain transfer checklist can help separate registrar changes from DNS changes.
For routine maintenance, schedule a monthly or quarterly review of critical domains. Start with an inventory of active records, then confirm authoritative answers, compare them with your intended service map, and test the services that matter. Remove abandoned records, document exceptions, and verify that recovery contacts and multifactor authentication remain current.
When a live issue occurs, use this short sequence: identify the failing service, query the authoritative nameserver, compare multiple recursive resolvers, inspect the record type and value, test the destination directly, and document the final fix. If the authoritative data is correct, avoid making additional edits solely because a propagation checker has mixed results. If it is incorrect, correct the zone first and then monitor the cache transition.
