A DNS propagation checker queries public DNS resolvers for your hostname and shows which ones return the new value and which still return the old one. Mixed results mean caches are still draining. Uniform results mean the change has reached those resolvers, or that the record itself is wrong.

Want to skip the reading? Run the free DNS propagation checker. No signup. It handles A, AAAA, CNAME, MX, TXT and NS records.

The reframe that answers most questions: DNS propagation is cache expiry with a misleading name. The TTL on the record you changed predicts the wait. The table below has the numbers.

What "propagation" actually is

Propagation is the lag between updating a record at the authoritative server and every recursive resolver returning the new value. That's all.

It isn't a network event. Nothing is being pushed across the internet. Resolvers hold the old answer until its TTL runs out. The "propagation" is the slow drain of stale cache entries.

That has one practical consequence. You can't speed it up after the fact. You can only wait out the TTL that was already cached.

For the longer version, read what DNS propagation is and the entry on DNS TTL. The TTL is not "how long propagation takes". It is the longest any single cache may lag behind you. Propagation is the sum of every cache between you and a user, each on its own countdown.

How long DNS propagation takes (by TTL)

The wait is bounded by the TTL on the record as it was cached before your change.

TTL on the old record	Worst-case wait
60 seconds	1–2 minutes
300 seconds (5 min)	5–10 minutes
3600 seconds (1 hour)	1–2 hours
86400 seconds (24 hours)	24–48 hours

Rule of thumb: worst case is roughly TTL × 2. Some resolvers don't honor TTLs strictly, so leave yourself margin.

The famous "up to 48 hours" only applies if your TTL was 86400. If it was 300, you're done in minutes. Anyone telling you to wait two days for a 5-minute TTL is working from folklore.

Planned change? Do it in this order:

Lower the TTL on the record.
Wait out the old TTL, so the short one is what's cached everywhere.
Make the change.
Raise the TTL again.

Lowering the TTL at the same moment you change the value does nothing for entries already cached under the old one.

How to check DNS propagation (browser and curl)

In the browser: open the free DNS propagation checker, enter the hostname and pick a record type (A, AAAA, CNAME, MX, TXT or NS).

From the command line: the same check is a free, keyless REST endpoint. No key, no signup, CORS-enabled. The type defaults to A.

curl -s "https://api.domainee.dev/v1/tools/dns-propagation-checker?host=example.com&type=A" | jq

It queries public resolvers such as Cloudflare, Google, Quad9 and OpenDNS, and reports which ones see the same answer. You get JSON back.

Limits, stated plainly: 30 requests per minute and 500 per day per IP.

Need to script a wait-until-propagated step? The DNS propagation checker API reference has the details. Keep the polling gentle. This loop checks every 5 minutes and stops after 12 tries, which is one hour:

for i in $(seq 1 12); do
  curl -s "https://api.domainee.dev/v1/tools/dns-propagation-checker?host=example.com&type=TXT" | jq
  sleep 300
done

That's 12 requests an hour. Even left running all day, a 5-minute interval makes 288 requests, under the 500 per day cap. Polling every minute would not fit: that's 1,440 a day.

How to read the results

Four patterns cover nearly everything you'll see.

All resolvers agree on the new value. Propagation is done for those public resolvers. If your own machine still shows the old value, you're looking at a local or ISP cache.

Mixed results. Normal inside the TTL window. Some caches have expired, some haven't. Re-check after the wait from the table above.

All resolvers show the old value. The change probably never reached the authoritative server. Common causes: you edited the wrong zone, or the domain's nameservers point somewhere other than the DNS provider you're editing. Run an NS check to see which nameservers are authoritative, then use the DNS record lookup to confirm what the zone actually holds.

All resolvers agree on a value you didn't mean. That isn't propagation. It's a wrong record. A typo, a trailing dot, a stray duplicate. Waiting won't fix it.

One honest limit: a public-resolver checker can't see your ISP's resolver or your laptop's cache. It tells you what the public sees, not what your machine sees.

Propagation or wrong record? The custom-domain case

A classic Tuesday. Your customer adds a CNAME for their custom domain and writes: "it's not working."

The record to expect is a CNAME pointing to edge.domainee.dev. Check it with type=CNAME:

curl -s "https://api.domainee.dev/v1/tools/dns-propagation-checker?host=app.customer.com&type=CNAME" | jq

Read it with the patterns above:

