DNS TTL change planner: when to lower the TTL before an MX change
In short: Enter the time of the change, your current TTL and the lower TTL you will use. The planner gives the latest time to lower it, when the change is seen and when to raise it again. Limit: Times assume resolvers follow the TTL they were given.
Enter when you will change the record, its current TTL and the shorter TTL you will switch to first. The planner gives the latest time to publish the shorter TTL, the time by which resolvers should see the change, what that time would have been without lowering it, and when it is safe to raise the TTL again.
Price: this tool is free. Checking a whole email list is from $9/mo, and the first 100 checks are free with Google, no card. Check your list free nowSee pricing
The values below are examples. Replace them with your own change time and TTLs.
- Lower the TTL no later than
- 2026-11-19 09:00 UTC
- Make the change at
- 2026-11-20 09:00 UTC
- Resolvers should see it by
- 2026-11-20 09:05 UTC
- Raise the TTL again after
- 2026-11-20 09:05 UTC
- Without lowering, seen by
- 2026-11-21 09:00 UTC
Lowering the TTL first makes the change visible 23 h 55 min sooner in the worst case.
Formulas: lower by = change time − current TTL; seen by = change time + lowered TTL. Resolvers that ignore the TTL are not covered.
Sample result
For a change at 2026-11-20 09:00 UTC, lower the 24 hour TTL to 300 seconds by 2026-11-19 09:00 UTC.
- Seen everywhere by
- 09:05 UTC
- Current TTL
- 24 h
- Lowered TTL
- 5 min
What this means for you
Resolvers then see the change by 09:05 instead of up to a day later.
- Latest time to lower the TTL
- When resolvers see the change
- When to raise it again
- Formulas shown
- TTL
- MX change
- Planner
By SimpleVerifier Team · Last updated · Runs in your browser; nothing you paste is sent to us
Mail routing changes are the time to check your list too.
- Plan the DNS change above, then check the list before you send from the new setup.
- Upload or paste it at /verify. Every address gets a live mailbox check, and the first 100 email checks are free with a Google sign-in, no card.
How do I plan a DNS change so it takes effect quickly?
- Enter the date and time (UTC) you will change the MX, SPF or other record.
- Pick the TTL the record has now and the shorter TTL you will use before the change.
- Lower the TTL no later than the time shown, so every copy of the old long TTL has expired by the change.
- Make the change, then raise the TTL again after the time shown.
Example
- You enter
- Example change at 2026-11-20 09:00 UTC on a record with a 24 hour TTL, lowered first to 300 seconds.
- You get
- Lower the TTL no later than 2026-11-19 09:00 UTC. Make the change at 2026-11-20 09:00 UTC; resolvers should see it by 2026-11-20 09:05 UTC instead of 2026-11-21 09:00 UTC.
- Limits
- Runs in your browser. It assumes resolvers follow the TTL they were given.
How are the times worked out?
A resolver that cached the record just before you lowered the TTL keeps it for up to the old TTL. So the shorter TTL must be published at least one old TTL before the change: lower-by time = change time − current TTL. After the change, the longest any resolver should still hold the old record is the lowered TTL: seen-by time = change time + lowered TTL.
Without lowering it first, the same change would take up to the current TTL to be seen: change time + current TTL.
Why plan this for mail records?
During an MX move, some senders still reach the old server until their cache expires, so keep the old mail server running until the seen-by time passes. Check the new records with the MX lookup and the DNS propagation checker, and see check a new domain is ready to send email.
What can still go wrong?
A few resolvers and some devices hold a record longer than its TTL or less time than it, so the times are the planned worst case for resolvers that follow the TTL, not a promise. Raise the TTL again once the change is settled so your DNS host serves fewer queries.
Who uses this tool, and for what?
- IT admins
- Schedule an MX move for a new mail provider.
- Cold emailers
- Time the DNS change when you move a sending domain to a new host.
- Web agencies
- Give a client the exact times to lower and raise a TTL.
What can’t this tool tell you?
- Times assume resolvers follow the TTL they were given.
- It does not read your DNS or know your current TTL.
- Browsers, operating systems and some resolvers add their own caching.
- It does not check that the new record is correct.
Common questions
- What TTL should I lower it to?
- Common choices are 300 seconds (5 minutes) or 60 seconds. Check what your DNS host allows.
- How early must I lower the TTL?
- At least one current TTL before the change. A record with a 24 hour TTL must be lowered at least 24 hours ahead.
- Do all resolvers follow the TTL?
- Most do, but some keep a record longer than its TTL. Keep the old setup running a while after the change.
- Which times does it use?
- UTC. Convert your local time before you enter it.
- Does it change my DNS?
- No. It only works out the times.
- Is anything uploaded?
- No. The times are worked out in your browser.
A tidy list can still be full of dead addresses.
Extracting, deduplicating and syntax checks all work on the text of an address. None of them can tell whether the mailbox exists. Only the server that hosts it can answer that, through an SMTP check, and that is what the paid product does.
- Upload the cleaned file as it is: CSVs up to 100,000 rows
- A real SMTP mailbox check on every row, with catch-all detection
- Small list? Starter at $9/mo covers 2,500 emails a month, cancel anytime
Plans from $9 a month, cancel anytime, no contract. Sign in with Google and your first 100 email checks are free, no card. The free tools stay free either way.