Hosting & VPS Guides

Adjusting DNS TTLs Before a Site Migration

Practical guide to lowering DNS TTL before a website migration, hosting move or DNS change so updates can propagate faster and rollback is easier.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 8 min read Beginner

Introduction

DNS TTL, or Time To Live, tells DNS resolvers how long they may cache a DNS record before checking for a fresh value. During normal operation, longer TTLs are fine. During a migration, shorter TTLs can help DNS changes take effect faster.

The important detail is timing. TTL should be lowered before the migration, ideally 24–48 hours before the final switch. Lowering TTL after changing the record may not help users or resolvers that already cached the old value.

Quick answer

Quick answer

Before a site migration, lower the TTL for website-related DNS records such as A, AAAA and CNAME records. Do this 24–48 hours before the final switch when possible. Use a temporary TTL such as 300 seconds, update the records during migration, verify the new host, then restore a normal TTL after the migration is stable.

DNS TTL

Adjusting DNS TTL before a migration means temporarily reducing how long DNS resolvers cache records that will change.

Example: If your A record has a TTL of 14400 seconds, some resolvers may keep the old IP for up to 4 hours. If you lower TTL to 300 seconds before migration, many resolvers may check for updates more frequently during the final switch.

TTL does not force every resolver to update instantly, but it can reduce the delay for many users and make rollback easier if something goes wrong.

What DNS TTL means

TTL stands for Time To Live. It is measured in seconds.

Common examples:

  • 300 seconds = 5 minutes
  • 600 seconds = 10 minutes
  • 3600 seconds = 1 hour
  • 14400 seconds = 4 hours
  • 86400 seconds = 24 hours

A DNS resolver may cache the record for the TTL period. When the TTL expires, the resolver should ask authoritative DNS again for the current value.

Lower TTL means records can refresh sooner. Higher TTL means fewer DNS lookups and more stable caching.

When to lower TTL before migration

Lower TTL before planned DNS changes.

Recommended timing:

  • 24–48 hours before migration for normal sites
  • longer if current TTL is very high
  • at least one full current TTL period before the final switch
  • before changing A, AAAA, CNAME or relevant service records
  • before changing nameservers if possible

Example: If the current TTL is 86400 seconds, lower it at least 24 hours before migration.

Lowering TTL only minutes before the switch may not help resolvers that already cached the old record.

Which DNS records should have lower TTL?

Lower TTL only for records that may change during migration.

Usually lower:

  • A record for root domain
  • AAAA record if IPv6 is used
  • CNAME for www
  • CNAME for app or staging if changing
  • CDN-related records if changing
  • MX records only if email is moving
  • verification records only if provider requires changes

Usually do not change:

  • MX records if email is not moving
  • SPF/DKIM/DMARC if email remains the same
  • verification TXT records unrelated to migration
  • stable subdomains not affected by the move

Do not edit every DNS record just because you are migrating the website.

Website migration TTL example

Website migration TTL example 
Before migration:

example.com
Type: A
Value: 192.0.2.10
TTL: 14400

www.example.com
Type: CNAME
Value: example.com
TTL: 14400

24–48 hours before migration:

example.com
Type: A
Value: 192.0.2.10
TTL: 300

www.example.com
Type: CNAME
Value: example.com
TTL: 300

During migration:

example.com
Type: A
Value: 198.51.100.20
TTL: 300

After migration is stable:

example.com
Type: A
Value: 198.51.100.20
TTL: 3600 or 14400

Values are examples only. Use the real IPs and TTL options from your DNS provider.

TTL and nameserver changes

Nameserver changes are different from normal record changes. If you switch authoritative nameservers, the old and new DNS zones both matter.

Before changing nameservers:

  • export old DNS zone
  • recreate all records at new DNS provider
  • lower TTL where possible
  • copy MX records
  • copy SPF, DKIM and DMARC
  • copy verification TXT records
  • copy subdomains
  • confirm new zone is complete
  • test records before switching

Changing nameservers can affect website, email, SSL validation, verification records and subdomains. Treat it as a full DNS migration, not only a website change.

TTL and email migration

If email is moving to a new provider, TTL planning also matters for MX and authentication records.

Email records that may change:

  • MX
  • SPF
  • DKIM
  • DMARC
  • autodiscover
  • mail CNAME/A records
  • verification TXT records

If only the website is moving, do not change email records. If email is also moving, plan MX TTL carefully and test sending/receiving after the switch.

Why this matters

Why this matters

TTL planning matters because DNS changes are not seen by every user at the same time. If TTL is high, some visitors may continue reaching the old host after the migration. If TTL is lower before the switch, more resolvers can pick up the new value sooner.

Lower TTL also helps rollback. If the new host fails, you can point DNS back to the old host and many resolvers will refresh sooner.

How to check TTL before migration

Use DNS Lookup to inspect current records and TTL values.

  1. Authoritative DNS provider — Confirm where DNS is managed.
  2. Root domain A/AAAA records — Check current value and TTL.
  3. www record — Check CNAME or A record and TTL.
  4. Important subdomains — Check app, staging, API, CDN or store records if affected.
  5. MX records — Check only if email migration is involved.
  6. TXT records — Review SPF, DKIM, DMARC and verification records before nameserver changes.
  7. Propagation after change — Re-check records after TTL expires.

Check current DNS TTL values

Use DNS Lookup to inspect A, AAAA, CNAME, MX and TXT records with their TTL values before a migration.

Run DNS Lookup →

Common problems

TTL lowered too late

Medium

Resolvers may already have cached the old value for the previous high TTL.

Next step: Lower TTL at least one current TTL period before the migration.

Wrong records lowered

Low

Unrelated records were changed while important website records kept high TTL.

Next step: Identify A, AAAA and CNAME records used by the website.

MX TTL changed during website-only migration

Medium

Email records were touched even though email was not moving.

Next step: Restore correct MX and email authentication records.

Nameserver switch missing records

High

The new DNS zone does not include all old records.

Next step: Copy full DNS zone before switching nameservers.

TTL kept very low after migration

Low

DNS continues refreshing frequently even after the site is stable.

Next step: Raise TTL back to a normal value after monitoring.

Old host deleted too soon

High

Some users may still reach the old server during propagation.

Next step: Keep old hosting online until traffic has fully moved.

CDN cache confused with DNS TTL

Medium

DNS updated, but CDN or browser cache still shows old content.

Next step: Purge CDN/application cache separately from DNS changes.

IPv6 record forgotten

Medium

AAAA still points to the old server while A record points to the new one.

Next step: Update or remove the AAAA record if IPv6 is not configured on the new host.

www and root domain mismatch

Medium

example.com and www.example.com point to different destinations.

Next step: Align root and www with the intended canonical setup.

No rollback values saved

Medium

Old DNS values are not available if migration fails.

Next step: Save old DNS records before making changes.

How to adjust TTL safely before migration

  1. Step 1: Identify DNS provider

    Confirm where authoritative DNS is managed.

  2. Step 2: Export current DNS zone

    Save all existing records before making changes.

  3. Step 3: Identify records that will change

    Usually A, AAAA and CNAME records for the website.

  4. Step 4: Lower TTL in advance

    Set temporary TTL such as 300 seconds at least 24–48 hours before migration when possible.

  5. Step 5: Wait for old TTL to expire

    Give resolvers time to pick up the lower TTL.

  6. Step 6: Prepare new host

    Copy files, database, SSL and configuration before switching DNS.

  7. Step 7: Switch records

    Update only the records required for the migration.

  8. Step 8: Verify new destination

    Check website status, SSL, redirects and DNS resolution.

  9. Step 9: Keep old host online

    Do not cancel old hosting immediately.

  10. Step 10: Restore normal TTL

    After migration is stable, raise TTL back to a normal value.

Rollback planning

Lower TTL helps rollback if the new host fails.

Prepare:

  • old IP address
  • old DNS values
  • old hosting access
  • database backup
  • DNS provider access
  • old SSL state
  • contact/support details
  • migration log
  • testing checklist

Rollback is easier when the old host remains online and the old DNS values are saved.

DNS propagation reality

DNS propagation is not one single global timer. Different resolvers may update at different times depending on cache, TTL and resolver behavior.

Important notes:

  • some resolvers refresh quickly
  • some may cache longer than expected
  • user devices may have local DNS cache
  • browsers may cache connections
  • CDN cache is separate
  • application cache is separate
  • email routing can have its own delay patterns

A low TTL improves the situation, but it does not guarantee every user switches instantly.

Useful TTL checks

Useful TTL checks 
Check A record and TTL:
dig example.com A

Check www:
dig www.example.com CNAME

Check authoritative nameservers:
dig example.com NS

Check MX records:
dig example.com MX

Check specific resolver:
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

Trace DNS:
dig +trace example.com

Check website after switch:
curl -I https://example.com

Follow redirects:
curl -IL http://example.com

Commands are examples. Replace example.com with your real domain. DNS output varies by resolver and provider.

Example migration timeline

Example migration timeline 
48 hours before:
Export DNS zone.
Lower TTL for website A/CNAME records to 300.

24 hours before:
Prepare new hosting.
Copy files and database.
Test new host privately.

Migration window:
Final database sync.
Update A/CNAME records to new host.
Verify website, SSL and redirects.

After switch:
Monitor website, logs, forms and email.
Keep old hosting online.

24–72 hours after stable migration:
Raise TTL back to normal value.
Keep backups and migration notes.

The exact timeline depends on current TTL, website complexity, DNS provider and business risk.

Frequently asked questions

What is DNS TTL?

TTL means Time To Live. It tells DNS resolvers how long they may cache a DNS record.

When should I lower TTL before migration?

Ideally 24–48 hours before the final DNS switch, or at least one current TTL period before.

What TTL should I use during migration?

A temporary TTL such as 300 seconds is common for migration windows.

Does low TTL guarantee instant propagation?

No. It helps many resolvers refresh sooner, but it does not guarantee every user updates instantly.

Should I lower MX TTL when moving only the website?

No. Only lower MX TTL if email routing is also changing.

Should I keep TTL low forever?

Usually no. Raise TTL back to a normal value after the migration is stable.

What happens if I forget to lower TTL?

The migration can still work, but some users may reach the old host longer and rollback may be slower.

Use these free tools to verify your configuration after applying changes.

DNS Lookup Domain Health Checker Website Status Checker SSL Checker MX Lookup SPF Checker DMARC Checker
Migrating a Website to a New Host Without Downtime 9 min read Managing DNS Zones in cPanel and Plesk 9 min read Web Hosting vs Email Hosting: Key Differences 7 min read DNS vs CDN: Where the Problem Really Lies 9 min read How to Set Up Clean Redirects After Moving a Site 10 min read
Browse all Hosting & VPS guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.