Confirming your DNS is doing what you think it is

Verify a DNS change from somewhere that has never met the domain: the authoritative servers first, a spread of independent resolvers second, the destination itself last. Seeing the new answer at your own desk proves little, because your desk has been asking about this name all day and keeps several copies of the reply.

What "it works for me" is worth as evidence

The value is wildly asymmetric, and most people read it backwards. Between your browser and the world sit a browser cache, the operating system stub resolver, whatever your router keeps, your provider's recursive resolver, and possibly a corporate resolver or VPN exit. Each holds its own copy on its own countdown, and none of those countdowns began together. Add the local override you pinned during the build and forgot, and a green result can come from four things unrelated to your zone.

Ask the source before you ask the crowd

The authoritative servers for the zone are the only place where "correct" is a fact rather than a snapshot. Query each server named in the delegation individually rather than accepting whichever replies fastest. A secondary that is out of step hands the old value to whatever slice of the world lands on it, which is the origin of most "it works for some people" reports. Two things must hold: the nameservers recorded at the registrar match those the zone itself publishes, and every one of them returns identical data with the same serial. When they disagree, waiting does not help, because there is no single answer to wait for.

Then sample what visitors actually use

With the source clean, the remaining question is breadth. Take readings from several widely separated public resolvers and at least one path you do not administer, such as a phone on mobile data. Multi-location lookup pages are useful for shape, not truth. They show where an old answer is still alive, not whether your configuration is right. Once the authoritative set agrees, anything they report is time left on somebody's clock, and which resolvers matter to you is a network planning question.

A correct record aimed at the wrong thing

Resolution succeeding and the destination behaving are separate conditions, and the second fails quietly. The address can be right while the server there answers that hostname with an unrelated default site, because the name was never added to it. The name can resolve perfectly while the certificate presented does not cover it, which visitors read as a security warning rather than a DNS issue; that belongs with your certificate checks. Mail routing can point at a host that accepts the connection, then discards the message because it holds no mailbox for the domain. Test by hostname, and read what came back.

Knowing it has finished, not guessing

Propagation is a countdown, not weather. Four rules make it calculable:

1. The old lifetime governs, not the new one. Whatever was published before your edit dictates how long caches may keep it, which is why lowering it a day in advance is the one thing that makes a cutover quick.
2. No countdown started when you saved. Each resolver's began when it last asked, so the honest worst case is one full previous lifetime from the change.
3. Absences are cached too. A name that did not exist before has its own negative window, taken from the zone rather than the record, as set out in RFC 2308.
4. Nameserver changes live in the parent zone, on timers you do not control.

The change is finished when all authoritative servers agree, the previous lifetime has elapsed, an uncontrolled sample matches, and the destination has been checked by hostname. Until then, stragglers are expected. After that, they are a fault for diagnostics rather than another round of waiting.