Your IP address:
Provider:
...

What is DNS propagation?

DNS propagation is the informal name for the interval when resolvers still return different answers after a record changes. DNS does not broadcast a new value to every server at once. Recursive resolvers fetch answers when needed and may retain them in a cache for the permitted lifetime.

Why answers differ

Suppose a site owner changes an A record from one IP address to another. The authoritative server already holds the new value, but a visitor’s recursive resolver recently saved the old one. Until that cached answer expires, the visitor may reach the previous server. TTL states how long an answer may be cached; the remaining time depends on when that resolver received the previous answer.

Changing a domain’s delegation to new nameservers is a separate operation. Delegation information can also be cached, so moving DNS providers requires both the old and new zones to be considered. Editing a record in the new provider’s panel will not help while queries still follow the old delegation.

Check the right layer

Find the currently authoritative nameservers first. Ask them for the specific record, then compare the result with a few recursive resolvers. The DNS propagation checker can compare visible answers, while the DNS configuration tool helps inspect individual records. Record the time, exact name and type: A, AAAA, MX and TXT are independent.

If an authoritative server still gives the old value, waiting for caches is not the answer. Verify which provider hosts the live zone and whether the edit was saved. If authoritative answers are new but some recursive resolvers are old, allow the cached entries to expire. Repeated edits during diagnosis make the timeline harder to interpret.

Plan a safer change

Before a planned migration, lower the old record’s TTL early enough for its previous lifetime to pass. Make the new server ready before switching and, where possible, keep the previous one serving requests through the transition. For mail, review related address and TXT records alongside MX.

Clearing a cache on your own computer only affects part of the path; it cannot clear other people’s resolvers. A TLS error or broken application can persist even when DNS is correct. TTL and caching are specified in RFC 1035, with negative answer caching in RFC 2308.

If web and mail services move together, test their DNS records separately. A working web page does not prove that mail delivery has been restored.