Free DNS Propagation Checker
Query your domain across several independent public resolvers at once and see, record by record, whether a change has propagated everywhere or only reached some.
Querying resolvers...
Could not check
no answer
No records at this resolver
What is a DNS Propagation Checker?
When you change a DNS record, the change is not instant everywhere. Each recursive resolver on the internet caches the old answer until its TTL expires, so for a while some resolvers return the new value and others still serve the old one. That window is what "propagation" describes.
A DNS propagation checker asks the same question of several independent resolvers at once and shows you their answers side by side. When they all agree, the change has propagated; when they disagree, you can see exactly which record and which resolvers are still catching up.
- Enter the domain whose DNS you just changed.
- We query it across four independent public resolvers and compare each record type.
- A record that matches everywhere has propagated. One that disagrees is still in flight, wait out the TTL and check again.
Why Check Across Resolvers?
- One resolver is not the internet: your own resolver may have the new value while most of the world still sees the old one. Comparing several independent resolvers is the only honest read.
- Per-record, not just "up": your A record can be live while your MX is still catching up. We compare each type separately so a half-propagated change cannot look complete.
- No caching in the way: we ask the authoritative recursive resolvers directly, so the answer is what they are actually serving right now.
The Records We Compare
Propagation is checked per record type, a change to one does not move the others. These are the five the checker compares across every resolver.
| Record | What it controls | Why it must agree |
|---|---|---|
| A | IPv4 address | Where the name points for IPv4 traffic. The record a site move changes, and the one whose propagation decides whether visitors reach the old server or the new one. |
| AAAA | IPv6 address | The IPv6 equivalent of the A record. Easy to forget when moving a site, and a stale one sends IPv6 visitors to the old host while IPv4 visitors reach the new one. |
| MX | Mail servers | Where email for the domain is delivered. A half-propagated MX change is how mail splits between the old and new provider and messages go missing. |
| NS | Nameservers | Which servers are authoritative for the zone. A nameserver change is the slowest to settle and the most disruptive if it is only half done. |
| TXT | SPF, verification | Carries SPF, domain-verification tokens and more. A TXT still propagating is why a verification "fails" moments after you added the record it needs. |
How to Read the Result
Each record type gets one row, showing what every resolver returned and whether they agree.
Propagated
GreenEvery resolver that answered returned the identical value for this record. The change has propagated, you can rely on it being the answer visitors and mail servers get.
Still propagating
AmberThe resolvers returned different values for this record, some have the new answer, some still serve the old one. This is normal right after a change; wait out the TTL and check again.
What each resolver sees
The columnsEvery resolver's own answer is shown, so you can tell whether a change has reached the major networks (Google, Cloudflare, Quad9, OpenDNS) or is stuck at one of them.
No answer from a resolver
GreyA resolver that could not be reached is marked and left out of the agreement check, its silence is a lookup problem on our side, not a disagreement about your zone, so it never turns a propagated record amber.
What DNS Propagation Really Is
There is no single moment a DNS change "goes live" everywhere. The authoritative servers update instantly, but the resolvers that the rest of the world actually queries keep serving their cached copy of the old answer until it expires. Propagation is the ragged edge of that cache expiry rolling across the internet.
Why it is not instant:
- Caching: resolvers hold answers to avoid asking again, and only refresh when the TTL runs out.
- Independence: every resolver has its own cache with its own clock, so they expire at different times.
The TTL Is the Clock
The TTL (time to live) on a record is how long a resolver may cache it. A record with a one-hour TTL can serve its old value for up to an hour after you change it; a five-minute TTL settles far faster. This is why operators lower the TTL before a planned change and raise it again afterwards.
A propagation checker cannot speed any of this up, nothing can, short of the TTL expiring, but it tells you where you are in the process, so you know whether to wait or whether something is genuinely wrong. If a change still disagrees long after the TTL should have passed, the problem is usually a record you did not update, which a full DNS lookup will show.
When Resolvers Disagree for a Reason
Most disagreement is just propagation in progress. A few cases are not, and it helps to know the difference:
- Anycast and GeoDNS, some providers deliberately return a different address depending on where the query comes from, to route you to the nearest server. That is a permanent, intended disagreement, not a propagation lag.
- Long or forgotten TTLs, if a record still disagrees well past its TTL, the usual cause is a second record you did not update (a stray A record, an old CNAME) rather than slow propagation. A full lookup finds it.
- Negative caching, resolvers also cache the absence of a record. If you just added one, a resolver may keep saying "no record" for the negative-cache TTL, which is set by your zone's SOA, not the new record.
- Your own resolver is not neutral, checking from your own machine often shows the new value first, because you changed it and your resolver refreshed. That is exactly why comparing independent resolvers matters. Once it has settled, monitor the zone so the next change does not surprise you.
Why Propagation Matters
Site & host migrations
Moving to a new server or host means changing an A or AAAA record and waiting for it to propagate. Checking tells you when it is safe to decommission the old server without dropping traffic.
Avoiding split-brain downtime
During propagation, some visitors hit the new server and some the old one. Knowing where propagation stands is how you avoid decisions that assume everyone is already on the new host.
Mail cutovers
An MX change that is only half propagated splits inbound mail between two providers, and messages that land on the decommissioned one are lost. Propagation is the go/no-go signal for a mail cutover.
Verification & certificates
Domain verification and certificate issuance often depend on a TXT or CNAME record. If it "fails" right after you add it, a propagation check confirms whether the record has reached the resolver being asked.
Who Checks Propagation
The same multi-resolver read serves a different moment depending on who is asking.
Operators & SREs
Confirm a record change has landed everywhere before decommissioning the old infrastructure behind it.
For DNS monitoringDevelopers & IT
Debug why a verification or a deploy is not seeing the record you just added, without guessing at cache state.
For IT & MSPsAgencies
Manage a client site or email migration and give a clear, evidence-backed answer to "is it live yet?".
For agenciesMigration Teams
Coordinate a cutover across teams with one shared view of where propagation actually stands.
For enterpriseRelated DNS Tools
Once you know where propagation stands, here is where to go next.
Full DNS lookup
See every record type for the domain at once, the full picture when a propagation disagreement points at a record you did not expect.
Run a DNS lookupEmail deliverability
Once MX has propagated, check that SPF, DKIM and DMARC are set up correctly so the mail actually gets delivered.
Check email setupDNS change detection
Propagation is a one-off; drift is continuous. Get alerted when any record in your zone changes, planned or not.
How detection worksDNS monitoring
Put the whole zone under continuous monitoring so the next change reaches you as an alert, not a surprise.
DNS monitoringFrequently Asked Questions
Common questions about DNS propagation, TTLs, and resolver caching.
What is DNS propagation?
It is the time it takes a DNS change to be reflected across the internet. Authoritative servers update instantly, but recursive resolvers keep serving their cached copy of the old answer until its TTL expires, so the change spreads gradually rather than all at once.
How long does DNS propagation take?
Up to the record's TTL. A record with a five-minute TTL settles in minutes; one with a 24-hour TTL can take a full day. Nameserver (NS) changes are typically the slowest. Lowering the TTL before a planned change shortens the window.
Why do resolvers show different answers?
Because each resolver has its own cache with its own expiry clock. Right after a change, some have refreshed to the new value and some still serve the cached old one. That is normal propagation; it resolves as the caches expire.
Which resolvers do you check?
Four large, independent public resolvers on different networks: Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) and OpenDNS. Comparing independent resolvers is what makes agreement a real signal.
Can I speed up propagation?
Not directly, nothing can force a resolver to drop a cached answer before its TTL. What you can do is lower the TTL in advance of a planned change so the window is short. After the fact, you can only wait it out.
The record still disagrees long after the TTL. Why?
The usual cause is not slow propagation but a second record you did not update, a stray A record, an old CNAME, or a duplicate. A full DNS lookup shows every record so you can find the one that is out of date.
Does the checker cache results?
No, it queries the recursive resolvers directly each time, so the answer reflects what they are serving at that moment. Their own caches are exactly what you are measuring.
Why does my own computer show the new value already?
Because you made the change, and your own resolver refreshed quickly. Your local view is the least representative one, which is why comparing independent public resolvers is the honest test.
What is a TTL?
Time To Live, the number of seconds a resolver is allowed to cache a record before it must ask again. It is set per record in your zone, and it is the single biggest factor in how fast a change propagates.
Does propagation affect email?
Yes. An MX change that is only half propagated splits inbound mail between the old and new provider, and mail delivered to a decommissioned server is lost. Confirm MX has propagated everywhere before a mail cutover.
Is a disagreement always a problem?
No. Some providers use anycast or GeoDNS to return a different address by location on purpose, which shows as a permanent, intended disagreement. Genuine propagation disagreement resolves once the TTL passes; intentional geo-routing does not.
What should I do once it has propagated?
A propagation check is a one-off snapshot. To catch the next change, whether you make it or someone else does, put the zone under continuous DNS monitoring so any record change reaches you as an alert.
Start Monitoring & Catching Domains Today
Join founders, agencies, and domainers already protecting their portfolio. Your first 5 domains are free.
No credit card required • Cancel anytime
Guides for domain operators
Deep dives on domain names, DNS, SSL, acquisitions and portfolio management.
All guides →
Do Exact Match Domains (EMDs) Still Work? How to Find & Grow Them
Do exact match domains (EMDs) still work in 2026? Discover current SEO ranking data, AI search impact, and how to acquire and grow an EMD with Domainyze.
How to Catch Domains with Hidden Expiry Dates
WHOIS won't show the expiry date for .de, .ai, .nz and other domains. Here is how to monitor domain expiration behaviorally, with no registry dates required.
Do All Pending Delete Domains Go Through Auctions?
Learn why not all pending delete domains go to auction. Explore pre-release sales, dropcatching mechanics, and multi-backorder bidding rules across registrars.