DNS propagation: what it is and how to speed it up

You updated a DNS record, triple-checked the values, saved your changes, and…nothing happened. Your browser still shows the old site. Your email authentication still isn’t passing. So you refresh the page. Again. And again.

This is DNS propagation at work. It’s the process that sits between making a DNS change and the rest of the internet catching up to it. 

For better or worse, nothing is broken. It’s just not instantaneous.

Whether you’re updating Sender Policy Framework (SPF) records, swapping nameservers, or pointing a domain to a new host, understanding how DNS propagation works (and what you can do to speed it up) will save you a lot of unnecessary troubleshooting. 

The biggest takeaway: it’s not a you problem. It’s just DNS propagation.

Below, we’ll walk through what DNS propagation is, how long it takes, and what’s in (and out of) your control.

What is DNS propagation?

DNS propagation is the process of distributing updated Domain Name System (DNS) records across the global network of DNS servers. When you make a change to a DNS record (like an A record, MX record, or TXT record), that update doesn’t go live everywhere at once. It starts at your authoritative nameserver and gradually spreads to caching servers around the world.

DNS doesn’t work like a single database with one master copy. It’s a distributed system. Your authoritative nameserver holds the official version of your records, but millions of recursive resolvers around the globe keep their own cached copies to avoid hammering that server with repeat requests. 

When you change a record, those cached copies don’t update simultaneously. Each resolver holds onto its old copy until it expires, then goes back to the source for a fresh one.

That gap between your change going live on the authoritative server and every resolver picking up the new version is DNS propagation. Ultimately, it’s a feature, not a flaw.

How DNS propagation works

Here’s what happens after you hit save on a DNS change:

1. You update a record on your authoritative nameserver. This is the source of truth for your domain’s DNS information.
2. Secondary nameservers sync with the primary. They check in periodically (based on something called the refresh interval) or get notified proactively through a mechanism called DNS Notify.
3. Recursive resolvers still have the old record cached. These are the servers your browser, email client, and other applications query when they need to look up a domain. They don’t go directly to your authoritative server every time. Instead, they serve a cached copy of the record until it expires.
4. The cache expires, and the resolver fetches the new record. Once the cached copy hits its expiration (determined by the record’s Time to Live, or TTL), the resolver goes back to the authoritative server and pulls the updated information.

That’s propagation. It’s not a single event. It’s thousands of servers independently deciding when to refresh their copy of your DNS data.

How long does DNS propagation take?

You’ve probably seen the “24-48 hours” disclaimer on every DNS provider’s help page. That number is… conservative, to put it politely.

Honestly, most DNS changes propagate within minutes to a few hours. The worst-case scenario for full global propagation is determined by a simple formula:

Maximum propagation time = TTL + refresh interval

If your record has a TTL of one hour and your zone’s refresh interval is 30 minutes, you’re looking at 90 minutes max. Not two days. The 24-48 hour warning is a catch-all that accounts for unusually high TTL values, aggressive ISP caching, and the occasional edge case. 

For most setups, it’s overkill.

That said, there are situations where propagation legitimately takes longer, and most of them come down to the factors below.

What affects DNS propagation time

Not all DNS changes propagate at the same speed. A few happen instantaneously, others take a while, and some are completely out of your control.

Factor	What it controls	Can you control it?
TTL (time to live)	How long resolvers cache a record before refreshing	Yes
Refresh intervals	How often secondary nameservers sync with the primary	Yes (if self-hosting)
DNS Notify	Whether the primary server proactively pushes updates to secondaries	Yes (provider-dependent)
ISP caching behavior	How aggressively an ISP caches records (sometimes beyond TTL)	No
Record type	NS changes propagate slower than A, TXT, or MX changes due to higher default TTLs	Partially

