"Propagation" describes the wait but explains it wrongly. Your record changed the moment you saved it. What takes time is every resolver in the world letting go of the copy it already had, and that is governed by one number you control.

See how long is left

dig +noall +answer yourdomain.com\n# yourdomain.com. 3421 IN A 1.2.3.4

3421 is the seconds remaining on that cache. When it reaches zero the resolver asks again. That is the whole mechanism.

Check the source, not your own machine

dig @1.1.1.1 yourdomain.com +short\ndig @ns1.yourdns.com yourdomain.com +short

Asking the authoritative server tells you whether the change is live at all. If that answer is right and a public resolver is wrong, it is only a cache and only time.

Lower the TTL before a change, not after

Lowering TTL now does not shorten the current wait: the world is holding the OLD ttl. Lower it a day before you plan to change the record, then the change itself is minutes.

Your own machine is the slowest

# Linux\nsudo systemd-resolve --flush-caches\n# macOS\nsudo dscacheutil -flushcache\n# Windows\nipconfig /flushdns

Browsers cache separately and aggressively. Test in a private window, or with dig, before deciding the change failed.

Nameserver changes are the slow ones - up to 48 hours - because they are held at the registry. A record change inside nameservers you already use is minutes.