LeadHaste

What Is DNS TTL?

DNS TTL, or time to live, is the cache lifetime attached to a DNS resource record, expressed in seconds. It tells caching resolvers how long they may retain an answer. It helps explain why different observers can see different values after a DNS change.

By LeadHaste Editorial · AI-assisted editorial review ·

A record edit is not an instant global update

Changing a record at the authoritative DNS service does not immediately replace copies already cached elsewhere. A resolver that recently obtained the old answer may continue using it for its remaining lifetime. Distinguish an authoritative configuration problem from an observer legitimately retaining an earlier answer before making another edit.

In a conceptual example, one resolver queried a record before a change and another queried after it. They can return different values without either observation proving that the provider failed to save the update. Keep the queried name, type, resolver and timestamp beside the result so the discrepancy can be investigated.

Lowering TTL needs planning

A lower value can shorten future caching, but changing TTL does not retroactively shorten every copy already cached with the previous value. If an operator wants shorter caching around a planned migration, the timing of that change matters. Coordinate the sequence with the DNS and application owners before the migration begins.

Do not interpret TTL as a guaranteed deadline for an entire service to become ready. Application verification, certificate provisioning, local caches and negative DNS answers can introduce other behavior. Identify which component is still returning an old result or waiting for activation instead of using propagation as a catch-all explanation.

What to record during an email DNS change

Capture the old and new values, the intended TTL and the authoritative answer after the edit. Check the resolver used by the affected tool where practical. If authentication is involved, also inspect a real message's receiver-reported result; the DNS edit is only one part of the verification process.

Keep a rollback plan appropriate to the service and preserve the observations that led to the change. Repeated edits during a cache transition can make the timeline harder to understand. A clear record of what changed, when and where it was observed is more useful than repeatedly refreshing an unrelated online checker until a badge changes color.

Sources

Useful next steps

Related terms

Put the pieces into a system you own.

Explore your ICP and campaign fit on a free discovery call, then decide what your outbound operation needs.

Book your free ICP review →