Quick Summary
Query the record from several resolvers and compare what comes back. An online checker does this for you, and so do the dig and nslookup commands. The first thing to look at is the TTL on the old record, because that number decides most of how long the change takes. Until it expires, expect some resolvers to hand you the old answer and some the new one.
- Look up the TTL on the old record before anything else. It sets the timeline.
- A TTL of 3,600 seconds means a resolver can hold the old answer for an hour.
dig @8.8.8.8asks one named public resolver what it currently has cached.- If resolvers still show the old value, go straight to the authoritative nameserver.
- Disagreement between checkers usually means the old TTL has not run out yet.
What DNS Propagation Means and How It Differs From DNS Caching
DNS propagation is the lag between making a change and the rest of the world seeing it. The authoritative server has the new record as soon as your DNS host publishes it. Every other server keeps handing out the old answer until the copy it saved expires, and there is nothing you can do from your side to hurry that along.
Propagation and caching get used interchangeably, which is where a lot of the confusion starts. Propagation describes the spread. Caching describes why the spread is slow: each resolver keeps the answer it received for as long as the record's TTL (time to live) told it to.
So the TTL is the number worth looking at. A record with a TTL of 3,600 seconds can sit in a cache for a full hour after you have already changed it. Drop the TTL before a change you know is coming and the old answer expires sooner. I have never regretted doing that, and I have definitely regretted skipping it.
Using an Online DNS Propagation Checker
An online DNS propagation checker shows you a record from many locations at once. Enter the domain, pick the record type, run the check, and it queries resolvers in different regions and prints what each one returned.
They all work the same way, so which tool you pick matters less than reading the output correctly:
- Enter the full domain, such as
example.com - Select the record type that changed, such as A, CNAME, MX, TXT, or NS
- Run the lookup and compare the answers across locations
- Note which locations show the new value and which still show the old one
A split result is not a fault. It is what partial propagation looks like. The checker reports a state; it has no way to push anything along, so treat it as a signal for when to look again rather than a lever. If you want the wider picture of how these records affect delivery, we cover that in a fuller guide to email authentication and inbox placement.
Checking Records From the Command Line With dig
The point of dig is that you choose which server answers you, which no browser-based checker lets you do with the same precision. It ships with macOS. On Linux it comes in the dnsutils or bind-utils package, so install that if dig is not found. From a terminal, with your own domain in place of example.com:
dig example.com A +short
dig @8.8.8.8 example.com A
dig example.com NS +short
The first returns the current A record. The second asks one specific public resolver, so you see what that resolver has cached rather than some average of the internet. The third lists the nameservers for the domain, which is what you want after a nameserver change.
Then compare the TTL in the full output, the number in the second column, against what you expect to see. A TTL that drops by a few seconds each time you rerun the command is a cached answer counting down.
Checking Records With nslookup on Windows and macOS
nslookup runs on Windows, macOS, and Linux, and it checks a record without installing anything extra. Open a terminal or Command Prompt and run these, again with your own domain in place of example.com:
nslookup -type=A example.com
nslookup -type=TXT example.com 8.8.8.8
On Windows you can flush your local DNS cache first with ipconfig /flushdns. On macOS the flush command changes between releases, so look up the one for your version. Worth being clear about what flushing does, though: it clears your own machine and nothing else. Every other resolver still holds whatever it held a second ago.
How Long DNS Propagation Time Really Takes
Propagation time follows the TTL of the old record more than anything else. If that TTL was 300 seconds, most resolvers pick up the change within minutes. If it was 86,400 seconds, some of them will keep serving the old answer for a full day, and they are not misbehaving by doing so.
You have probably seen the 24 to 48 hour figure. It is a planning cushion, not a measurement, and it is wildly pessimistic for a short TTL and occasionally optimistic for a nameserver change.
Nameserver changes tend to run longer, because they depend on the parent zone and on how each resolver refreshes its delegation data.
All of which is an argument for lowering the TTL a day before you touch anything, when you can plan that far out. A 300 second TTL turns a day of waiting into a coffee break. The cost is a few more queries hitting your DNS host in the meantime, which nobody is going to notice.
| Old TTL | What to expect | Note |
|---|---|---|
| 300 seconds | Most resolvers update within minutes | Short TTL, fast change |
| 3,600 seconds | Can be cached for up to an hour | Common default |
| 86,400 seconds | Some resolvers may hold the old answer for a full day | Long TTL, slow change |
| Nameserver change | Can take longer | Depends on parent zone and delegation refresh |
What to Do When Results Disagree or Stay Old
When checkers disagree, go back to the TTL and wait until the old one has passed. If the answers still conflict after that, something else is wrong, and these are the usual suspects:
- Confirm the change actually saved at your DNS host
- Query the authoritative nameserver directly: get its name from
dig NS yourdomain.com +short, then rundig @followed by that name and your domain (our guide to querying authoritative DNS servers with dig covers reading theaaflag and comparing SOA serials) - Check for a typo in the record value or the record name
- Make sure a second set of records is not conflicting with the first, such as two A records, or a CNAME sitting alongside other records
- Look for a stale record left behind by a migration
If the authoritative server returns the new value and public resolvers do not, it is caching almost every time, and the fix is patience. Checking the same record from resolvers in several regions shows which ones are still holding on. If the record you changed is a DMARC policy, our walkthrough of setting up DMARC at a small business covers checking that it was published the way you intended.
Confirming Your Change Is Live Before You Move On
Once the authoritative server and most public resolvers return the new value, do one more pass: query from two different resolvers, confirm the TTL matches what you set, then test the service itself by loading the site or sending a message through it. There is a longer version of this for a full sending domain setup in our afternoon guide to configuring a sending domain, and if you want to double-check the signing side, see how to configure DKIM for custom domains.
One habit worth stealing: keep a plain text file with the record type, the old value, the new value, and the time you made the change. It takes about ten seconds, and it has stopped me more than once from debugging a change I made myself.
FAQ
How long does DNS propagation take?
It follows the TTL of the old record. A 300 second TTL means most resolvers update within minutes; an 86,400 second TTL means some can serve the old answer for a full day. The familiar 24 to 48 hour figure is a planning cushion, not a measurement, and nameserver changes tend to run longer because they depend on the parent zone and delegation refresh.
Can I speed up DNS propagation?
Not after the fact. You can only lower the TTL before a change you know is coming, so the old answer expires sooner. Flushing your local cache with ipconfig /flushdns clears your own machine and nothing else; every other resolver still holds whatever it held a second ago.
Why do DNS checkers show different results?
A split result is normal partial propagation, usually because the old TTL has not run out. If answers still conflict after it has, confirm the change saved at your DNS host, query the authoritative nameserver directly, check for typos, and look for conflicting or stale records.
How do I check a DNS record from the command line?
Use dig example.com A +short for the current record, dig @8.8.8.8 example.com A to see what one named public resolver has cached, and dig example.com NS +short after a nameserver change. On Windows, nslookup -type=A example.com does the same job without installing anything.