The most expensive moment in a DNS cutover is the gap between “we updated the record” and “the world agrees.” Until five major resolvers return the same answer, you cannot honestly tell a client the change is live, and you should not be flipping the next dependent change. PortJar’s DNS Propagation Checker exists to compress that confirmation step from a tab full of regional checkers into one query.
What the tool does
It fires the same DNS query in parallel against Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9, NextDNS, and OpenDNS over DNS-over-HTTPS, and lays the answers side by side. If all five agree, the record has effectively propagated — those resolvers serve the bulk of real-world traffic. If any disagree, the change is still rolling out and the previous record is still being served somewhere.
The five-resolver shape is deliberate. Anycast resolvers like Google and Cloudflare hide regional cache variation that a single-region check would miss. Looking at five independent vendors at once gives you a far better signal than hitting one resolver from twenty locations.
How to use it
Open portjar.com/tools/dns-propagation, enter the domain, and pick the record type that you actually changed — A, MX, NS, TXT, whatever it was. Run the check immediately after publishing the change, then again every few minutes until all five columns match the expected value.
Share the URL with the client when they ask whether the change has gone through. The answer they see is the same one you see, and it updates each time the page is loaded.
When you’d reach for it
- Right after a TTL-aware cutover — you lowered TTL to 300 the day before, published the new
Arecord at the cutover window, and you need to confirm propagation before you decommission the old origin. Read PortJar’s TTL reference if you want to understand why the previous TTL governs how long stragglers persist. - A nameserver delegation change at the registrar (
NSrecords) — these typically propagate slower than zone-level records and a single resolver can lag for hours. - A new
MXrecord on a domain being migrated from one mail provider to another — until propagation is complete, mail will split between the two destinations. - An
SPForDMARCchange where the receiver’s cached old policy is bouncing the mail you just authorized; checking propagation tells you whether to wait or to chase the receiver. - A failed certificate issuance that requires a fresh
_acme-challengeTXT record — the ACME server must see the new TXT before the challenge will validate, and a slow resolver can stall the renewal.
What to make of the output
All five resolvers returning the same value is the goal. Treat that as “propagated” and move on.
One resolver still serving the old value with the others updated almost always means that resolver has a cache TTL counting down. Wait for the previous record’s TTL and re-check. If the lone holdout persists past that window, there is usually an upstream caching layer (a corporate resolver, a Cloudflare zone with stale data, an ISP recursor) and the right move is to query the laggard from its own diagnostic endpoint, not to keep refreshing PortJar.
An empty answer from every resolver after a change should have appeared usually means the record was published with the wrong name — apex versus subdomain, missing trailing dot, wrong record type. Pop back to DNS Lookup and confirm the record actually exists where you expect.
Beware the false positive of “propagated fast.” If you check thirty seconds after publishing and all five resolvers agree on the new value, ask whether you are actually looking at the right zone — sometimes the record was already published and you re-saved an unchanged value.
Stack Harbor runs propagation checks at every cutover boundary as part of Deployment Management — they’re the cheapest possible insurance against announcing “we’re cut over” while a quarter of users still hit the old origin.