What's actually happening
DNS is a caching system by design. When a resolver looks up your domain, it doesn't ask your authoritative nameserver every single time — it caches the answer for a period of time defined by that record's TTL (time to live), specified in seconds. Every resolver that queried your domain before your change has its own cached copy of the old answer, and each one will keep serving that stale answer until its own cached copy's TTL expires — independently, on its own schedule.
There's no mechanism to push a change out to those caches early. The "propagation" you're waiting for is really just the slowest of many independent caches finally expiring on its own.
Why TTL is the actual control
TTL is the one variable you control that determines how long this takes. A record with a 24-hour TTL means any resolver that cached the old value right before your change could serve it for up to 24 hours afterward. A record with a 5-minute TTL bounds that same worst case to 5 minutes.
This is why the standard practice before a planned DNS change (a server migration, a mail provider switch) is to lower the TTL well in advance — a day or more before the actual change, so the old, longer TTL has time to fully expire out of caches everywhere before you make the real change under the new, short TTL. Lowering TTL at the same moment as the actual change doesn't help; resolvers that already cached the record under the old TTL don't retroactively adopt the new, shorter one.
Why different tools report different results during this window
Any "DNS propagation checker" that queries multiple resolvers around the world during this window will legitimately show different answers from different locations — that's not a bug in the tool, it's an accurate snapshot of real, independent cache state at that moment. A resolver in one region might have queried your domain an hour ago and cached the old value; another that's never queried it before will get the new value immediately on its first lookup.
The record types that don't play by these rules
Registrar-level changes — like switching which nameservers a domain delegates to — involve an additional layer of caching at the parent zone (the registry operating the TLD) and can take longer to settle than a typical record TTL would suggest, since the parent zone's own cached delegation record has its own separate TTL, often longer than what you can control on individual records within your zone.