Skip to content
ForgePlug — Logo
developerRuns Server-SideNo Signup

DNS Propagation Checker

Query a domain's A, AAAA, MX, TXT (including SPF), and NS records from three independent public DNS-over-HTTPS resolvers — Cloudflare, Google, and Quad9 — at the same moment, and instantly see whether they agree. A record that differs between resolvers is flagged as still propagating, so you know whether to wait or investigate. Part of ForgePlug's Site Health Check, which also runs SSL, HTTP security header, and robots.txt checks on the same domain at no extra cost.

This check runs server-side — ForgePlug briefly connects to the domain you enter to read its certificate, DNS records, response headers, and robots.txt/sitemap. We don't store anything beyond a 5-minute result cache (to avoid re-running the same check for everyone hitting a trending domain) and a short-lived snapshot used to compare a re-check later.

Checking DNS propagation from three vantage points

Cloudflare, Google, and Quad9, queried at the same moment.

"Is my DNS change live yet?" is hard to answer from a single lookup, because your own machine's resolver may have cached the old answer while the rest of the world has already moved on — or the other way around. This tool queries A, AAAA, MX, TXT (including SPF), and NS records from three independent public resolvers at once and compares the answers directly.

If every resolver agrees, the change has propagated. If they disagree, that record is flagged as still propagating, and you can see exactly which resolvers have the old value versus the new one instead of guessing.

Because it's part of ForgePlug's full Site Health Check, submitting also runs a TLS certificate check, an HTTP security header scan, and a robots.txt/sitemap validation on the same domain — all in parallel, at no extra cost.

Frequently Asked Questions

DNS propagation checking, explained

How does the propagation check actually work?
It queries A, AAAA, MX, TXT, and NS records from three independent public DNS-over-HTTPS resolvers — Cloudflare, Google, and Quad9 — at the same moment. If two resolvers return different answers for the same record type, that's a live sign the change is still propagating outward from your authoritative nameserver.
Why DNS-over-HTTPS instead of a normal DNS query?
This tool runs on serverless infrastructure that commonly blocks outbound UDP on port 53 (the traditional DNS port), so it queries each resolver's HTTPS JSON API instead — the same records, delivered over a protocol serverless functions can actually use.
How long does DNS propagation actually take?
Up to the TTL that was set on the record before you changed it. Nothing spreads outward from your nameserver — your authoritative server updates instantly, and every resolver that already cached the old value keeps serving it until its copy expires. If the old TTL was 86400, some resolvers will hold the previous answer for a full day.
Can I force propagation to finish faster?
Not after the fact. You cannot make someone else's resolver forget a cached record early. The only real lever is planning ahead: lower the TTL to around 300 seconds a day or two before a migration, so by the time you cut over, the cached copies everyone holds are already short-lived.
The site loads for me but my colleague still sees the old server. Who is right?
Both of you. Your resolver's cached entry has expired and been refreshed; theirs has not. This is the normal, expected behaviour of a change in progress rather than a misconfiguration — which is exactly why checking several independent resolvers is more informative than checking your own machine.
Why do NS records matter more than A records during a migration?
If you moved DNS hosting entirely, NS records control which nameserver resolvers ask in the first place. Until the delegation change works through, some resolvers are still querying your old provider — so they will keep returning old answers no matter what you set at the new one.
Is this really free, and is there a limit?
Yes — Site Health Check is free and doesn't require an account. Like every ForgePlug tool it's rate-limited per IP address (a handful of checks per minute) to keep the service fast and available for everyone, not to push a paid tier.
Why does this tool need a server? Aren't ForgePlug's tools all browser-based?
Almost all of them are — but a browser can't open a raw TLS handshake, query a DNS resolver directly, or fetch another site's headers without hitting CORS. Those three things require a real network connection from a server, so this one tool runs a small, rate-limited check server-side instead of pretending it can do it client-side.
What do you do with the domain I check?
The check result is cached for 5 minutes so a burst of people checking the same trending domain doesn't trigger five fresh outbound connections each time, and the most recent result is kept briefly so a re-check can eventually show what changed. We don't log who checked what.

