What DNS Propagation Is, and Why the Change Takes Time to Show

"DNS propagation" is the phrase people use for the period after a DNS change, when some visitors see the new address and others still see the old one. The phrase describes a result, not a step. Nothing is pushed out to the internet when you save a record. Each resolver keeps the answers it has already fetched, and it keeps each answer for a time set by the record's TTL, the time to live. So the change reaches people as their resolvers expire the old answer.

Test the new server before you change DNS. Open the free preview tool

This post explains what happens between your change and a visitor's browser, why two people can see different addresses at the same moment, and how to plan a switch so that the wait is short and predictable. For a migration, see the preview guide, which covers the checks to run before you change anything.

The short version

• Your DNS host saves the new record at once. Servers that answer for your zone return the new address to any query they receive.
• Resolvers, which are the servers your visitors' networks use to look up names, keep copies of the answers they fetch.
• A copy stays until its TTL runs out. A resolver that fetched the old answer just before your change keeps serving it until then.
• So the new address reaches each resolver at a different time, depending on when that resolver last fetched the record.

What a DNS record is, in one paragraph

A DNS zone holds records for a domain. An A record maps a name to an IPv4 address. An AAAA record maps a name to an IPv6 address. An MX record names the mail server for a domain. A TXT record holds text, often used for verification. Each record has a TTL, which is the number of seconds a resolver may keep the answer. RFC 1035 defines the TTL field as "a 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted" (RFC 1035, section 3.2.1). The zone owner sets the TTL, and the zone owner does not control the caches that hold the record.

Who holds a copy of the answer

A name is answered through a chain. Your visitor's device asks its operating system, the operating system asks a recursive resolver, and the recursive resolver asks the authoritative servers for the domain if it has no fresh copy. Each step can keep a copy:

• The browser may keep a short-lived copy of a name it resolved recently.
• The operating system may keep its own copy.
• The recursive resolver is the main cache. It is usually run by an internet provider, a company network, a public DNS service or a security product.
• The authoritative servers hold the current record. They answer with the current value and the TTL.

A DNS change takes effect at the authoritative servers at once. The copies in the other places only change when they expire. That is why one visitor can see the new address while another, on a different network, still sees the old one.

Why the timing is not one number

People often ask how long DNS propagation takes. The honest answer is that it depends on three things, and none of them is a fixed number.

1. The TTL on the old record. It sets how long a resolver may keep the old answer.
2. When each resolver last fetched the record. A resolver that fetched the record a second before your change holds the old answer for the full TTL. A resolver that fetched it a day earlier, with a shorter remaining TTL, may expire it sooner.
3. How the resolver treats the TTL it receives. RFC 2181 says the TTL "specifies a maximum time to live, not a mandatory time to live," and it adds that implementations "are always free to place an upper bound on any TTL received, and treat any larger values as if they were that upper bound" (RFC 2181, section 8).

Because of the third point, a resolver may cap a long TTL, and it may expire a record earlier than the TTL says. Plan for the longest TTL you set, and treat any earlier change as a bonus.

A worked example, without a fixed number

Suppose the record has a TTL of 3,600 seconds, which is one hour. You change the address at 10:00. A resolver that fetched the old answer at 09:59 can keep serving it until 10:59. A resolver that fetched the old answer at 09:00 can keep serving it until 10:00, and then it fetches the new one. A resolver that caps TTLs at a lower value will refresh sooner.

The example shows that the wait is set by the TTL that was in effect before the change, not by the TTL you set after it. Lowering the TTL on the day of the change does not help a resolver that already holds the old answer with the old TTL. Lower the TTL in advance, and wait for the old, longer TTL to run out before you make the change.

Why a lowered TTL needs time before the change

If the TTL is 86,400 seconds (one day), a resolver may hold the old answer for a day after it last fetched the record. You set the TTL to 300 seconds on the day before the migration. Resolvers that fetched the record before you lowered it keep the one-day TTL until their copies expire. After that point, they fetch the record again and receive the 300-second TTL.

So a lowered TTL works in two stages:

1. Lower the TTL, and wait at least as long as the old TTL. Then every resolver has fetched the record with the short TTL.
2. Make the change. Resolvers refresh within the short TTL.

The TTL glossary term explains the field. The pre-migration steps are listed in the migration checklist guide, and the DNS propagation checker shows the current answers from a set of resolvers around the world, so you can see when most of them return the new address.

What the DNS propagation checker shows

The checker queries a set of resolvers and reports the answer each one returns. Use it to see the split: how many resolvers return the new address, how many still return the old one, and how the answers differ by location. Check the checker when you start the change, after an hour, and again the next day.

A checker shows what its resolvers return at the moment of the query. It does not show the state of every resolver on the internet, and it cannot tell you what a particular visitor's device has cached. Use it as a guide to the general state, not as a guarantee.

Record types and what each change moves

Not every record behaves the same way in a migration. Plan each change with the record type in mind.

