The short answer
TTL (time to live) is the number of seconds a resolver may cache a DNS answer before asking again. It is set per record, it is why DNS scales, and it is why “propagation” exists: after a change, the world keeps serving the old answer until the old TTL runs out. Lower it before changes, keep it around an hour the rest of the time.
The mechanism in thirty seconds
Every DNS record carries a TTL, assigned by whoever runs the zone. When a
recursive resolver (your ISP’s, Google’s 8.8.8.8, your office DC) fetches
www.example.com A 93.184.215.14 TTL 3600, it stores the answer
and serves it from memory for up to an hour, decrementing the counter as it
goes. Run a DNS lookup twice in a row and you can watch
this happen: the second answer often returns faster and with a lower TTL,
because you are reading someone’s cache mid-countdown.
This is the entire trick that lets a protocol from 1983 serve today’s internet. The authoritative servers for a popular domain answer a tiny fraction of the world’s queries for it; caches absorb the rest. The TTL is the dial that trades freshness against load: shorter means changes apply faster, longer means fewer queries and faster resolution.
The semantics live in RFC 1035 and its clarifications: the TTL is a maximum, not a contract. Caches may drop records early under memory pressure, a handful of resolvers clamp very low TTLs upward, and negative answers (the domain does not exist) get cached too, governed by the SOA record’s minimum field, which is a classic gotcha when you query a name before creating it.
”Propagation” is not what the word suggests
Nothing propagates. DNS changes are not pushed anywhere; there is no wave rolling across the internet. The moment you publish a change, your authoritative servers answer with the new value. Every resolver that asks fresh gets it instantly. Every resolver holding a cached copy keeps serving the old value until its countdown hits zero, and those countdowns started at different moments on thousands of independent caches.
So the worst-case delay for full convergence is the TTL that was on the record before you changed it. Change a record that carried 86400 and some users can see stale data for a day; nothing you do afterward shortens it. This is also why the gradient effect happens: your phone on 5G already sees the new site while your colleague’s office resolver serves the old one for forty more minutes. Both are behaving correctly.
The practical consequence inverts how people schedule changes: the important TTL work happens before the change. Drop the TTL to 300 at least one full old-TTL period in advance (so every cache has picked up the short value), make the change, verify, then raise the TTL back. The five-minute window you created is the difference between a cutover and a vigil.
Recommended TTL by situation (log scale)
Lower the TTL one full old-TTL period before any change, raise it back after.
Picking values like an operator
For everyday A and AAAA records on stable services, 3600 (one hour) is the boring, correct answer: changes apply within a coffee break, resolvers are not hammered, and nobody notices anything. Genuinely static infrastructure can run 4 hours or more without regret.
Records that exist to enable failover are the exception. If a load balancer or a DNS-based failover service is supposed to move traffic in minutes, its TTL has to be short, 60 to 300, permanently; that is the cost of the feature. Just be honest about which records those are. A 60 second TTL on a record nobody has changed since 2023 is pure waste: every minute, every resolver on earth re-asks the same question and gets the same answer.
Slow-moving plumbing goes the other way. NS records and glue change rarely and break loudly, so a day is normal. MX records sit comfortably at an hour or more, since sending servers retry on failure anyway; mail is the protocol most forgiving of brief DNS staleness. TXT records used for verification (SPF, DKIM, DMARC, the topic of our email authentication guide) live fine at an hour, though dropping them to 300 while you iterate on a new SPF record saves a lot of waiting between attempts.
A migration checklist that respects the math
Suppose the old record is www A 203.0.113.10 TTL 14400 and you
move to a new host. Day one: lower the TTL to 300, change nothing else. Wait
at least four hours (the old TTL), so every cache now holds the short-TTL
copy. Cutover: switch the A record to the new address, verify immediately
with a fresh lookup against your authoritative servers and a couple of public
resolvers, keep the old origin serving (or redirecting) for stragglers.
Within five minutes the world has converged. A day later, raise the TTL back
to its cruising value and decommission the old origin.
The whole procedure is ten minutes of actual work wrapped around two waiting periods, and the waiting periods are not optional: they are the TTL doing exactly what it says. Operators who internalize that stop fearing DNS changes, because there is nothing mystical left. It is a cache with a countdown, and you own the clock.
Frequently asked questions
What does TTL 3600 mean on a DNS record?
Resolvers may reuse that answer for up to 3600 seconds (one hour) without asking your nameservers again. A user whose resolver cached the record at minute zero can see the old value until minute sixty after you change it. The TTL is a maximum: caches may evict earlier, and a few misbehave and hold longer.
How long does DNS propagation really take?
Your authoritative servers answer with the new value seconds after you publish. Everyone else catches up as their cached copy expires, so the realistic worst case is the OLD TTL that was in effect before the change, plus a little slack for resolver quirks. If the old TTL was a day, plan for a day; nothing you do after the change speeds it up.
Is a very low TTL like 30 or 60 seconds bad?
As a permanent setting, usually yes. Every cache expiry forces a fresh lookup, so a 60 second TTL multiplies query load on your DNS provider and adds resolution latency for users, in exchange for agility you rarely use. Keep low TTLs for planned changes and failover records; park everything else at an hour or more.
Why did my change show up for some people and not others?
Different resolvers cached the old record at different moments, so their copies expire at different moments. Add resolvers that pre-fetch popular names, mobile carriers with aggressive caches, and the odd resolver that ignores low TTLs, and a rollout always lands as a gradient, not a step. Checking against several resolvers shows the gradient directly.
Does TTL affect my SEO?
Not directly: TTL is not a ranking signal. Indirectly, a sane TTL matters during migrations, because a botched cutover with a day-long TTL can leave crawlers hitting a dead origin for hours. Lower the TTL before moving, confirm the new target, then raise it again; Googlebot follows DNS like any other client.