TTL, or Time to Live, is a DNS setting that controls how long a DNS record is cached by resolvers, browsers, operating systems and other systems before it is checked again. It is one of the most important DNS record settings because it affects how quickly DNS changes take effect and how often DNS servers are queried.
If you are updating website hosting, changing mail providers, moving a domain, or troubleshooting DNS propagation, understanding TTL helps you plan the change properly. A shorter TTL can help changes spread more quickly, while a longer TTL can reduce DNS query traffic and improve caching efficiency.
What TTL means in DNS
DNS translates domain names such as example.com into information that computers can use, such as IP addresses and mail routing details. Each DNS record can include a TTL value, usually measured in seconds.
When a DNS resolver looks up a record, it stores the result in cache for the length of the TTL. Until that time expires, the resolver will usually continue serving the cached result instead of requesting a fresh copy from the authoritative DNS server.
For example, if an A record has a TTL of 3600 seconds, a resolver may cache that result for 1 hour. If the record is changed during that hour, users relying on that resolver may still see the old value until the cache expires and a new lookup is performed.
Why TTL is important
TTL affects both performance and change management.
* A lower TTL allows DNS changes to be picked up sooner after caches expire.
* A higher TTL reduces repeated DNS lookups and can improve efficiency.
* TTL influences how long old DNS information may continue to be used after a record has been updated.
* TTL planning is especially important before website migrations, email cutovers, DNS failover changes and provider moves.
How TTL works in practice
When a user visits a website or sends an email, several systems may cache DNS data. These can include:
* Recursive DNS resolvers operated by internet providers or public DNS services
* Local operating system DNS caches
* Application-level caches, such as web browsers
Although the authoritative DNS zone defines the TTL for the record, real-world propagation can still vary because different systems may refresh at slightly different times, and some software may apply its own caching behaviour.
This is why a DNS update may appear to work immediately for one user but not for another.
Common TTL values
TTL values are generally expressed in seconds. Common examples include:
* 300 seconds = 5 minutes
* 600 seconds = 10 minutes
* 1800 seconds = 30 minutes
* 3600 seconds = 1 hour
* 14400 seconds = 4 hours
* 86400 seconds = 24 hours
Shorter TTL values are often used when a DNS change is expected soon. Longer TTL values are commonly used for stable records that do not change often.
When to use a lower TTL
A lower TTL is useful when you expect to change a record and want the update to be recognised sooner once caches refresh.
Common examples include:
* Moving a website to a new hosting server
* Changing the IP address of a server
* Updating MX records during an email migration
* Testing DNS changes
* Preparing for a planned service cutover
In these situations, it is common to reduce the TTL before making the actual DNS change. This should ideally be done at least one full current TTL period in advance so that existing caches have time to expire under the old value.
When to use a higher TTL
A higher TTL may be a better choice when records are stable and are unlikely to change often.
Benefits can include:
* Fewer repeated DNS lookups
* Reduced load on authoritative DNS servers
* More efficient caching for commonly requested records
For example, if your main website IP address rarely changes, a longer TTL may be perfectly suitable.
Example of TTL during a DNS change
Suppose your website A record currently points to an old server and has a TTL of 86400 seconds, which is 24 hours.
If you change that record now, some resolvers may continue using the old IP address for up to 24 hours from the time they last cached it. That can make a migration appear inconsistent.
A better approach may look like this:
1. Reduce the TTL from 86400 to 300 well before the planned migration.
2. Wait long enough for the previous 86400-second cache period to expire.
3. Change the DNS record to the new value.
4. Allow resolvers to refresh and begin using the new record more quickly.
5. Increase the TTL again later if a longer cache period is preferred.
Important limitations of TTL
TTL helps control caching behaviour, but it does not guarantee an exact propagation time for every user.
Keep in mind:
* Some resolvers may not refresh immediately the moment TTL expires.
* Some devices or applications may retain cached data temporarily.
* Negative caching can affect how quickly newly created records are recognised.
* DNS propagation depends on the behaviour of external resolvers, not only the DNS zone itself.
Because of this, DNS changes should always be planned with some allowance for propagation time.
Best practices for TTL management
* Use a shorter TTL before planned DNS changes.
* Reduce TTL in advance, not at the same time as the change.
* Use longer TTL values for stable production records where frequent updates are not expected.
* Avoid making TTL unnecessarily low for all records on a permanent basis.
* Confirm that the DNS record was updated correctly at the authoritative source.
* Test from multiple networks or public DNS resolvers if you need to verify propagation.
Common mistakes
* Lowering the TTL immediately before a migration and expecting instant propagation.
* Assuming TTL is the only factor affecting DNS update visibility.
* Forgetting that users may still be affected by local or resolver-level caching.
* Leaving critical records on very long TTLs when frequent changes are expected.
* Setting all records to extremely short TTLs without a specific reason.
Troubleshooting TTL-related issues
DNS change is not visible yet
The most common cause is cached DNS data still being used by one or more resolvers.
Check the current authoritative record value and compare it with what public resolvers are returning. If the authoritative value is correct, additional waiting may be required while caches expire.
Some users see the new site and others see the old site
This usually means different resolvers refreshed at different times. It is a normal part of DNS propagation after a change.
If the DNS zone is configured correctly, this inconsistency should reduce as caches expire.
Email is still being delivered to the old mail provider
If MX records were changed recently, remote mail servers may still be using cached DNS data. This can continue until the old TTL period has expired on those systems.
During an email migration, it is a good idea to lower TTL in advance and keep old services available during the transition where possible.
Frequently Asked Questions
What is a good TTL value for most DNS records?
A suitable TTL depends on how often the record changes. A common default is 3600 seconds, or 1 hour, because it provides a balance between caching efficiency and flexibility.
Does a lower TTL make DNS changes instant?
No. A lower TTL can help changes be recognised sooner after caches expire, but it does not make updates instant for every resolver or device.
Should I always use the lowest possible TTL?
No. Very low TTL values can increase DNS query traffic and are usually only necessary when records are expected to change soon or frequently.
Can TTL affect website and email migrations?
Yes. TTL is especially important during migrations because it affects how long old DNS information may continue to be used after a record is changed.
Related Articles
* What is DNS?
* DNS Propagation Explained
* A Record Explained
* MX Record Explained
* How to Change DNS Records
* Nameservers vs DNS Records
Need More Help?
If you require further assistance, please contact Apexhost Support at support@apexhost.com.au.