• A records (IPv4) decide where web traffic goes. Changing one moves the web for every visitor who uses IPv4, once their resolvers refresh.
• AAAA records (IPv6) do the same for IPv6 visitors. A stale AAAA record can keep some visitors on the old server after the A record has moved, so check both.
• MX records decide where mail for the domain is delivered. Move the mailboxes first, then change the MX records. The email DNS checker shows the current mail records.
• TXT records carry SPF, DKIM and DMARC policy, and verification tokens for other services. Keep them when you move. A verification token removed by mistake can break a service that checks the domain.
• CNAME records point one name to another. The target has its own record and TTL. A change to the target moves every name that points to it.
• NS records name the servers that answer for the zone. A change to the nameservers moves the whole zone to another provider, and it needs the registrar's own update. It is a different kind of change from editing a single A record, so plan it separately.

A migration changes one or two of these records, but a domain often has many more. Before you change anything, list every record in the zone, and mark the ones that must change, the ones that must stay, and the ones that must be checked afterwards.

When the checker looks stuck

Sometimes the change has passed its TTL and the checker still shows the old address on some resolvers. Work through these causes before you assume the change failed.

1. A second record still points to the old server. Check the AAAA record, every subdomain, and any CNAME that points to a name you did not change.
2. A resolver caps or ignores the TTL. RFC 2181 lets a resolver put an upper bound on any TTL it receives (RFC 2181, section 8). Such a resolver may hold a copy longer than you expect, and you cannot change its behaviour.
3. Your own computer holds an old copy. On Windows, ipconfig /flushdns "flushes and resets the contents of the DNS client resolver cache" (Microsoft Learn, ipconfig). Run it on the computer you use for testing, then check the name again. Your browser may keep its own copy too, so test in a private window or a second browser.
4. The change went to the wrong zone. Check the nameservers for the domain, and confirm that the zone you edited is the one those nameservers serve.
5. The checker queried resolvers that are still refreshing. A checker shows a sample. Check again after an hour, and compare the answers from more than one location.

If none of these explain the result, compare the answer your checker gets with the answer your DNS host shows for the same record. A difference means a cache or a zone mismatch. A match means the authoritative answer is right, and the rest of the internet is still catching up.

A timeline for a planned change

The plan below covers a change to an A record with a 300-second TTL, after the old TTL has been lowered in advance. Adjust the times to your own TTL.

• Day before the change. Confirm the TTL on the record is 300 seconds. Check the AAAA record and every subdomain. Run a preview of the new server, and check the mail records.
• Change day, start. Edit the A record. Run the DNS propagation checker. Expect a split between old and new answers.
• Change day, one hour later. Run the checker again. Resolvers that fetched the old answer more than 300 seconds before the change should now return the new address. Load the live domain from two networks.
• Next day. Run the checker again. Check the error logs, the forms and the payments on the new server. Keep the old server answering until its traffic has stopped.
• After the move. Raise the TTL back to your normal value once the move is stable. Remove any test entries from your computers.

The migration checklist guide describes the whole move, including the steps before and after the DNS change.

Common mistakes that make the wait longer

• Changing the TTL and the address on the same day. The old TTL still governs the old answers, so the short TTL does not help that change.
• Leaving an AAAA record that points to the old server. Visitors on IPv6 networks can keep reaching the old server after the A record changes.
• Forgetting a subdomain. A www record, a mail record or an API record may still point to the old address.
• Editing the wrong zone. Some domains are hosted by a DNS provider that is not the registrar. A change at the registrar does not change the zone that answers.
• Using a CNAME without checking the target. A CNAME points to another name, and that name has its own record and TTL. A change to the target applies to every name that points to it.
• Assuming a checker shows the whole internet. A checker shows a sample. Test the live site from a few networks, and keep the old server running until traffic moves.

Keep the old server running

Do not shut down the old server when you change DNS. Some resolvers will keep the old answer for the full TTL, and some visitors will reach the old server during that window. Keep the old server answering, with the same content or a redirect to the new site, until the traffic has moved. The server diff tool helps you compare the old and new servers while both run.

Mail is separate

A change to the A record moves web traffic. It does not move mail. MX records decide where mail goes, and SPF, DKIM and DMARC records decide how other servers check your mail. Check those records before the change, and do not let a web migration break them by accident. The email DNS checker shows the mail records for a domain.

Checking your own change

A short checklist for the day of a change:

• Confirm the TTL you plan to use, and confirm that the old TTL has run out.
• Make the change in the zone that answers for the domain.
• Check the A and AAAA records, and the records for each subdomain you serve.
• Run the DNS propagation checker at the start, after an hour, and the next day.
• Test the live domain from more than one network.
• Keep the old server running until the old address stops receiving traffic.

Terms used in this post

• Zone. The set of records a DNS server holds for a domain.
• Authoritative server. A server that holds the current records for a zone.
• Recursive resolver. A server that looks up names for clients and keeps copies of the answers.
• TTL. The time a resolver may keep an answer before it asks again.
• Cache. A stored copy of an answer that a resolver or device keeps until the TTL runs out.

The DNS glossary term gives a short definition and links back to this post.

Sources

• RFC 1035, Domain Names: Implementation and Specification, section 3.2.1 (TTL field)
• RFC 2181, Clarifications to the DNS Specification, section 5.2 (TTLs of RRs in an RRSet) and section 8 (Time to Live)
• Microsoft Learn, ipconfig command reference, parameter /flushdns

All fetched 2026-10-28, HTTP 200.