Domain, DNS, SSL, and Email Setup Checklist for New Websites

Overview

A practical launch process should reduce guesswork, not add more of it. The goal of this checklist is to help you confirm four foundational systems before they create problems in production:

• Domain: who owns it, where it renews, who has access, and whether it is protected against accidental loss or transfer.
• DNS: whether the website, subdomains, redirects, and verification records point to the correct services.
• SSL: whether every hostname visitors use is covered by a valid certificate and forced to HTTPS.
• Email: whether mailbox routing and authentication records are in place so business email works and outgoing messages are less likely to be flagged.

If you only remember one principle, make it this: separate ownership from configuration. Know who owns the domain, where DNS is hosted, where the website is hosted, where email is hosted, and who can change each one. Many launch issues happen because those responsibilities are mixed together and undocumented.

This article focuses on setup and launch readiness, but these systems also affect security and recovery. If you are building a broader launch process, pair this checklist with a security review and restore plan. Related reads on pyramides.cloud include the Cloud Hosting Security Checklist: SSL, WAF, Backups, Access Control, and Monitoring and How to Launch a Business Website on Cloud Hosting: Step-by-Step Checklist.

For day-to-day use, think in three phases:

1. Pre-launch: confirm ownership, records, certificate issuance, and mail routing.
2. Launch day: switch DNS carefully, verify HTTPS and redirects, and watch propagation.
3. Post-launch: recheck email authentication, uptime, renewal settings, and access control.

Checklist by scenario

This section gives you a practical checklist based on the most common launch situations. Start with the scenario that matches your project, then adapt the items for your stack.

Scenario 1: Brand-new domain and brand-new website

Use this when you have registered a new domain and are launching a site for the first time.

• Confirm the domain is registered in an account the business controls, not a personal account that may become inaccessible later.
• Enable domain auto-renew and verify the billing method is valid.
• Turn on registrar security features such as account protection, two-factor authentication, and transfer lock where available.
• Document the registrar, DNS host, web host, and email provider in one internal record.
• Decide whether the primary public address will be example.com or www.example.com. Use one as canonical and redirect the other.
• Create the required DNS records for the website. In many setups this means an A record, AAAA record, CNAME, or provider-specific alias record.
• Create DNS records for any essential subdomains, such as www, mail, blog, app, or status.
• Add verification records required by your host, CDN, analytics, or email provider.
• Issue or enable SSL for the root domain and any public subdomains that should serve HTTPS.
• Force HTTPS and confirm that mixed-content warnings do not appear.
• Set up business email mailboxes or aliases, such as hello@, support@, or billing@.
• Add MX records for inbound mail.
• Add SPF, DKIM, and DMARC records for outbound authentication.
• Send and receive test emails between internal and external mail systems.
• Check that website forms send notifications to the intended mailbox.

Scenario 2: Moving an existing domain to a new website host

This is the scenario where DNS mistakes are most common because old services and new services overlap during cutover.

• Export or record the current DNS zone before changing anything.
• List all active records, not only website records. Pay special attention to MX, SPF, DKIM, verification TXT records, and subdomains used by third-party services.
• Lower DNS TTL values ahead of the planned cutover if your provider and workflow allow it. Do this early enough for the previous TTL to expire.
• Prepare the new site before switching production traffic: content, redirects, SSL, and application settings should be tested on a staging or temporary hostname.
• Verify whether your new host expects apex A/AAAA records, a CNAME for www, or nameserver changes for full DNS delegation.
• If using a CDN or proxy layer, confirm whether SSL terminates at the edge, the origin, or both.
• Make the DNS change in a maintenance window appropriate for your traffic.
• After the switch, test root domain, www, mobile and desktop rendering, redirects, API endpoints, and login flows.
• Keep the old hosting environment available until you are sure no traffic or background jobs depend on it.

Scenario 3: Keeping web hosting and email hosting separate

This is a common and often sensible setup for small businesses and developer-led teams. The key is to treat web and mail as separate systems in DNS.

• Confirm that changing website records will not overwrite MX records.
• Check that your DNS provider does not offer one-click presets that replace unrelated records.
• Preserve existing SPF entries when changing mail providers or adding transactional email tools. SPF must be valid as a single record, not split into multiple SPF TXT records.
• Publish DKIM exactly as provided by the email service, including selector-specific hostnames.
• Create a DMARC policy that at minimum gives you reporting visibility. Tighten enforcement only after validating legitimate sending sources.
• Document every system allowed to send mail as your domain: mailbox provider, support platform, CRM, billing tool, newsletter platform, and application server if applicable.

Scenario 4: Launching with a website builder or managed cloud hosting platform

Website builders and managed cloud hosting can simplify setup, but they also hide details that still need verification.

• Confirm whether the platform manages SSL automatically or requires DNS verification before issuing a certificate.
• Check whether the platform expects a nameserver change or only individual DNS records.
• Review redirect settings for non-www to www, HTTP to HTTPS, and any legacy URLs.
• Verify support for custom domains on every environment you plan to expose publicly.
• Confirm whether built-in email forwarding is available, or whether you need a separate email host.
• Test form delivery, password reset emails, and contact flows after the domain is connected.
• Check caching and CDN behavior so launch-day changes are not hidden behind stale responses.

If performance matters early, it usually does, continue with How to Reduce TTFB on Cloud Hosting: Server, CDN, Cache, and DNS Fixes and CDN vs No CDN for Small Websites: When It Helps, When It Hurts, and What It Costs.

