Website Launch DNS Checklist
Launching a website or migrating to a new host? DNS misconfiguration is the number one cause of post-launch downtime. This checklist covers everything you need to verify before, during, and after going live.
Quick Answer
Before launching, lower your TTL to 300 seconds and document all existing DNS records. During launch, update your A records and CNAMEs, re-create MX and TXT records if you changed nameservers, and verify propagation globally. After launch, confirm SSL is active, email is working, security headers are in place, and raise TTL back to normal.
Phase 1: Pre-Launch (48 Hours Before)
Preparation is what separates a smooth launch from a panicked one. These steps should be completed at least 48 hours before you make any DNS changes.
Lower TTL to 300 seconds on records you plan to change
This ensures old cached values expire quickly once you make the switch. If your current TTL is 86400 (24 hours), you need to lower it and wait at least 24 hours before changing the actual records.
Verify the new server is ready
Test your site on the new hosting platform using its default URL or IP address. Confirm it loads correctly, all pages work, and there are no errors before pointing DNS to it.
Identify all email-related records
If you are changing nameservers, your MX, SPF, DKIM, and DMARC records will not carry over automatically. Write down the exact values so you can re-create them at the new DNS provider.
Phase 2: During Launch (DNS Changes)
This is the critical window. Make your DNS changes carefully and verify each one before moving to the next.
Update A record for root domain
Point your root domain (example.com) to your new server's IP address. Double-check the IP for typos.
Update CNAME for www subdomain
Point www.example.com to your root domain or hosting provider's hostname. Both root and www should resolve correctly.
Re-create MX records (if nameservers changed)
This is the most commonly missed step during migrations. Without MX records, your email stops working. Copy the exact values from your backup.
Re-create SPF, DKIM, and DMARC records
These TXT records handle email authentication. Missing SPF means your outbound email lands in spam. Missing DKIM breaks email signatures. Missing DMARC removes your spoofing protection.
Keep old records until new ones are confirmed
Do not delete old DNS records until you have verified the new ones are propagating correctly. Having both temporarily does not cause issues and gives you a rollback path.
Timing tip: Never make DNS changes on a Friday afternoon. If something goes wrong, you want business hours ahead of you for troubleshooting, not a weekend.
Phase 3: Post-Launch Verification
After making DNS changes, verify everything is working correctly from multiple angles. Do not assume it works just because it loads on your machine.
DNS Propagation
Check A record propagation globally. All servers should return your new IP address. Check A records
Check CNAME for www subdomain. Verify it resolves to the correct target. Check CNAME records
Check MX records are resolving. Confirm mail routing is correct. Check MX records
Verify TXT records (SPF, DKIM, DMARC) are present. Check TXT records
Check NS records point to the correct nameservers. Check NS records
SSL Certificate
Verify SSL certificate is issued and valid. Most platforms auto-provision after DNS propagates. Check SSL certificate
Confirm the certificate covers both root domain and www (check Subject Alternative Names).
Test that HTTPS redirects work. Visiting http:// should redirect to https:// automatically.
Check for mixed content warnings. All resources (images, scripts, fonts) should load over HTTPS.
Email Verification
Send a test email to your domain address from an external account (Gmail, Outlook). Confirm it arrives.
Send a test email from your domain to an external account. Check it does not land in spam.
Verify SPF passes by checking email headers on the received test email. Look for spf=pass.
Test contact forms on your website. Confirm submission emails are being delivered.
Security Headers
Check HTTP security headers are present on the new server. Headers from the old server do not carry over. Check HTTP headers
Verify HSTS, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy are configured.
Domain Verification
Verify WHOIS shows correct nameservers for your new DNS provider. Check WHOIS
Confirm domain registration is not expiring soon. A domain expiring mid-launch is a disaster. Check domain details
If you enabled DNSSEC, verify it shows as active in your WHOIS results.
Phase 4: 24-48 Hours After Launch
Re-check DNS propagation
Run propagation checks again after 24 hours. All 21+ global servers should now return consistent results. If any still show old values, investigate that specific resolver.
Raise TTL back to normal
Once propagation is complete and everything is confirmed working, change your TTL back to 3600 (1 hour) or higher. Keeping TTL at 300 long-term wastes DNS queries.
Test from a different network
Visit your site from a mobile network (not Wi-Fi), a VPN, or ask someone in a different country to check. Your local network cache might still show stale results.
Remove old DNS records
Once the new records are fully propagated, delete any old records that are no longer needed. Stale records create security risks over time.
Monitor for issues over the next week
Set up uptime monitoring if you have not already. Some edge cases (ISPs with aggressive caching, corporate DNS resolvers) can take longer than 48 hours to update.
Common DNS Launch Mistakes
Forgetting MX records after changing nameservers
This is the most common and most damaging mistake. Your website works, but email silently stops. You might not notice for hours or days until someone tells you their email bounced.
Adding a CNAME on the root domain
Standard DNS does not allow CNAME records on the root domain because they conflict with NS and SOA records. Use an A record for the root, CNAME for subdomains. Some providers like Cloudflare support CNAME flattening as a workaround.
Not lowering TTL before the change
If your TTL is 86400 seconds (24 hours), caches worldwide hold the old value for up to a day after you update. If something goes wrong, you cannot roll back quickly. Always lower TTL at least 24 hours before making changes.
Checking only from your own machine
Your local DNS cache and ISP cache may show the new record before the rest of the world sees it. Always verify propagation from multiple global locations, not just your own browser.
Launching on a Friday
DNS problems can take hours to diagnose and resolve. If something breaks on Friday evening, you may not have support from your hosting provider or registrar until Monday.
Verify Your Launch
Use DNSFly's free tools to run through every step of this checklist. Check DNS propagation, SSL certificates, WHOIS details, and HTTP security headers from one place.