Where to start
Confirm which provider currently serves your DNS, compare the exact hostname and record type, and review the old TTL. Then compare the answer with another resolver or network. A TTL is a cache lifetime, not a guaranteed worldwide completion timer.
Open DNS lookup1. Confirm the active DNS provider
The company that registered your domain may be different from the company serving its DNS. Review the nameserver settings at your registrar and compare them with the provider where you made the edit.
Run an NS lookup as another point of comparison. NetLuma gets this answer through its hosting resolver; it is not a direct audit of the parent delegation or every authoritative server. If the registrar and dashboard disagree, confirm the active setup with the provider before moving records.
Look up the domain’s DNS records2. Match the exact hostname and record type
The root domain, www and other subdomains can have separate records. A correct change to example.com does not by itself establish the configuration for www.example.com. Look up the hostname visitors actually use.
Compare A and AAAA records for website addresses, CNAME for aliases, or the specific MX or TXT record involved in an email change. If a provider asks for a CNAME target, use the hostname value it specifies rather than inserting a complete page URL.
3. Read TTL as a cache lifetime
TTL is expressed in seconds. A value of 3600 is one hour. An answer already held by a resolver can remain there until that cached entry expires, even after the authoritative record has changed.
Lowering the new record’s TTL does not retroactively change the lifetime of an answer that was cached earlier. A nameserver change also involves different records and caches from an ordinary address edit. Avoid using one lookup’s TTL as a countdown for every visitor.
4. Compare what changed with what is observed
Save the expected value and the time you changed it. Look up the same record type again and compare with a separate resolver or network when available. This helps distinguish a consistent configuration problem from different cached answers.
The following patterns guide the investigation; they do not prove a cause on their own.
| Pattern | Check next |
|---|---|
| Every comparison shows the old value | Confirm the active DNS zone, saved record and provider instructions. |
| Some comparisons show the new value | Review the previous cache lifetime and allow existing answers to expire. |
| Root domain works; www fails | Inspect the www record and the web server configuration for that hostname. |
| Addresses look correct; page still fails | Check HTTPS, the website response and redirects. |
On a small screen, scroll the table sideways to see both columns.
5. Account for proxies and multiple addresses
If a hostname is deliberately proxied through a CDN, its public DNS response can show the CDN addresses instead of the origin hosting address. Compare the answer with the intended proxy setup, rather than treating every unexpected public IP as an error.
More than one address can also be intentional. Review both A and AAAA when only some visitors report a problem, and check that the relevant web endpoints serve the intended hostname. A successful lookup only tells you the record answer; it does not confirm that the application at that address works.
6. Confirm the website or email service separately
Once DNS matches the expected setup, run Website status and SSL checker for the same hostname. A DNS record can be correct while a redirect, certificate or application configuration still points visitors to the wrong place.
For an email change, compare MX, SPF and DMARC with the instructions from the provider handling the mail. The Email DNS checker discovers basic records and policy; it does not send a message or prove that a mailbox exists.
If the result remains inconsistent beyond the expected cache period, give your provider the hostname, record type, expected value, observed value and change time. Those details help them investigate without guessing which record you meant.
Check the domain’s email DNSTechnical references
Provider documentation and technical explanations supporting this guide.