How to Check DNS and SSL Before Launching a Website
Most launch-day incidents aren't code bugs — they're DNS and certificate issues that were checked too late, or not at all. A wrong A record still points to the old host, an MX record is missing so all mail bounces, or a certificate covers the wrong subdomain. This guide is a practical order of checks to run before pointing a domain's traffic at a new site.
Key Takeaways
- Check DNS records against what the new host actually requires before switching nameservers or updating records
- DNS changes propagate gradually — verify from multiple resolvers, not just your own machine, which may have a cached answer
- An SSL certificate must cover every subdomain you serve, including "www" if you use it — a mismatch causes browser warnings, not a clean failure
- Certificate expiry is one of the most preventable outages — check the expiry date, not just that HTTPS currently works
- MX records are independent of your website's A/CNAME records — moving a site can silently break email if MX is overlooked
1. Confirm every DNS record your new host requires
Before switching, list what the new host actually needs: an A record (pointing to an IP) or CNAME (pointing to a hostname) for the root and "www", any TXT records for domain verification, and MX/TXT records for email (SPF, DKIM, DMARC) if you're sending mail from that domain. Missing a single TXT verification record is a common reason a domain fails ownership checks with a new provider.
2. Check propagation from more than one location
DNS resolvers cache answers for the record's TTL (time to live), so your own browser or ISP may show the old value long after the authoritative record changed, while someone on a different network already sees the new one. Check propagation from several public resolvers/locations, not just your own connection, before concluding a DNS change "isn't working yet".
3. Verify the SSL certificate covers every hostname you serve
A certificate issued for "example.com" does not automatically cover "www.example.com" unless it was issued as a SAN (Subject Alternative Name) or wildcard certificate. Check the certificate's covered domains directly rather than assuming — visiting the bare domain in a browser can show a valid padlock while "www" shows a certificate mismatch warning, and vice versa.
4. Check certificate expiry, not just current validity
A certificate can be perfectly valid today and expire in three days if a renewal (manual or automated) silently failed. Check the actual expiry date as part of a pre-launch and recurring routine — auto-renewal failures (an expired payment method, a DNS validation record that got removed, a rate limit) are a leading cause of "the site was fine yesterday" outages.
5. Don't forget MX and email during a migration
Moving a website to a new host changes A/CNAME records, but MX records that route email are usually separate and hosted elsewhere. If MX gets accidentally overwritten during a DNS migration (common when copying a template zone file), email delivery breaks silently — often nobody notices until a customer complains that a form submission or password reset email never arrived.
Common Mistakes to Avoid
- ✗Switching DNS and immediately assuming propagation failed because your own browser still shows the old site (it's just a cached DNS answer)
- ✗Assuming a certificate for the root domain automatically covers the "www" subdomain, or vice versa
- ✗Checking that HTTPS "works" without checking the certificate's actual expiry date
- ✗Overwriting MX records during a DNS migration and breaking email delivery without noticing until much later
- ✗Not verifying required TXT verification records before a new host or email provider rejects the domain
Frequently Asked Questions
Why does my new DNS record show up on one device but not another?▾
DNS answers are cached by resolvers for the record's TTL. Different networks and devices query different resolvers, which may have cached the old answer at different times — this is expected during propagation and isn't a sign that anything is broken, as long as the authoritative record itself is correct.
Does an SSL certificate for my root domain also cover "www"?▾
Only if it was issued to explicitly include "www" as a Subject Alternative Name, or as a wildcard certificate covering all subdomains. A certificate issued only for "example.com" will show a hostname-mismatch warning on "www.example.com" even though the root domain works fine.
What's the most common cause of an unexpected SSL expiry?▾
A failed auto-renewal — often because a DNS-based validation record was removed, a domain-validation email bounced, or an ACME client/cron job silently stopped running. Checking expiry proactively rather than waiting for a browser warning avoids the outage entirely.
Related Guides
SEO Technical Checklist for Small Websites
A practical, ordered checklist of the technical SEO fundamentals a small site or side project needs — sitemap, robots.txt, canonicals, structured data, and metadata — before worrying about anything more advanced.
How to Debug API JSON Responses Safely in the Browser
A practical workflow for inspecting, formatting, and comparing API JSON responses in the browser without pasting sensitive data into random online tools.
Last reviewed: 2026 · Written and verified by the Dev Utilities team · Editorial policy
Report an issue with this guide →