How long does it take for DNS record changes to propagate?
Michael Ko
Co-founder & CEO, Suped
Published 3 Jul 2025
Updated 18 Aug 2025
6 min read
When you make a change to your domain's DNS records, whether it is for a new website, email provider, or security enhancement, a common question arises: how long will it take for these changes to take effect across the internet? This process, often referred to as DNS propagation, is not instantaneous. Instead, it involves a complex dance between various DNS servers around the globe.
While you might hear estimates ranging from a few minutes to 72 hours, the reality is nuanced. Several factors influence the actual propagation time, making it challenging to give a precise number. Understanding these elements can help you anticipate delays and plan your changes more effectively, especially when managing critical services like email deliverability.
The key to comprehending propagation lies in recognizing that DNS records are cached at various levels. Your computer, local network, internet service provider (ISP), and global DNS servers all store copies of DNS information to speed up lookup times. When you make a change, these cached copies need to expire and be refreshed before the new information becomes universally visible.
Understanding DNS propagation
DNS propagation is the process by which changes to your DNS records are updated across the global network of DNS servers. When you modify a record, such as changing an A record to point to a new IP address or updating an MX record for a different email server, the new information must be disseminated from your authoritative DNS servers to recursive DNS resolvers worldwide.
The common estimate of 24-48 hours for DNS propagation is largely due to the Time to Live (TTL) setting of your DNS records. TTL is a value that tells recursive resolvers how long they should cache a specific record before querying the authoritative name servers again for an update. If a record has a high TTL, say 24 hours, resolvers will hold onto that old information for up to 24 hours before checking for a new version.
It is important to note that the term “propagation” itself can be misleading. As some experts point out, DNS changes do not propagate in the same way a signal spreads. Instead, it is about caches expiring. Once your authoritative DNS servers are updated, they immediately serve the new information. The delay comes from various caching servers across the internet slowly refreshing their records based on the TTL.
Typical propagation times
Most DNS record changes are visible within a few hours, but it can extend up to 48 hours, or in rare cases, even 72 hours. This variability depends heavily on the specific recursive DNS servers being queried, their caching policies, and your record's TTL.
Factors impacting speed
Time to Live (TTL): This is the most significant factor. A higher TTL means longer caching and thus longer propagation times.
ISP caching: Internet service providers maintain their own caches, and some update more frequently than others.
Geographic location: DNS servers closer to your location or to major internet exchange points might update faster.
Type of record change: Adding a new record or deleting an old one can sometimes be affected by negative caching, which might introduce different delays compared to simply modifying an existing record.
The role of time to live (TTL)
The TTL value is a critical setting for any DNS record, including SPF, DKIM, and DMARC records. It is measured in seconds. For example, a TTL of 3600 seconds means that a record will be cached for 1 hour. A TTL of 86400 seconds means 24 hours. When you change a record, the old record will continue to be served by various caches until its TTL expires.
Lowering your TTL before a planned change is a common strategy to minimize downtime. If you anticipate a change, you can reduce the TTL of the relevant records to a very low value (e.g., 300 seconds or 5 minutes) at least 24-48 hours before the actual modification. This ensures that by the time you make the change, most caches would have expired, picking up the new record much faster.
However, keep in mind that a very low TTL can also increase the load on your authoritative DNS servers because recursive resolvers will query them more frequently. For stable records, a higher TTL is generally more efficient. It is a balancing act between speed of updates and server load.
TTL value
Caching duration
Impact on propagation
300 seconds (5 minutes)
Shortest caching, ideal for imminent changes.
Fastest propagation after TTL expires.
3600 seconds (1 hour)
Standard for many dynamic records.
Most changes visible within an hour, maximum 24 hours.
86400 seconds (24 hours)
Common for stable records like NS records.
Propagation can take up to 48 hours for full global visibility.
Monitoring and troubleshooting propagation
Even with a low TTL, it is common to experience delays. Sometimes, DNS resolvers might ignore the specified TTL or have longer internal caching policies. This can lead to situations where your changes do not appear to propagate as quickly as expected, even after waiting for the TTL to expire.
If you are troubleshooting, it can be helpful to flush your local DNS cache. This clears out any old records stored on your computer, forcing it to retrieve the latest information from a DNS server. While this does not affect global propagation, it ensures that your own device is seeing the most up-to-date records.
For ongoing monitoring or to quickly check the status of your DNS records, various online tools can query DNS servers from multiple locations worldwide. These tools provide a snapshot of how your DNS records are resolving globally, helping you determine if a change has propagated to critical regions.
Impact on email deliverability
For email deliverability, DNS propagation is especially crucial. Records like MX, SPF, DKIM, and DMARC directly impact how mail servers identify and authenticate your outgoing emails. Incorrect or unpropagated records can lead to delivery failures, messages landing in spam folders, or DMARC verification failures.
If you are migrating email services or changing email sending platforms, it is vital to account for DNS propagation time. Sending emails from a new setup before the MX records have fully propagated can result in emails bouncing or being sent to the old server. Similarly, issues with SPF or DKIM records can harm your sender reputation and affect inbox placement.
Before DNS propagation
When you make a DNS change, such as updating your MX records, the old records remain in various DNS caches across the internet until their TTL (Time to Live) expires. This means that for a period, different parts of the internet will still see your old DNS configuration.
Email behavior
During this transition period, some incoming emails might still be directed to your previous mail server, while others may start routing to the new one. Outgoing emails could also face authentication issues if the SPF or DKIM records for your new sending IP are not yet propagated across all receiving mail servers. This can result in bounces or mail being flagged as spam.
Risk to deliverability
Sending emails before full propagation increases the risk of deliverability problems. Recipients might not receive your emails, or your domain's reputation could suffer if emails are consistently rejected or sent to spam due to authentication failures or inconsistent routing.
After DNS propagation
Once the old DNS records have expired from caches and the new records have been distributed globally, all internet users and mail servers will see and use your updated DNS configuration. This typically means the new mail server is fully recognized and your authentication records are validated universally.
Email behavior
With full propagation, all incoming emails should reliably reach your new mail server. Outgoing emails will be correctly authenticated against your updated SPF, DKIM, and DMARC records, reducing the likelihood of bounces and improving email deliverability rates.
Minimized risk
Waiting for full propagation minimizes service interruptions and ensures a smoother transition for your email communications. It also helps maintain a strong sender reputation and avoids potential blocklisting issues that can arise from misconfigured DNS.
In summary
While DNS propagation can seem like an unpredictable beast, understanding its underlying mechanics, particularly the role of TTL, empowers you to manage the process more effectively. Patience is key, as is proactive planning, especially for critical services like email.
By setting appropriate TTLs and using the right tools to monitor your DNS changes, you can ensure a smoother transition and minimize potential disruptions to your online presence and email communications.
Views from the trenches
Best practices
Always lower your TTL (Time to Live) for critical DNS records at least 24-48 hours before any planned changes to ensure faster propagation.
Utilize online DNS checking tools that query multiple global servers to get a real-time view of your record's propagation status.
Flush your local DNS cache on your computer to ensure you are seeing the most up-to-date DNS information on your end.
Common pitfalls
Not accounting for the old TTL value, which can delay propagation much longer than expected.
Assuming DNS changes are instant everywhere, leading to premature actions that cause service interruptions.
Only checking DNS propagation from a single location or tool, missing regional delays.
Expert tips
Recursive DNS resolvers cache old values for a duration less than the TTL of the old record, so wait for the old TTL.
When adding a brand new record or deleting an old one then adding a new one, negative caching, which is controlled by the parent zone's SOA record, can make things more complicated.
Some DNS checking tools can avoid caching for longer than 60 seconds, regardless of TTL, which can be useful for quick checks.
Expert view
Expert from Email Geeks says that propagation is not an instantaneous process and cache time is determined by the TTL (Time to Live) for the domain.
2024-02-18 - Email Geeks
Expert view
Expert from Email Geeks says there isn't really such a thing as propagation in the traditional sense. Once data changes are at authoritative servers, new data is returned immediately, but recursive resolvers hold onto old values based on the old record's TTL.
