Move from explanation to action with the matching DomainCheck.co.uk tools for this topic.
Check live resolution before and after a DNS or transfer change.
Useful when a UK domain transfer depends on TAG or registrar handling.
Check TLD context when transfer and DNS behaviour can vary by namespace.
The beginner explanation describes what propagation is. This article is the practical one: how to check whether a DNS change is visible, where to look, and how to tell the difference between an authoritative update and a cached result. Keeping these separate avoids turning one article into both a definition and a troubleshooting checklist.
Checking DNS propagation is really about answering one question: “Has the new DNS value reached the places that matter?” The answer may be yes in one place and no in another, so the goal is to compare the authoritative record with what different resolvers are currently returning.
| What you see | What it usually means | What to do next |
|---|---|---|
| New value everywhere | The change has reached the places you checked | Confirm the live site behaves as expected |
| New value at the authoritative source, old value elsewhere | A cache is still holding the old answer | Wait for TTL expiry and recheck |
| Wrong value at the authoritative source | The DNS change itself is wrong | Fix the zone before chasing propagation |
| Different answers on different resolvers | Normal during a change window | Compare authoritative and cached results |
Your DNS provider has the value you expect. Any mismatch now is likely cache timing or a resolver that has not refreshed yet.
Propagation is not the problem. Correct the record at the source first, then check the rest again.
That usually points to a local resolver, ISP cache, or a device that has not refreshed yet.
You may be looking at the wrong zone or an in-progress transfer. Verify the registrar and the live DNS host.
First, confirm the record is correct at the DNS provider that hosts the zone. If you are not checking the authoritative copy, you are only guessing.
Look for:
If the authoritative zone is wrong, propagation is not the problem. The data itself needs fixing.
The answer depends on the TTL, the resolver cache, and how often different systems refresh. A low TTL can shorten the wait, but it does not force every network to refresh instantly.
| TTL / setup | Typical behaviour | Practical note |
|---|---|---|
| Very low TTL | Often refreshes quickly | Useful before planned changes, not as a magic fix |
| Standard TTL | May take longer to settle | Expect a mixed picture during the transition |
| Nameserver change | Can look inconsistent for longer | Check both the registrar and the new DNS provider |
Different resolvers may return different answers during a change window. A practical check usually involves comparing:
If the authoritative answer is new but another resolver is still showing the old value, that is usually a cache timing issue rather than a configuration failure.
If the record is wrong at the authoritative source, waiting will not help. The value will keep propagating exactly as configured, including the mistake.
That is especially important when the website or mail system fails immediately after a change. A bad record, wrong hostname, or missing zone entry can look like a propagation delay when it is actually a configuration error.
When you run a DNS lookup, pay attention to:
For example, if you updated an A record but the lookup still returns the previous IP address, check whether the resolver is still holding a cached result. If the nameservers themselves are wrong, you may be querying a DNS zone that is no longer authoritative for the domain.
Nameserver checks are useful after a transfer or hosting move. If the domain should be using a new DNS provider, verify that the registrar has the correct NS records and that the new provider has the full zone file replicated.
It is common for people to change nameservers and then forget to recreate:
If these are missing, parts of the domain may appear broken even though the nameserver change itself worked.
For websites, the main records are usually:
If you are testing a web change, make sure you are checking the exact hostname the browser uses. The root domain and www often have different records, and one can update correctly while the other is still old.
Email checks are more sensitive because several DNS records may be involved. If mail is not working after a DNS change, inspect:
A record can be correct while mail still fails because the email authentication records were not copied across.
It is normal for tools to disagree briefly. A browser-based checker, a command-line lookup, and a third-party DNS tool may show different answers because they query different resolvers or cache layers.
When that happens:
Do not assume the first failed check means the change failed everywhere.
People often get false alarms because they:
The cleanest method is to isolate DNS from the app or hosting layer. If DNS is correct but the website is still wrong, the problem may be on the server side.
Use this sequence when you want a quick sanity check:
This workflow is enough for most routine site moves and mail updates.
Wait if:
Investigate if: