Domain Validation Checklist for New Website Launches

Overview

This guide gives you a practical domain validation checklist you can run before launch day. It is written for developers, IT admins, and technical teams who need a repeatable process rather than a one-time setup note.

A useful pre-launch review should answer five questions:

• Does the domain resolve to the right infrastructure for every hostname users may reach?
• Does HTTPS work cleanly for apex and subdomains with the expected certificate coverage?
• Do redirects send users and crawlers to the intended canonical URL without loops or mixed behavior?
• Are ownership, registration, and DNS change controls in place so the domain is not exposed to avoidable risk?
• Are mail-related DNS records present and aligned with the domain’s sending setup?

If your team uses a domain validation API or DNS validation tool, this checklist maps well to automated preflight checks. If you work manually, it still helps create a launch gate that is clear enough for engineering, infrastructure, and marketing teams to sign off together.

Before you start, define the exact launch scope. List every hostname in use, including:

• Primary website domain
• www hostname
• Country or language subdomains
• App or account subdomains
• Static asset or CDN hostnames
• Form, checkout, help center, or status subdomains
• Email sending or return-path domains if they are part of the rollout

That inventory becomes your validation list. Most launch issues happen because one hostname was left out of planning.

Checklist by scenario

Use the scenario that matches your launch, then adapt the steps to your stack. The goal is not to check every possible record. It is to validate the records and behaviors that affect reachability, trust, and continuity.

Scenario 1: Brand new domain launch

If this is the first public site on the domain, validate the basics in a strict order.

1. Confirm registrar and DNS authority. Verify which provider controls registration and which provider is authoritative for DNS. Make sure the intended nameservers are delegated correctly.
2. Validate DNS records for the website. Check the apex record strategy and any www CNAME or equivalent routing setup. Confirm that records point to the intended load balancer, reverse proxy, hosting platform, or CDN.
3. Review TTL values before launch. If changes are likely during cutover, lower TTLs in advance. This is not a guarantee of instant propagation, but it usually makes correction faster if a record needs to change.
4. Test resolution from multiple networks. Query public resolvers and confirm the answers are consistent enough for launch. If IPv6 is enabled, validate AAAA records as carefully as A records.
5. Issue and validate SSL certificates. Confirm the certificate covers every live hostname, including www and any subdomain users might enter directly. Verify the certificate chain is complete and the hostname matches are correct.
6. Force HTTPS consistently. Decide whether HTTP should redirect to HTTPS for every hostname, and test that behavior explicitly.
7. Define canonical redirects. Choose one canonical URL style, such as https://www.example.com or https://example.com. Redirect all other variants directly to it in one hop where possible.
8. Validate robots, sitemap, and crawlable pages. Even though this is not purely DNS work, it affects the visible launch result and is worth checking while redirects and canonical URLs are under review.
9. Set up mail records if the domain will send email. At minimum, confirm MX, SPF, DKIM, and DMARC planning. If mail is in scope, see MX, SPF, DKIM, and DMARC Explained: A DNS Validation Checklist for Email Senders.
10. Document rollback ownership. If the site becomes unreachable after launch, someone should know exactly where to revert DNS, certificate, or proxy settings.

Scenario 2: Replatforming an existing website

Replatforming is riskier than a first launch because users, bots, and integrations already depend on current behavior.

1. Capture the current DNS and redirect state. Export existing records, note CDN or WAF settings, and map all active redirect rules before making changes.
2. Compare old and new hostname coverage. Confirm the new platform supports every hostname currently used in production, not just the main site.
3. Check certificate ownership and automation. If the old platform managed certificates automatically, make sure the new one can do the same or that your team has a replacement process.
4. Validate origin and edge routing. If a CDN sits in front of the new stack, confirm cache, origin health checks, TLS mode, and header forwarding are intentional.
5. Test old URLs against the new redirect map. Focus on high-traffic pages, campaign landing pages, login URLs, and documentation paths. Watch for chains, loops, and dropped query strings.
6. Check non-browser traffic. APIs, webhook endpoints, and machine clients can fail if redirects or TLS settings change unexpectedly. Keep this in scope if the domain serves more than webpages.
7. Validate mail records after DNS moves. Mail often breaks when teams change DNS providers and forget to carry over TXT or MX records.
8. Review monitoring and alerting. DNS, certificate expiry, and endpoint health checks should point to the new stack before launch, not after.

Scenario 3: Changing registrars or DNS providers

This scenario often looks simple on paper but creates subtle failures when records or settings are copied incompletely.

1. Inventory every record type. Include A, AAAA, CNAME, MX, TXT, CAA, SRV, and any provider-specific verification records.
2. Replicate records carefully. Differences in formatting, quoting, trailing dots, flattening behavior, or UI defaults can create mismatches.
3. Check DNSSEC and delegation settings. If DNSSEC is in use, validate the full change sequence before switching. A partial setup can make the domain appear broken.
4. Review CAA records. CAA settings should allow the certificate authorities you rely on. Overly restrictive or stale CAA records may block issuance or renewal.
5. Validate WHOIS or registration contact settings where applicable. The exact visibility varies by provider and privacy settings, but the practical goal is the same: make sure ownership and recovery contacts are correct.
6. Confirm domain lock and change protections. Transfers and nameserver changes should not be possible without deliberate approval.
7. Test after cutover from multiple resolvers. Do not assume the new zone is correct because the UI accepted it.

Scenario 4: Launching email and web from the same domain

When the website and email both go live together, domain trust depends on both working correctly.

1. Validate MX records. Confirm mail routes to the expected provider and that priorities are set intentionally.
2. Validate SPF records. Ensure the record reflects the actual senders in use and does not become invalid due to multiple SPF records or poor consolidation.
3. Validate DKIM selectors. Check that selectors exist, match the sending platform, and are published on the correct hostnames.
4. Validate DMARC policy and reporting addresses. Start with a policy appropriate to your readiness level and confirm the reporting mailbox can receive reports if you enable them.
5. Check support and transactional addresses. Test the addresses shown on the website so form flows, password resets, and customer replies do not fail on day one.
6. Run end-to-end delivery tests. A correct-looking zone file is not enough. Send and receive messages across common providers and inspect authentication results.

If your launch also includes signup, checkout, or contact forms, pairing domain checks with an email validation API comparison can help you think through deliverability and input quality together.

What to double-check

This section is the short list of items most likely to be missed even by experienced teams. If time is limited, do not skip these.

1. Apex, www, and subdomain behavior

Users may type the bare domain, click a saved www bookmark, or land on a marketing subdomain from an old campaign. Test each hostname directly over HTTP and HTTPS. Confirm they all resolve and redirect as intended.

2. Redirect hop count

A redirect that technically works may still be poorly configured. Try to keep users and crawlers from passing through multiple hops such as HTTP to HTTPS, non-www to www, then old path to new path. Consolidate where possible.

3. Certificate hostname coverage

A certificate may validate for the primary domain but fail on a lesser-used subdomain. Compare the certificate coverage directly against your hostname inventory, not against memory.

4. IPv6 readiness

If AAAA records exist, the site should work over IPv6 as reliably as over IPv4. If your infrastructure is not ready, do not publish partial support by accident.

5. CAA records and renewals

Teams often focus on initial certificate issuance and forget that renewal depends on the same conditions later. CAA should be reviewed as part of ongoing certificate validation, not just launch setup.

6. Mail record drift

Mail-related TXT records are commonly lost during DNS migrations because they look unrelated to the website. They are not unrelated if you send receipts, password resets, alerts, or support responses from the same domain.

7. Environment leakage

Make sure staging or preview subdomains are not accidentally indexed, publicly linked, or left with permissive certificates and weak access controls. A pre-launch domain review should include what should remain private.

8. Third-party verification records

Many services require TXT or CNAME records for verification. Confirm which records are still needed, which can be retired, and whether any stale records point to old vendors.

9. Monitoring targets

Health checks, uptime probes, and certificate alerts should target the canonical production hostname. Launches sometimes fail quietly because monitoring still points at the old environment.

Common mistakes

Most domain launch failures are not mysterious. They come from a handful of repeated patterns.

• Treating DNS as a one-time setup task. DNS should be validated before launch, after cutover, and after any provider or platform change.
• Assuming browser success means full success. A page loading in one browser from one office network does not prove DNS, TLS, redirects, and email are all healthy.
• Forgetting dependent services. Help centers, status pages, checkout flows, login endpoints, and asset hosts are often on separate subdomains with separate certificate and DNS needs.
• Moving nameservers without a complete record inventory. This is one of the fastest ways to break forms, email, and verification services at the same time.
• Leaving redirect logic split across too many layers. Redirects set partly at the registrar, partly at the CDN, and partly in the application are harder to reason about and easier to break.
• Ignoring registration security. Domain lock, access control, and recovery contacts are part of domain validation in practice because a correctly configured zone is still vulnerable if ownership controls are weak.
• Skipping documentation. If no one can say where DNS lives, who owns certificates, and how mail authentication is managed, the next update will be slower and riskier than it needs to be.

For teams building internal automation, this is where a domain validation API or DNS validation tool becomes useful. It can turn these repeatable checks into a launch gate, reduce manual comparison work, and flag drift before it causes an outage.

When to revisit

The value of a checklist is not just using it once. Domain validation should be revisited whenever the underlying inputs change.

Return to this checklist:

• Before any new website launch or microsite rollout
• Before seasonal planning cycles when campaign domains or traffic patterns change
• When changing hosting providers, CDNs, WAFs, or reverse proxies
• When moving registrars or DNS providers
• When adding or retiring subdomains
• When enabling email from a domain that previously did not send mail
• When certificate management ownership changes
• When internal workflows or validation tools change
• After any unexplained deliverability, redirect, or reachability issue

A practical way to make this sustainable is to keep a simple pre-launch record for every domain:

1. Hostname inventory: every public and operational hostname in scope
2. DNS ownership map: registrar, authoritative DNS provider, CDN, certificate owner, mail provider
3. Expected records: web, mail, verification, and security-related records
4. Validation results: resolution, TLS, redirects, and email authentication checks
5. Rollback notes: who can revert what, and where the change is made

If you do this consistently, each new launch becomes easier. You are no longer rebuilding domain knowledge from memory. You are validating against a known baseline.

As a final action step, create a launch checklist that your team can run in three passes: one pass 48 to 72 hours before launch, one pass immediately before cutover, and one pass after DNS and traffic have settled. That rhythm catches configuration mistakes early, confirms live behavior after the switch, and gives you a reusable process for every future domain change.