Guides & Articles

Learn how to get the most out of this tool with our in-depth guides.

Tool Overview

A closer look at DNS Propagation Checker — how it works, who it's for, and where it fits in your workflow.

"DNS propagation" is a slightly misleading name for what is actually happening. Nothing spreads outward from your nameserver. When you change a record, your authoritative nameserver is updated instantly — but every resolver that already asked for the old value is holding it in cache until the TTL you set on that record expires. What feels like a change rippling across the internet is really thousands of independent caches quietly timing out at different moments.

That mechanic explains the symptom that drives people to a tool like this: you moved a site to a new host, it loads perfectly for you, and a colleague two streets away still sees the old server. Neither of you is wrong. Your resolver had a stale entry that has since expired; theirs has not. There is no way to force someone else's resolver to forget early, which is why the only real fix is planning — lowering a record's TTL to a few minutes a day or two *before* a migration, so the cached copies everyone is holding are short-lived by the time you cut over.

This checker queries A, AAAA, MX, TXT, and NS records from three independent public resolvers at the same instant: Cloudflare, Google, and Quad9. Because they operate separate cache infrastructure, disagreement between them is direct evidence that a change is still working through. Agreement across all three is a reasonable signal that most of the internet has caught up, though it is a sample, not a guarantee.

It queries each resolver over DNS-over-HTTPS rather than traditional port 53, because the serverless platform this runs on blocks outbound UDP. The records returned are the same; only the transport differs. One consequence worth knowing: DoH endpoints answer from the resolver's own cache, which is exactly what you want here — you are trying to observe cache state, not bypass it.

Key Features

Everything you get with this tool, at a glance.

Three independent resolvers

Queries Cloudflare, Google, and Quad9 simultaneously so cache disagreement is immediately visible.

Five record types

Reads A, AAAA, MX, TXT, and NS in a single pass rather than one lookup at a time.

Mid-propagation detection

Different answers for the same record across resolvers is the clearest sign a change is still landing.

Nameserver visibility

NS records confirm whether a registrar delegation change has actually taken effect yet.

Mail and verification records

MX and TXT cover the records behind email delivery and domain-ownership verification.

One request, not fifteen

All resolvers and record types resolve in parallel instead of sequentially.

How to Use DNS Propagation Checker

Get from zero to done in four quick steps — no account, no learning curve.

  1. Check before you migrate, not after

    Read the current TTL on the records you are about to change. That number is how long the internet will keep serving the old value after you switch, and it is the one variable you can still control beforehand.

  2. Lower the TTL in advance

    Drop the TTL to 300 seconds a day or two ahead of a cutover. Caches then hold the old value for minutes rather than hours when you make the real change.

  3. Enter the domain and read across resolvers

    Compare the answer from each of the three resolvers for the same record type. Identical answers suggest the change has largely landed; differing answers mean it is still in progress.

  4. Check NS records for delegation changes

    If you moved DNS hosting entirely, the NS records are the ones that matter. Until those agree, some resolvers are still asking your old provider for answers.

  5. Wait out the original TTL before worrying

    If the records look right at the authoritative source, the remaining wait is just the old TTL expiring. Re-checking every thirty seconds does not make it faster.

Practical Examples

Real input and output pairs so you know exactly what to expect.

Records agreed across all resolvers

Input

github.com

Output

Pass — A, AAAA, MX, TXT, and NS records match across Cloudflare, Google, and Quad9.

Domain with no mail records

Input

example.com

Output

A and NS records resolve consistently; MX comes back empty, which is expected for a domain that does not receive mail.

Checking a delegation move

Input

your-domain-mid-migration.com

Output

NS records differing between resolvers indicates the registrar delegation change has not finished working through caches.

Guides & Articles

Learn how to get the most out of this tool with our in-depth guides.

Was this tool helpful?

Your feedback helps us improve DNS Propagation Checker for everyone.

Share this tool

Share