Domains and DNS

What is TTL in DNS, and what should I set it to?

“DNS propagation” is not a process that runs somewhere. It is just other people’s caches expiring, and TTL is the number that says when.

TTL (Time To Live) is a number of seconds attached to every DNS record, telling any resolver that fetches it how long it may serve the cached copy before asking again. A TTL of 3600 means one hour; 86400 means one day; 300 means five minutes. It is the only thing that decides how long a DNS change takes to reach everybody: worst case, a change is fully live one old-TTL after you make it. Lower the TTL to 300 at least one old-TTL before a migration, or the low value will not be cached in time to help you.

Worked out 2026-09-11 (IST) · resolvers that honour published TTLs, which most but not all do

What to set, by record type

Recommended TTLs
Record	Steady state	Before a planned change	Why
A / AAAA for a web server	3600 (1 hour)	300 (5 min)	Balances cache efficiency against a fast rollback
A / AAAA behind a CDN	60–300	Already low	The record is the traffic-steering mechanism
CNAME	3600	300	Follows whatever it aliases
MX	14400–86400	300, a day ahead	Mail routing rarely changes; a mistake here loses mail
NS	86400 (1 day)	3600, a week ahead	Registrar-level change; slow and hard to reverse
TXT (SPF, DKIM, DMARC)	3600	300	Verification and policy records you may need to correct fast
TXT (domain verification)	3600	—	Set once, then forgotten
SOA minimum	3600	—	Governs negative caching of names that do not exist

The migration timeline that actually works

Cutting over without losing traffic
When	Do this	Reason
T−48h	Lower the TTL on the records you will change to 300	Gives every cached copy of the old long TTL time to expire
T−24h	Verify with a lookup that the short TTL is being served	Confirms the change reached your authoritative servers
T−1h	Have the new server already answering for the name	So the moment DNS moves, it works
T	Change the record	Now only five minutes of cache stands between you and everybody
T+15min	Check from several networks and a mobile connection	Different resolvers, different caches
T+24h	Raise the TTL back to 3600	Restores cache efficiency and outage tolerance
T+7d	Only now decommission the old server	Stale caches, hardcoded IPs and old clients take longer than DNS

Where the time actually goes

A change reaches your authoritative name servers in seconds. Everything after that is caching, in this order: your DNS provider's own edge, the recursive resolver your visitor uses, that visitor's operating system, and the browser, which keeps its own short DNS cache regardless of what the record says. This is why one person sees the new site immediately and a colleague on the same office network does not — different caches, different ages, same record.

The full picture, including what to do when a resolver ignores your TTL entirely, is in how long DNS propagation actually takes.

Sources: IETF RFC 1034 and RFC 1035 (domain names), RFC 2181 (clarifications to the DNS specification), RFC 5321 (SMTP) and RFC 7505 (null MX).

Check your own numbers

Read the live records for any domain before and after you change them.

DNS LookupA, AAAA, MX, NS, TXT, CNAME and SOA records, live from the resolver.

Frequently asked

Why is my change not live even though the TTL has passed?

Three usual causes. Some public resolvers and many ISP resolvers enforce their own minimum TTL and ignore anything shorter. Your own operating system and browser cache separately from your resolver. And if you lowered the TTL at the same time as making the change, resolvers were still holding the OLD long TTL - the new short one only applies to copies fetched after the old one expired.

Does a low TTL hurt performance?

Slightly, and it costs you money only at scale. A lower TTL means more queries reaching your authoritative name servers, which for a normal site is invisible; for a domain serving billions of lookups it is a real bill. The practical risk is availability, not speed: if your name servers go down, a long TTL keeps you resolving from cache while a 60-second TTL takes you off the internet in a minute.

What TTL do the big sites use?

Large sites that steer traffic with DNS - CDNs, global load balancers - use very short TTLs, commonly 20 to 60 seconds, because the record is how they move users between regions. Records that never change, such as NS and MX for a stable mail provider, are usually 86400. The rule is simple: TTL should match how often the answer changes.

Can I force a resolver to forget a record early?

Not remotely. You can flush your own caches - the OS resolver cache, the browser, your local resolver - and Google and Cloudflare both publish a public form to flush a name from their own public resolvers, which covers a large share of users. Everybody else's ISP resolver will hold the record until the TTL expires, and there is no mechanism in DNS to revoke it.

Need domain and DNS checks inside your own product?

We build WHOIS, RDAP, DNS and SSL lookups as embeddable widgets or a plain JSON API in your branding, wired to your own lead form. Tell us which checks you need and we will send a working demo.