Understanding TTL: DNS Cache and Propagation Times

Introduction

TTL controls how long DNS resolvers may cache a DNS answer before checking again. It is one of the most important settings to understand when changing A records, MX records, nameservers, CNAME records or other DNS values.

Many users call every delay “DNS propagation,” but most delays are caused by caching. If a resolver recently cached the old DNS value, it may continue using that value until the TTL expires. This is why some users may see the new website while others still reach the old server for a while.

Quick answer

What is DNS TTL?

DNS TTL stands for Time To Live. It is a value, usually measured in seconds, that tells resolvers how long they may keep a DNS answer in cache.

example.com A 192.0.2.10 TTL 3600

In this example, a resolver may cache the A record for up to 3600 seconds, or one hour, before asking for the record again.

How DNS caching works

DNS caching reduces repeated DNS lookups and helps websites load faster. Instead of asking the authoritative nameserver every time, resolvers can reuse recently received answers until the TTL expires.

1. A resolver asks for a DNS record.
2. The authoritative nameserver returns the record and its TTL.
3. The resolver stores the answer in cache.
4. Users using that resolver receive the cached answer.
5. When TTL expires, the resolver checks again for a fresh value.

Caching is useful, but it can make DNS changes appear slowly during migrations.

TTL vs DNS propagation

TTL and propagation are related, but they are not the same.

Lowering TTL does not instantly update all resolvers. It helps only after resolvers refresh and receive the lower TTL.

Common TTL values

Different DNS providers and use cases use different TTL values.

There is no perfect TTL for every domain. Short TTLs update faster but create more DNS queries. Long TTLs reduce DNS traffic but make changes slower.

When should you lower TTL?

Lower TTL before planned DNS changes, especially when moving important services.

• before moving a website to a new server
• before changing A or AAAA records
• before changing MX records
• before switching CDN or proxy provider
• before changing nameservers
• before launching a new website
• before moving important subdomains
• before major email provider migration

For best results, lower TTL at least one current TTL period before the planned change. For example, if the current TTL is 24 hours, lower it a day before the migration if possible.

When should you increase TTL?

After a migration is stable, you can increase TTL again for records that do not change often.

Examples:

• stable website A records
• MX records for a long-term email provider
• verification records that rarely change
• static subdomains

Do not leave very low TTL values forever unless you have a reason. Low TTLs can increase DNS query volume and make your setup noisier.

Why this matters

TTL does not fix incorrect DNS records. It only controls how long DNS answers may be cached.

How to check TTL values

Use DNS Lookup to inspect DNS records and their TTL values. Check the exact record you plan to change, such as A, AAAA, CNAME, MX, TXT or CAA.

Common TTL problems

How to manage TTL safely

1. Identify the records that will change

   Decide whether you will change A, AAAA, CNAME, MX, TXT, CAA or nameserver records.

2. Check current TTL values

   Use DNS Lookup to see how long current answers may be cached.

3. Lower TTL before the planned change

   If possible, reduce TTL to a lower value such as 300 seconds before the migration.

4. Wait one old TTL period

   Give resolvers enough time to refresh and receive the lower TTL before making the actual change.

5. Make the DNS change

   Update the record only after the lower TTL has had time to spread.

6. Keep old services available temporarily

   During migrations, keep the old website server or email provider active until traffic and mail clearly move to the new destination.

7. Verify and restore stable TTL

   After the migration is confirmed stable, raise TTL to a normal value if appropriate.

TTL planning examples

Before migration:
example.com.  86400  IN  A  192.0.2.10

Lower TTL one day before migration:
example.com.  300    IN  A  192.0.2.10

Migration change:
example.com.  300    IN  A  192.0.2.20

After stable migration:
example.com.  3600   IN  A  192.0.2.20

dig example.com A
dig example.com MX
dig example.com TXT
dig +nocmd example.com A +noall +answer

TTL during website migrations

Before moving a website, lower TTL for records that point visitors to the website, such as A, AAAA or CNAME records. This makes it easier to switch traffic to the new server when the migration is ready.

Before changing the record, make sure:

• the new server has the website files
• the database is migrated
• SSL is ready
• redirects are configured
• www and root domain are both handled
• the old server remains available temporarily

A low TTL helps reduce transition time, but it does not replace proper migration preparation.

TTL during email migrations

Email migrations need careful TTL planning because senders may continue using cached MX records.

Before changing MX records:

• lower TTL in advance
• create mailboxes at the new provider
• copy or configure SPF, DKIM and DMARC
• keep the old mail provider active temporarily
• test inbound and outbound mail
• monitor bounce messages

Changing MX records only affects incoming mail routing. Outgoing email authentication also depends on SPF, DKIM and DMARC.

TTL and negative caching

Negative caching happens when a resolver caches a “record not found” answer. This can happen if a service checks for a TXT, CNAME or verification record before you have added it.

Example:

1. A verification service checks for a TXT record.
2. The record does not exist yet.
3. A resolver caches the negative answer.
4. You add the TXT record.
5. The service may still not see it until negative cache expires.

Negative cache behavior is often influenced by SOA settings and resolver behavior.

How to verify propagation

To verify DNS propagation, check the same record from multiple resolvers or locations.

Use checklist:

• check the record type you changed
• compare expected value and current value
• check from multiple resolvers
• check active nameservers
• check whether TTL is decreasing
• test the actual service, not only DNS

For example, after changing an A record, confirm that the website loads from the new server. After changing MX records, send test emails from external providers.

Frequently asked questions