Mixed results, some showing edge.domainee.dev: the record is right, caches are draining. Wait out the TTL.
Every resolver shows something else: the record is wrong or sitting in the wrong zone. Send your customer back to their DNS provider.
Every resolver shows edge.domainee.dev: DNS is fine. Look at the next layer.

Domainee does this for you on custom domains. We re-check every custom domain every 5 minutes, or on demand via POST /v1/domains/{id}/check, and report the result as monitorStatus:

curl -X POST https://api.domainee.dev/v1/domains/{id}/check -H "Authorization: Bearer sk_live_..."

monitorStatus	What it tells you
`dns_not_resolving`	The hostname isn't resolving yet. Check the record exists, then allow for the TTL.
`dns_incorrect`	The hostname resolves, but not to the expected target. Look at the record.
`pending_ssl`	DNS is fine. The certificate is next.
`active_ssl`	DNS is fine and SSL is live.

Other states are unknown, ssl_failed and ssl_expired. Read them in the same order as the checker: dns_incorrect is a record problem, dns_not_resolving may just be time, and pending_ssl or active_ssl means stop blaming DNS.

Apex domains are the awkward case. The DNS standard doesn't allow CNAME records at the apex, and some providers enforce that. Where an apex provider disallows CNAME, Domainee offers two anycast A records instead.

How to speed it up (and what doesn't work)

What works:

Lowering the TTL ahead of the change, then waiting out the old TTL.
Verifying the change at the authoritative server first, so you aren't waiting on a change that never landed.

What doesn't:

Waiting "for the internet to update." The cache expires on its own schedule.
Hammering the checker. Re-checking doesn't hurry any cache, and the free endpoint stops at 30 requests a minute.
Flushing your local cache. That fixes your machine only. Other resolvers keep their own countdowns.

FAQ

What is a DNS propagation checker?

A DNS propagation checker queries public DNS resolvers for a hostname and record type, then shows which resolvers return the new value and which still return the old one. It tells you whether a change has reached them yet.

How do I check DNS propagation?

Enter your hostname in the free DNS propagation checker and pick a record type. Agreement on the new value means the change has reached those resolvers. Mixed results mean caches are still expiring.

How long does DNS propagation take?

It depends on the TTL of the old record. A 60-second TTL means 1–2 minutes worst case, 300 seconds means 5–10 minutes, 3600 means 1–2 hours and 86400 means 24–48 hours. Worst case is roughly TTL × 2.

Why does DNS propagation take up to 48 hours?

Only when a record had a TTL of 86400 seconds (24 hours), and some resolvers don't honor TTLs strictly. With a short TTL you won't wait anywhere near that long.

Why do some resolvers show the new record and others the old one?

Each resolver caches the old answer on its own countdown. Those whose cache has expired fetch the new value. The rest keep serving the old one until their TTL runs out. Mixed results inside the TTL window are normal.

Can I speed up DNS propagation?

Not after the change. Resolvers hold the old answer until the TTL expires, and nothing is pushed to them. Lower the TTL before a planned change, wait out the old TTL, then make the change.

How do I check DNS propagation from the command line?

Run curl -s "https://api.domainee.dev/v1/tools/dns-propagation-checker?host=example.com&type=A" | jq. It needs no key and no signup. The type defaults to A. Limits are 30 requests per minute and 500 per day per IP.

Why does my DNS change show in the checker but not on my computer?

The checker queries public resolvers. Your computer, router or ISP resolver may still hold the old answer in its own cache. Flushing your local cache fixes your machine. The ISP's cache expires on its own TTL countdown.

Is it propagation or did I set the record wrong?

Mixed results inside the TTL window are propagation. If every resolver shows the old value, the change likely never reached the authoritative server. If every resolver agrees on a value you didn't intend, the record is wrong. Check the nameservers and the DNS record lookup.

Does a lower TTL make propagation faster?

Yes, but only if it was lowered before the change and the old TTL has expired. Caches already holding the record keep it for the TTL they were given. A short TTL shrinks the wait for the next change.

Which record types can I check?

A, AAAA, CNAME, MX, TXT and NS. The type defaults to A when you don't pick one.

Check the record you just changed

Run the free DNS propagation checker on the hostname you just changed. It takes no signup.

If you run a SaaS and your customers connect their own domains, Domainee monitors every custom domain's DNS every 5 minutes. 20 custom domains are free, forever. Start at domainee.dev/sign-up.

Domainee by Common Ninja is a custom-domains-as-a-service API for SaaS products, with automatic SSL, DNS monitoring and webhooks.