DNS TTL is one of those settings nobody thinks about until it bites them. Then they think about it a lot.
This guide explains what DNS TTL is, how it works in plain language, and how to pick the right value for your records. By the end you will know what to set, when to change it, and why it matters when you migrate to a new server.
What is DNS TTL?
TTL stands for Time To Live.
A DNS TTL is the number of seconds that a DNS record can be cached. Caching just means saving a copy. When you set a TTL of 3600, you are telling every DNS resolver in the world that they can save a copy of your record for one hour before they have to come back and ask for it again.
The shorter the TTL, the faster a change to your record reaches users. The longer the TTL, the less work your DNS provider has to do.
That is the whole tradeoff.
How DNS caching actually works
To understand TTL, you need to understand caching.
When a user types your domain into a browser, their computer asks a DNS resolver "what is the IP address for example.com?" The resolver checks its cache. If it has a fresh answer, it returns it. If not, it asks the authoritative DNS server for your domain. That server returns the answer along with a TTL. The resolver stores the answer and the TTL, and uses that cached copy for any future requests until the TTL expires.
Every resolver in the chain does this. Your ISP. Cloudflare's 1.1.1.1. Google's 8.8.8.8. Your office router. Your laptop's local DNS cache.
So when you change a DNS record, the change is not instant. Old copies float around in caches all over the world. They only get refreshed when the TTL expires and somebody asks for the record again.
The TTL is the maximum time a stale copy can stick around.
What does a TTL of 3600 mean?
A TTL of 3600 means 3600 seconds, or one hour.
If you set the TTL on your A record to 3600 and then change the IP address an hour later, every resolver that cached the old copy will hold onto it for up to 60 minutes. Some users will see the new IP within seconds. Others might see the old IP for the full hour. After that, every cache will refresh.
In practice, propagation usually takes longer than the TTL, because not every resolver checks at the same time, and some misbehaving resolvers ignore your TTL and keep records longer than they should.
This is why people say DNS changes take 24-48 hours. They actually take as long as your TTL plus a fudge factor for misbehaving caches.
Common TTL values and what they mean
Here are the values you will see most often.
60 (one minute). Used right before a migration. Very low. Your DNS provider will see more traffic, but your changes will reach users almost instantly.
300 (five minutes). A good "ready to change" TTL. Low enough that updates roll out quickly. High enough that you are not slamming your DNS provider with extra queries.
1800 (thirty minutes). A reasonable default for production records that change occasionally.
3600 (one hour). The most common production TTL. A solid balance for most websites.
14400 (four hours). Used when records almost never change. Reduces DNS load.
86400 (twenty-four hours). Used for records that should be cached for a full day. NS records often use this.
172800 (forty-eight hours). The maximum recommended. Useful for records that never change, like SOA records.
If you are not sure, 3600 is a fine default for almost everything.
How to choose the right TTL for your records
Different record types call for different TTL values.
A and AAAA records. These point to your web server. Most production sites use 3600 (one hour) here. If you change servers often, drop to 300 or 600. If you have a steady IP that never changes, you can go higher.
CNAME records. These alias one domain to another. CNAMEs are usually stable. A TTL of 3600 to 14400 works well.
MX records. These point to your mail server. Mail servers retry on failure, so a longer TTL is fine. 3600 to 14400 is normal.
TXT records. Used for SPF, DKIM, DMARC, domain verification, and more. These rarely change once set up. 3600 is fine. Some teams use 14400.
NS records. These point to your authoritative name servers. Almost never change. 86400 (one day) is standard.
SOA records. These hold metadata about your zone. Almost never change. 86400 to 172800.
The rule is simple. Records that change often need lower TTLs. Records that never change can have higher TTLs.
The most important TTL rule: lower it before a migration
This is the one TTL trick every team should know.
When you plan to move your website to a new server, change your DNS provider, or update an A record for any reason, lower the TTL well in advance.
Here is the playbook.
Step 1. Two days before the change, drop the TTL on the records you are about to change. Set them to 300 (five minutes) or 60 (one minute) if you want fast cutover.
Step 2. Wait at least as long as the old TTL. If your old TTL was 3600, wait at least an hour. Better, wait the full 24 hours. This guarantees that every cache in the world has refreshed and pulled the new low TTL.
Step 3. Make your real change. Update the IP address, switch providers, whatever the migration is. Because the TTL is now 60 or 300, the change reaches users in minutes instead of hours.
Step 4. Once the migration is stable and you are confident nothing will roll back, raise the TTL back to a normal value like 3600.
If you skip step one and just change the record cold, you can leave users staring at the old server for up to your old TTL. For a 24-hour TTL, that is a full day of stale cache. People will email you. The CEO will email you.
Lower the TTL first. Always.
The downsides of a low TTL
Low TTLs are not free.
Every time a cache expires, every resolver has to query your authoritative DNS server again. With a TTL of 60, that is up to 60 times more queries per hour than a TTL of 3600.
Most managed DNS providers handle this load fine. Cloudflare, AWS Route 53, NS1, and DNS Made Easy all charge by query volume, but for typical small-to-mid sites the difference is pennies a month.
The real concern with very low TTLs is what happens if your DNS provider has a problem. With a long TTL, caches keep serving the right answer even if your DNS server is briefly unreachable. With a short TTL, caches expire fast and users start hitting failures sooner.
For mission-critical records, do not run low TTLs all the time. Lower them only when you are about to change something.
How to check the current TTL of any record
You can see the TTL on any record using a few quick tools.
dig (Mac, Linux). Run
dig example.comand look for the number right before theIN Aline. That is the TTL in seconds.nslookup (Windows). Use the verbose mode:
nslookup -type=a -debug example.com. The TTL is shown in the answer section.DNS Spy. Just type your domain into dnsspy.io/scan. The TTL is shown for every record, alongside warnings if the value is unusual or risky.
If you want to know what TTL a specific resolver is currently caching, check both the authoritative TTL (what you set) and the resolver TTL (the time remaining on the cached copy). The resolver TTL counts down. The authoritative TTL is the number that resets the countdown when the cache refreshes.
Common TTL mistakes
A few patterns we see all the time.
Mistake 1: Forgetting to lower TTL before a migration. The classic. You move your site, the new IP works for some users, but a chunk of traffic keeps hitting the old server for hours. Always lower the TTL two days before any change.
Mistake 2: Leaving a low TTL forever. If you dropped to 60 for a migration, raise it back. Long-term TTLs of 60 add load and risk.
Mistake 3: TTL of 0. Some DNS UIs let you set TTL to 0. Some resolvers respect this and never cache. Others ignore it and use a default. The result is unpredictable. Do not use 0.
Mistake 4: Mismatched TTLs across related records. If your A record has TTL 60 but your NS record has TTL 86400, the NS record will hold caches hostage. Match TTLs across records that need to fail over together.
Mistake 5: Trusting the TTL exactly. Even with a TTL of 60, some caches will hold onto records longer than they should. Most ISPs and corporate networks have at least one resolver in the chain that ignores TTLs. Plan for that.
TTL and DNS monitoring
If you run any service that depends on DNS, you should watch your TTLs.
A TTL that suddenly drops or rises unexpectedly is a signal. Maybe a teammate made a change without telling anyone. Maybe a script updated a record incorrectly. Maybe your DNS provider had an outage and reverted to defaults.
DNS Spy watches every record on your domain and alerts you when TTLs change, when records are added or removed, and when settings drift from what they should be. You can start a scan now to see what your current TTLs are and where the risks are.
Quick TTL cheat sheet
A and AAAA records: 3600 (one hour) for most sites
CNAME records: 3600 to 14400
MX records: 3600 to 14400
TXT records: 3600
NS records: 86400 (one day)
SOA records: 86400 to 172800
Before a migration: drop to 300 or 60, two days in advance
After a migration: raise back to normal once stable
Final thought
TTL is one of those tiny DNS settings that decides whether your next migration goes smooth or makes the whole team sweat for a day.
Pick a sensible default. Lower it before changes. Raise it back when you are done. And monitor your records so a wrong TTL never catches you off guard.
If you want a fast read on every record on your domain, including TTLs, run a free scan at dnsspy.io. It takes about ten seconds and tells you exactly what is set, what is missing, and what to fix.
