Launch Profile
Enter the apex domain. Subdomains are checked automatically.
Leave blank if using A records directly.
TTL Propagation Calculator
Global coverage assumes stubborn resolvers and mobile carrier caches. Plan for this, not the minimum.
Verification Sequence
Enter your domain and click Generate Sequence to build your launch checklist.
Common Scenarios & Pitfalls
Scenario: Cutting over to a CDN
You are pointing your apex domain to Cloudflare or Fastly. The trap is forgetting that many DNS providers do not allow CNAME at the apex. You may need ANAME, ALIAS, or a flattened CNAME. Verify what your provider actually supports before launch day. Also confirm your origin IP is not exposed in older cached responses.
Scenario: Email migration with MX changes
MX changes have longer propagation tails because email servers cache aggressively. Send test emails from Gmail, Outlook, and a corporate Exchange server. Check that SPF and DKIM TXT records travel with the MX. A missing TXT record during MX transition means deliverability drops before users complain.
Scenario: Mobile carrier DNS quirks
Mobile carriers often run transparent DNS proxies with cache times unrelated to your TTL. Test on cellular data, not just WiFi. iOS and Android also maintain local DNS caches that may persist across airplane mode toggles. Power cycle the device for a true fresh lookup.
Rollback decision tree
If verification fails, your first question is how long until safe rollback. If you lowered TTL beforehand, rollback is fast. If not, you are waiting the full original TTL. The tool estimates this for you. In emergencies, switching to a backup DNS provider with pre-staged records can bypass cache waits.
Assumptions & Limits
This checklist assumes you have direct control of your DNS zone and can run command-line tools. It does not replace monitoring services like Pingdom or UptimeRobot for ongoing surveillance. The TTL calculator uses standard advisory math, not live resolver measurements. Some networks (corporate firewalls, national ISPs) cache for days regardless of TTL.
How to read the generated commands
Commands use dig syntax common on macOS and Linux. Windows users can install dig via BIND or use nslookup with comparable flags. The +short flag trims output for quick scanning. Remove it for full response details when debugging. The @8.8.8.8 specifier tests against Google's resolver explicitly, bypassing your local cache.
Quick Answers
How long should I wait after changing DNS?
Wait the full TTL plus 25 percent. For 300 seconds, that is about 6-7 minutes minimum. For 86400 seconds (24 hours), plan 30 hours. The calculator above shows your exact numbers.
Why does one device see the change and another does not?
Different networks use different resolvers. Your home ISP, office network, phone carrier, and VPN all have separate caches. Test from at least three independent networks before confirming propagation.
Should I lower TTL before a launch?
Yes, 24-48 hours ahead. This flushes old records faster. Raise TTL back after launch to reduce lookup load and improve resilience against provider outages.
Can I speed up propagation?
No. You can only make it faster next time by lowering TTL in advance. On launch day, you are bound by existing cache times. Some premium DNS services offer instant propagation to their own network, but the public internet still caches independently.
What about DNSSEC?
If you use DNSSEC, record changes require re-signing. The chain of trust must update too. Add 50 percent to your normal wait time. Verify with dig +dnssec and check for RRSIG records in responses.