What to double-check

Even careful teams miss the same handful of details. Before launch, review these items in order.

1. Domain ownership and access

• The registrant account is controlled by the business or project owner.
• At least two trusted administrators can access the registrar account.
• Recovery email addresses are current.
• Auto-renew is enabled and monitored.
• Transfer lock is enabled unless you are actively transferring the domain.

2. DNS accuracy

• The apex domain and www point where you expect.
• Unused legacy records are removed only after you verify they are truly unused.
• MX records still point to the intended mail provider.
• TXT records for SPF, DKIM, DMARC, ownership verification, and third-party integrations are complete and correctly quoted if required by the provider.
• TTL values are appropriate for normal operation after launch; do not leave unusually low values forever without a reason.

3. SSL behavior

• The certificate covers all public hostnames visitors actually use.
• HTTPS is forced site-wide.
• Redirect chains are short and intentional.
• No pages load scripts, styles, images, or fonts over HTTP.
• Admin areas, forms, checkout pages, and API endpoints behave correctly over HTTPS.

4. Email delivery and authentication

• Inbound mail works for each mailbox and alias you expect to receive messages.
• Outbound mail passes through an approved sender, not a leftover server configuration from an old host.
• SPF includes all legitimate senders and stays syntactically valid.
• DKIM signing is enabled and aligned with the domain in use.
• DMARC is published with the reporting address monitored by someone on the team.

5. Website launch behavior

• Canonical domain choice is enforced consistently.
• Old URLs redirect cleanly if this is a redesign or migration.
• Forms, notification emails, and transactional emails work from the live domain.
• Robots rules and indexing settings are correct; staging noindex rules should not leak into production.
• Monitoring is active for uptime, certificate issues, and key pages.

Launch quality is not just about being online. It is also about staying recoverable. A clean backup and restore process should exist before you make major DNS changes. See Website Backup Strategy Guide: RPO, RTO, Retention, and Restore Testing Explained and Disaster Recovery for Small Websites: Failover, Restore, DNS, and Communication Checklist.

Common mistakes

The most expensive launch mistakes are usually simple ones repeated under time pressure. Avoid these common failure points.

Changing nameservers without replicating the full DNS zone

When teams move DNS to a new provider, they often recreate only website records and forget mail, verification, or service-specific subdomains. If you change nameservers, rebuild the complete zone first and compare record by record.

Assuming SSL is automatic for every hostname

Many platforms provision certificates automatically, but not always for every subdomain, redirect host, or temporary environment. Verify the exact hostnames covered before launch.

Breaking email while connecting the website

This happens when someone edits DNS only to point the website to a new host and accidentally removes MX, SPF, or DKIM records. Website and email can share a domain, but they should be managed as separate systems.

Publishing multiple SPF records

SPF should be a single effective policy for the domain. Multiple SPF TXT records often cause evaluation issues. If you add a new sender, merge it into the existing SPF policy carefully.

Using a strict DMARC policy too early

DMARC is useful, but aggressive enforcement before you inventory all legitimate senders can block valid mail. Start with visibility, validate your sending paths, then tighten policy deliberately.

Forgetting redirects and canonical consistency

If http://, https://, www, and non-www all remain accessible without a clear redirect strategy, users and crawlers can encounter inconsistent versions of the site. Pick one preferred hostname and enforce it.

Leaving launch-day access too broad

Temporary access for developers, contractors, or vendors often remains longer than intended. After launch, review who can change registrar settings, DNS, TLS, hosting, and mailbox administration. For a wider operational hardening pass, see How to Choose a WAF for a Business Website and the Cloud Hosting Security Checklist.

When to revisit

The value of a checklist is not only in launch week. Domain, DNS, SSL, and email settings should be reviewed whenever the underlying systems change. Use the following schedule as a practical baseline.

• Before launch: complete the full checklist and capture screenshots or exports of key settings.
• 24 to 72 hours after launch: re-test HTTPS, redirects, forms, inbox delivery, and external sender authentication.
• Before seasonal planning cycles: review renewals, ownership, aliases, campaign sending tools, and traffic-related DNS or CDN changes.
• When workflows or tools change: revisit the checklist if you change registrar, DNS host, website builder, managed cloud hosting provider, email platform, CDN, support tool, or CRM.
• At least quarterly: audit access permissions, TLS coverage, DMARC reporting, and DNS sprawl from old integrations.
• Before a redesign or migration: snapshot the current DNS zone, mail routing, redirects, and certificate setup so rollback is realistic.

Here is a compact maintenance routine you can keep in your operations notes:

1. Verify domain renewal and registrar access.
2. Export the live DNS zone.
3. Check the website’s primary hostname, redirects, and SSL status.
4. Send a test email in and out of the domain.
5. Review SPF, DKIM, and DMARC against your current sending tools.
6. Remove stale records from retired services only after confirming they are unused.
7. Update internal documentation with every meaningful change.

If this website is part of a broader performance or builder decision, it is worth also reviewing Best Website Builders for Fast-Loading Sites: Core Web Vitals Features Compared, Image Optimization Checklist for Website Speed, and Uptime Monitoring Tools Compared.

The simplest way to use this article is to treat it as a release gate. Before any new site, migration, or major infrastructure change, walk through domain ownership, DNS records, SSL coverage, and email authentication in that order. Those checks take less time than diagnosing a broken launch after customers have already seen it.