Resolution checks · Caches and TTL · 5 minutes
How to check DNS propagation — Nothing Is Propagating — Caches Are Expiring
Your change was finished the moment you saved it; what you are waiting for is other people's servers forgetting the old answer.
The short answer
DNS does not propagate: your authoritative nameservers hold the new answer the instant you save it, and the wait is simply every other resolver in the world keeping its cached copy of the old answer until the TTL on it runs out.
So the useful check is not a map of green and red ticks. It is a direct query against your own nameservers — if the answer is right there, the record is correct and everything else is somebody else's countdown.
By the Hosting & Domains team · Reviewed 24 August 2026
Beginner
Level assumed
5 minutes
Budget for it
4
Stages, start to finish
24/7
Support, at any hour
Half of all propagation panic is local: the stale answer is on the machine doing the complaining. This walkthrough puts the checks in an order that finds that out first.
It also explains the one thing you can control, which is the TTL — and why controlling it means acting the day before rather than the day of.
The word is wrong, and the wrong word causes the panic
Nothing travels outward. Your nameservers publish an answer, and resolvers around the world ask for it when they need it and then keep what they were told for as long as the TTL permits. There is no wave moving across a map, no queue, and no process you can join to make it hurry.
Once you see it as expiry rather than distribution, the behaviour stops being mysterious. Networks change over one at a time, in no particular order, entirely according to when each one last happened to ask.
Ask the authority first
Query your own nameservers directly: dig @ns1.yourprovider.net yourdomain.com, or the equivalent in any lookup tool that lets you name a server. That is the only answer that says whether the record itself is right.
A wrong answer there means you have a record to fix and no amount of waiting will improve it. A right answer there means the job is done, and everything else you are seeing is a cache somewhere between you and it.
Then ask the world, and read the map properly
A propagation checker queries dozens of public resolvers at once and shows you which hold the new value. Mixed results are the normal, healthy midpoint of any change, not evidence of a fault — each red entry is a resolver whose copy has not yet expired.
What deserves attention is a checker showing the old value everywhere hours after an authoritative query returns the new one, since that usually means a second zone is involved somewhere, or the delegation itself points at nameservers you are not the one editing.
The TTL that governs a change is the old one
This is the detail that catches everybody. The waiting time is set by the TTL that was in place before the edit, because that is the figure every resolver was given when it last asked. Lowering the TTL at the same moment you change the record does nothing for this change; it only helps the next one.
So for anything planned, lower the TTL a day in advance, make the change, and put the TTL back afterwards. That turns most of a day of tail into a few minutes, and it is the only genuine speed control anyone has.
The stale resolver is usually the one on your desk. Your own computer caches DNS answers, your browser keeps its own separate cache, and your router frequently caches on top of both. It is entirely normal for the whole internet to have the new answer while the machine you are testing from insists on the old one.
Flush locally, or simply open the site on a phone over mobile data, and you step around your own view entirely. Doing that before you contact anybody resolves a good half of the cases that would otherwise become a support ticket.
Written against the real panel, not a generic one
Instructions written against imaginary hosting go stale quickly. These are written against the thing itself: the same Zone Editor, the same domain settings, the same buttons in the same order.
A copy is taken daily on every plan, and putting a file or a database back is one click in the panel rather than a support ticket.
- Every step checked against the live panel
- The trap named before you reach it
- What the clock is doing, at every stage
- Support that answers mid-job, not next week
Why Hosting & Domains
Standard on every plan
The mechanism, not the metaphor
Caches expiring rather than data travelling — which is the difference between waiting calmly and changing records at random.
Checks in the order that finds faults
Authority first, then the world, then your own machine, so a real error is caught in the first thirty seconds.
The map read correctly
What mixed results mean, and the one pattern that genuinely does indicate something is wrong.
The TTL rule stated plainly
The old value governs this change, which is why the only speed control has to be used a day beforehand.
Local caches ruled out early
Machine, browser and router all cache, and half of all propagation panic is one of the three.
Someone to check with
Support answers at any hour, including the one where you would simply like a second opinion on a lookup.
Quick Start
Order placed to site online
- 1
Query your own nameservers directly
Run a lookup against the authoritative servers by name. A wrong answer here is a record to fix; a right answer here means the change is finished and everything else is a countdown you do not control.
- 2
Check the delegation still points where you think
An NS lookup confirms which nameservers the registry publishes for the name. If they are not the ones you have been editing, that alone explains everything you are seeing.
- 3
Ask the world and read it as expiry
A propagation checker queries resolvers globally. Mixed results are the normal midpoint of a healthy change — each outstanding entry is one cache still counting down its own TTL.
- 4
Clear your own caches before you doubt the result
Flush the machine and the router, or load the site on a phone over mobile data. The most stubbornly out-of-date resolver in any of these stories is usually the one in the room.
Built In
Fitted to every plan
- Full zone control — A, CNAME, MX and TXT — from the panel
- Free SSL on every plan, reissued before the old certificate lapses
- cPanel, which is what most of the industry already runs
- A daily copy, with restores you run yourself from the panel
- People on the support desk every hour of every day
- 99.9% uptime as the target, watched around the clock
- NVMe storage on every tier, not only the expensive ones
- LiteSpeed caching in the server itself rather than bolted on by plugin
- No set-up charge at any point, and no joining fee
- Money back within 30 days on hosting plans, 7 on reseller
Frequently Asked
Questions we field again and again
Can I force other people's resolvers to update?
No, and nothing sold on that promise can either. Caches you do not control expire on their own clocks. What you can control is the next change: lower the TTL a day beforehand, and clear the caches you do own so that you at least see the result promptly.
Why does the site work on my phone but not on my laptop?
Different resolvers with different cached answers. The mobile network's resolver has expired its copy and asked again; your laptop, or your router, or your browser is still holding the old one. It is the clearest possible sign that the change itself is fine.
How do I query my own nameservers directly?
Name the server in the lookup: dig @ns1.yourprovider.net yourdomain.com, or nslookup yourdomain.com ns1.yourprovider.net. That bypasses every cache between you and the authority and tells you what the record actually is, which is the only fact worth having early on.
Does lowering the TTL after I have made the change help?
Not for that change. Every resolver was handed the previous TTL the last time it asked, and it will hold the old answer for that long regardless of what the zone says now. The lower value takes effect for the next edit, which is why planned work starts a day early.
Keep reading
Plesk Hosting
Plesk hosting where the zone, the delegation and the site sit behind one login.
WordPress Hosting
WordPress hosting with the records, the certificate and the site administered together.
Changing provider? Work through this checklist beforehand.
A straightforward running order for a migration your visitors never spot: which files travel first, how to bring the mail across without dropping a single message, the right moment to repoint DNS, and the two errors that sit behind almost every outage we get called in to fix.
Answers you can check for yourself.
Free SSL, a free migration, full zone control from the panel, and support that answers while the change is still landing.
View Plesk Hosting plans