DNS Propagation Checker

A DNS propagation checker shows whether a DNS change you have just made is visible to the rest of the internet yet, or whether resolvers are still handing out the old answer. Our tool asks five large public resolvers for the same record at the same moment, compares what they return and tells you whether the change is fully propagated, still propagating or not found anywhere. It also shows the longest cache time left, so you know whether to wait or go back and look for a mistake.

How to use the DNS propagation

1. 1 Enter the exact hostnameType the name you changed, such as example.co.uk, www.example.co.uk or _dmarc.example.co.uk. The record must be checked at the name where it lives.
2. 2 Choose the record typePick A, AAAA, MX, TXT, NS or CNAME to match the record you edited. The default is A.
3. 3 Run the propagation checkSign in with your free account and run the check. All five resolvers are queried in parallel.
4. 4 Act on the resultIf it says still propagating, wait for the TTL shown. If no record is found anywhere, check the name and the nameservers you edited, then run it again after about ten minutes, when our cached result expires.

Why DNS changes take time to appear

Every DNS record has a TTL (time to live) in seconds. When a recursive resolver, such as the one run by your broadband provider or Google's 8.8.8.8, looks up your record, it keeps the answer for that long and serves it to anyone who asks without checking again. When you change the record at your DNS host, the authoritative nameservers start giving out the new value immediately, but every resolver that already cached the old one keeps using it until its copy expires.

That is all propagation really is. A record with a TTL of 3600 can be out of date in some caches for up to an hour after you change it, and one with 86400 can lag for a day. Negative answers are cached too: if a resolver looked up a name before it existed, it remembers that the name does not exist for a period set by the zone's SOA record, often between five minutes and an hour, as described in RFC 2308.

Which resolvers our DNS propagation checker asks

Our DNS propagation checker queries five well-used public resolvers over DNS-over-HTTPS: Cloudflare (1.1.1.1), Google (8.8.8.8), AdGuard, which answers from Europe, Alibaba, which answers from Asia, and NextDNS on its anycast network. Between them they serve a large share of the world's DNS traffic and run caches in many locations, so if all five agree, the change has very likely reached most users.

It is not a test of every resolver on the internet. Your own broadband provider, such as BT, Sky, Virgin Media or TalkTalk, runs its own caches, as do company networks and mobile operators. Those caches follow exactly the same TTL rules, so the remaining TTL we show is a good guide to how long they may take too, but a private cache can still hold an old answer a little longer if it was refreshed just before your change.

Understanding the propagation result

For the record type you choose, we keep only answers of that exact type, sort the values and compare them across every resolver that responded. If a resolver times out, it is left out of the comparison instead of counting as a mismatch. You then get one of three outcomes, plus a cache time where one is available.

• Fully propagated: every resolver that answered returned the same set of values. The detail shows how many of the five agreed.
• Still propagating: resolvers returned different answers, so at least one still has the old record cached. The detail shows how many distinct answers we saw. Nothing needs doing except waiting.
• No record found: none of the resolvers returned a record of that type. Either the change is very new and a negative answer is cached, or the record is at a different name, of a different type, or on nameservers that are not live for the domain.
• Longest cache time left: the highest remaining TTL among the answers, shown in minutes or hours. This is the most you should need to wait for those resolvers.

Choosing the right record type to check

Checking the wrong type is the most common reason a propagation check looks wrong. A website move usually changes the A record (IPv4) and sometimes AAAA (IPv6). If www is an alias to another hostname, check CNAME on www rather than A. An email provider change means checking MX, while SPF, DKIM, DMARC and domain verification codes are all TXT records, and DKIM and DMARC live on special names such as selector1._domainkey.example.co.uk and _dmarc.example.co.uk. NS shows which nameservers the domain is delegated to.

One quirk to remember: when you ask for an A record on a name that is a CNAME, resolvers return the CNAME and then the final A records. Our checker compares only the A records, so the result reflects the IP addresses visitors will actually reach.

Planning a DNS change with minimal downtime

Good planning makes propagation almost invisible to visitors. The key is to lower the TTL well in advance, so caches already hold short-lived copies when you make the switch.

• At least one full old TTL before the change, reduce the TTL on the records you will edit to 300 seconds.
• Make sure the new server or service is ready and working before you update DNS.
• Change the record, then run the propagation check and watch the TTL count down.
• Keep the old server running until the check shows fully propagated and the longest TTL has passed.
• Once everything is stable, raise the TTL back to 3600 or more to reduce lookups and add resilience.

Nameserver changes behave differently

Moving a domain to a new DNS provider, such as switching to Cloudflare or a new host, changes the NS records at the registry. For .uk domains these delegations are held by Nominet and for .com by Verisign, and the parent zone hands them out with TTLs that are commonly one to two days. Resolvers that cached the old delegation keep asking the old nameservers until that expires.

To avoid an outage, copy every record to the new provider before changing the nameservers at your registrar, and leave the old zone in place for at least 48 hours. During that window some visitors use the old zone and some the new one, so both must give the same answers. Run the NS check to see which nameservers each resolver currently reports.

When the record never appears

If hours have passed, well beyond the TTL, and the check still reports no record, the change is not live on the nameservers the world is using. Waiting longer will not help. The usual reasons are that the record was added in a panel that is not authoritative for the domain, that the host field was filled in so that the panel appended the domain twice, or that the record was saved as a different type, for example a TXT value entered as a CNAME.

To confirm, run an NS check to see which nameservers the domain is delegated to, then query one of those nameservers directly with dig, as shown in the examples. If the authoritative server does not return your record either, the problem is in the zone itself, not in propagation. Fix it at the correct provider, and the change will usually show in our checker within minutes, since resolvers only hold a negative answer for a short time.

Examples you can copy

dig @1.1.1.1 www.example.co.uk A +noall +answer
dig @8.8.8.8 www.example.co.uk A +noall +answer

dig +short NS example.co.uk
dig @ns1.example-dns.net www.example.co.uk A +noall +answer

nslookup -type=TXT _dmarc.example.co.uk 8.8.8.8
ipconfig /flushdns

www.example.co.uk.  300  IN  A  203.0.113.10

Common mistakes to avoid

Frequently asked questions