Time to live, or TTL, is a number attached to every DNS record that tells any resolver caching that record exactly how many seconds it's allowed to keep using the cached answer before it has to ask the authoritative nameserver again. It's a small setting that's responsible for almost everything people experience as "DNS propagation" — a term that implies something is actively spreading a change outward, when what's actually happening is simpler and more mechanical than that.
What TTL actually is
Every DNS record — an A record pointing a domain to an IP address, an MX record for mail, a CNAME, any of them — has a TTL value specified in seconds. A TTL of 3600 means any resolver that looks up that record is permitted to cache the answer and reuse it for up to one hour before it's required to query the authoritative nameserver again for a fresh answer. This value is set per record by whoever manages the DNS zone, and it travels with the record itself — a resolver anywhere in the world that queries that record receives the TTL along with the answer and honors it.
Why "propagation" is a caching expiry, not a push
Changing a DNS record at the authoritative nameserver takes effect there immediately — there's no delay on that end. The delay people experience comes entirely from every resolver, everywhere, that had already cached the old value and hasn't hit its TTL expiry yet. An ISP's resolver, a visitor's operating system, a corporate DNS cache — any of them that queried the record before the change, and cached it per the TTL that was in effect at the time, will keep serving that cached old answer to anyone asking through them until their copy expires. Nothing pushes the new value out to those caches; they simply continue answering from memory until their TTL runs out, at which point they ask again and get the new answer. This is why propagation isn't instantaneous even though the authoritative change is: it's bounded by the oldest TTL still cached somewhere in the world, not by how far a change has to travel.
A worked example: lowering TTL before a migration
Say a site is migrating to a new server with a new IP address, and the A record currently has a TTL of 86400 seconds (24 hours). Changing the IP on migration day, with that TTL still in effect, means any resolver that cached the old IP any time in the previous 24 hours keeps sending visitors to the old server for up to a full day after the change — exactly the scenario that causes some visitors to see the new site while others still land on the old one. The fix is to lower the TTL in advance of the migration, not on migration day itself: changing it to, say, 300 seconds (5 minutes) a day or two before the move gives existing caches time to expire and pick up the new, shorter TTL. By the time the actual IP change happens, most resolvers are re-checking every five minutes instead of every 24 hours, so the IP change itself propagates in minutes rather than up to a day. Raising the TTL back to a normal value afterward, once the migration is confirmed stable, is a reasonable last step.
Low TTL vs. high TTL: the real tradeoff
A low TTL (seconds to a few minutes) means changes take effect quickly almost everywhere, which is valuable around planned changes or when quick failover matters. The cost is that it increases DNS query volume, since every resolver has to re-ask far more often instead of serving from cache — for most sites this is a negligible cost, but it's not literally free. A high TTL (hours to a day or more) reduces query volume and is appropriate for records that rarely change, but it means any unplanned correction — a mistake, an emergency IP change — takes correspondingly longer to reach everyone. Neither is universally correct; the right value depends on how stable a given record is expected to be and how much it would cost to have a correction take hours to fully take effect. A reasonable default for most records that aren't actively being changed is somewhere in the 3600-to-14400-second range (one to four hours) — short enough that a genuine emergency correction resolves in a reasonable window, long enough that ordinary query volume stays modest. Records tied to infrastructure that's expected to stay stable for long periods, like a domain's NS records once nameservers are set, can reasonably use a longer TTL still.
TTL across different record types
Not every record is a good candidate for a very low TTL, and some have constraints outside a domain owner's direct control. NS records (which specify a domain's authoritative nameservers) are queried and cached higher up the DNS hierarchy, by resolvers and other nameservers that don't necessarily respect an unusually low TTL the same way they would for an ordinary A record — nameserver changes can take longer to fully settle regardless of the TTL set on the record, simply because of how widely and redundantly NS information gets cached across the system. There's also a separate value called the negative caching TTL, set in a zone's SOA record, which controls how long resolvers cache the fact that a record doesn't exist (useful when a query is made for a record that was never created, or was deleted) — this is a different number from the TTL on any individual record, and it's worth not confusing the two when diagnosing why an old or removed record still seems to resolve somewhere. For most day-to-day changes — repointing an A record, updating an MX record — the ordinary per-record TTL covered above is the one that matters; NS and SOA-level TTLs are a separate, less frequently touched layer.
The most common TTL mistake
The single most common error is changing TTL at the same time as the record itself, rather than in advance. By the time a lowered TTL value is visible to resolvers, it's already too late to speed up the propagation of the change that prompted lowering it — the old, longer TTL is still what's cached everywhere, and that's what determines how long the old answer persists. Lowering TTL only helps if it's done early enough for the previous, longer TTL to have already expired everywhere before the actual change happens.
Practical guidance
For any planned change — a server migration, switching mail providers, repointing a subdomain — lower the TTL on the specific record being changed 24 to 48 hours ahead of time, make the actual change only after that window has passed, then raise the TTL back to a normal value (3600 to 86400 seconds, depending on how often the record is expected to change) once the new value is confirmed working everywhere. For records that almost never change, a longer TTL is simply more efficient with no real downside. This is a narrower, more mechanical topic than DNS as a whole — see DNS Records, Nameservers and Resolution for how record types and the broader resolution chain work, and Domain Transfer Explained for how TTL planning fits into a domain transfer specifically.