1. TTL (time to live): This is the single biggest factor. TTL tells caching resolvers how long they can hang onto a record before checking for an update. A TTL of 300 seconds (five minutes) means resolvers will refresh your record within five minutes of it expiring. A TTL of 86,400 seconds (24 hours) means they might not check back for a full day. If you’re planning a change, lowering your TTL in advance is one of the most effective things you can do.
2. Refresh intervals: This controls how often your secondary nameservers sync with the primary. Shorter refresh intervals mean your own nameservers stay in sync faster. Most modern DNS providers keep this tight, but it’s worth checking if you’re self-hosting.
3. DNS Notify: Some DNS setups use a feature called DNS Notify, where the primary server proactively pings secondary servers when a change is made (rather than waiting for the next refresh cycle). This can reduce sync time between your authoritative servers to seconds.
4. ISP caching behavior: Here’s the part you can’t control. Some internet service providers (ISPs) cache DNS records more aggressively than others, sometimes ignoring TTL values entirely and holding onto records longer than they should. There’s no way around this other than waiting it out.
5. Record type matters: Changing an A record or a TXT record typically propagates faster than swapping nameservers. NS record changes happen at the registrar level, where default TTLs tend to be higher (often 24-48 hours). That’s one reason nameserver migrations feel like they take forever.

How to check DNS propagation

Here are a few ways to verify whether your changes have gone live yet:

• DNS propagation checkers: Free online services let you query your domain’s DNS records from servers in different geographic locations around the world. This gives you a real-time map of where your changes have propagated and where they haven’t. A few well-known options include Valimail’s domain checker and dnschecker.org.
• Command-line queries: If you’re comfortable in a terminal, dig and nslookup let you query specific DNS resolvers directly.
• Check from multiple locations. A resolver in New York might have your updated record while one in Tokyo is still serving the old version. Checking from a single location only tells part of the story.

5 ways to speed up DNS propagation

You can’t snap your fingers and push a DNS change to every resolver on the planet (wouldn’t that be nice?). However, you can set yourself up for the fastest possible propagation:

1. Lower your TTL before making changes. If your current TTL is 24 hours, drop it to 300 seconds (five minutes) at least 24-48 hours before you plan to make your actual change. That way, by the time you update the record, most resolvers will already be checking back frequently.
2. Use a DNS provider that supports DNS Notify. Providers that push updates proactively to secondary servers eliminate the wait for the next refresh cycle. Most reputable managed DNS providers support this by default.
3. Keep your records clean. Unnecessary complexity in your DNS zone doesn’t directly slow propagation, but it increases the chance of misconfigurations that can look like propagation issues.
4. Verify changes on the authoritative server first. Confirm that your authoritative nameserver is actually serving the correct record. If the source of truth is wrong, nothing downstream will be right.
5. Raise your TTL back up after the change. Once you’ve confirmed propagation, bump the TTL back to a reasonable value (3,600 seconds is common). Running a permanently low TTL increases the query load on your nameservers without much benefit outside of migration windows.

What you can’t control (and why that’s okay)

Some things are just out of your hands. ISPs that ignore TTL values, legacy resolvers with stale caches, and geographic variance in propagation speed are all realities of how DNS works at a global scale. 

You’re not going to force propagation across every server on the internet, no matter what a forum post tells you…sorry, Reddit.

The good news is that the things you can control (TTL, provider choice, clean records, pre-change planning) cover the vast majority of propagation delays. 

Focus on those, and the rest will sort itself out.

Why DNS propagation matters for email authentication

Every time you update an SPF record, rotate a DKIM key, or adjust a DMARC policy, propagation determines how quickly those changes take effect. If a record hasn’t propagated yet, legitimate email sent during that window could fail authentication and get bounced or flagged as spam.

This is one of the reasons Valimail’s platform automates SPF, DKIM, and DMARC configuration, so you spend less time managing DNS records by hand and more time focused on the things that matter. 

Check your domain or sign up for Valimail Monitor for free to get full visibility into your sending services and authentication status.

Frequently asked questions

What does DNS propagation mean? 

DNS propagation is the process of distributing updated DNS records from your authoritative nameserver to caching servers around the world. Until propagation is complete, some servers may still return the old version of your record.

Can you force DNS propagation? 

Not globally. There’s no way to push a DNS update to every resolver on the internet at once. You can flush your local DNS cache, and you can lower your TTL ahead of time to speed things up. Still, the rest is a waiting game.

Does changing nameservers take longer to propagate? 

Yes. Nameserver (NS) record changes are managed at the registrar level, where default TTL values tend to be significantly higher than those on individual records like A, MX, or TXT. It’s common for nameserver changes to take 24-48 hours to fully propagate, even when other record types update within minutes.