TTL and caching: why your DNS change lags behind
When a DNS change "does not work yet", that is almost always a misdirection: the zone already carries the new value, and everyone answering is answering from an old copy. Every resolver that ever asked the question keeps the answer — and how long it may do so stands written in the record itself.
That keeping time is the TTL: not a guideline but a maximum. A resolver may hold the answer for exactly that long and not one second longer — so the lever of a smooth change lies before the change, not after it: first lower the TTL, then change, and only when every cache has run out does the TTL go back up.
Start at the DNS propagation checker: your browser asks the same question to Google (8.8.8.8), Cloudflare (1.1.1.1) and Quad9 (9.9.9.9), and the page says per resolver who already sees the new answer, who still holds the old one and which TTL covers it. What the zone itself carries is shown by the DNS lookup — two directions of looking, one question.
1. What a TTL is — and what it is not
TTL — time to live — is the maximum time a resolver may keep an answer: 300 seconds means five minutes, 3600 means an hour. Throwing it away may happen earlier; later may no one. And the empty answer has a TTL too: a name that is not there is kept just as long, and that is why a young domain sometimes answers "no" long before it answers "yes".
What a TTL is not: a sync interval. Between zone and world there is no push — the zone never reports that something changed, and the world finds out by itself as soon as a cache expires. So the age of the oldest copy of the answer determines when your change becomes visible, and nothing else.
2. Lower beforehand, change, raise afterward
The working order for a planned change: hours in advance lower the TTL of the records you will touch — 300, or 60 if your DNS host allows it — wait until the old, longer TTL expired everywhere, and then change; after a quiet day the TTL returns to its normal value. Whoever skips the first step waits afterward exactly the time they wanted to avoid.
Where TTLs stand depends on your host: in the DNS panel of registrar or hosting, per record or centrally as "default TTL", and at some hosts with a minimum and maximum per zone. The DNS lookup shows the TTL that currently stands on the wire per record, so you can look at what you set — and what the world is allowed to do with it.
3. Three questions, three directions of looking
The DNS lookup asks your domain at the resolver of our server: that answers what is reachable along that one road. The DNS compare asks the same question at four public resolvers at once and lays differing answers side by side, without averaging. And the DNS propagation checker stays entirely in your own browser: your connection asks Google, Cloudflare and Quad9 itself, over DNS-over-HTTPS — so you measure along exactly the road your visit will later arrive on, with the open note that those parties see your question and may keep a log of it.
One rule applies to every measurement: a resolver that did not answer, gave an error or was too slow counts as unknown and never as "does not see". A failed question says nothing about your zone — and a validating resolver that does not dare to answer says something else entirely, namely that something in the DNSSEC chain was wrong; for that there is the DNSSEC reader.
4. When it is not the cache
If the new value is nowhere after the TTL ran out, caching is seldom the cause: the value stands on the wrong hostname (www where only the bare domain was touched), a CNAME still points at the old target, or MX and SPF were changed separately while they belong together — is this IP on your SPF is the same domain from that side. And if half the world sees the new value and half does not, that is often no error: CDNs answer per place, and the cache of one large resolver simply has not expired yet.
Measure before and measure after: the propagation checker exports a JSON report per measurement, so the baseline from before the change and the check after it get two dates; the report comparator lays the two reports side by side on their finding id, making "did it get better?" an answer with two measurement moments instead of a feeling.