DNS is the control system behind the domain

Most website launch stress comes from DNS. The design may be finished, the pages may be tested and the client may be ready, but the site does not become public in the right place until domain records point correctly. DNS is the system that tells browsers where the website lives and tells mail servers where email should go.

You do not need to become a DNS engineer, but a basic understanding prevents expensive mistakes. The most important idea is that a domain can have different records for different services. The website can point to one host while email points to another. Changing website records should not automatically mean changing email records.

Before launch, write down the current setup. Where is the domain registered? Which nameservers are active? Where is the current website hosted? Where is email hosted? Are there subdomains, verification records or third-party services using DNS? This inventory is the safety net.

Domain registrar and nameservers are not always the same

The domain registrar is the company where the domain is registered and renewed. Nameservers decide where the active DNS zone is managed. Sometimes they are the same provider. Sometimes they are not.

For example, a domain might be registered with one company but use Cloudflare nameservers. In that case, editing DNS at the registrar may do nothing because Cloudflare is the active DNS provider. This is a common source of confusion.

Check nameservers before making changes. The active nameservers tell you where DNS records must be edited. If you are unsure, use a DNS lookup tool or ask the current provider.

Know the common record types

An A record points a domain or subdomain to an IPv4 address. An AAAA record points to an IPv6 address. A CNAME points one name to another name. MX records control incoming email. TXT records are often used for verification and email authentication such as SPF, DKIM and DMARC.

For a simple launch, you may only need to update A, CNAME or ALIAS/ANAME records for the website. Email records should be preserved unless email is also moving.

Do not delete records you do not understand. A harmless-looking TXT record may verify Microsoft 365, Google Workspace, email authentication, analytics or another service.

Plan the launch records

Ask the new host or developer exactly which DNS records are required. The answer should include host/name, type, value and TTL if relevant. For example, the root domain may need an A record and www may need a CNAME. Some platforms use CNAME flattening or ALIAS records for the root domain.

Decide whether both example.co.uk and www.example.co.uk will work, and which version is canonical. Redirect the other version to the preferred one. This prevents duplicate versions of the site.

If the site uses subdomains such as staging, shop, portal or mail, handle them separately.

Lower TTL before launch where possible

TTL means time to live. It controls how long DNS resolvers may cache a record. Lowering TTL before launch can make changes appear more quickly. This should be done in advance because the old TTL may still be cached until it expires.

Not every DNS provider gives fine control, and not every project needs this. But for business-critical launches, it is worth planning.

After launch is stable, TTL can be raised again if appropriate.

Protect email during website launch

Email disruption is one of the biggest avoidable launch problems. Website records and email records are separate, but changing nameservers can replace the entire DNS zone. If you switch nameservers without copying MX, SPF, DKIM, DMARC and verification records, email may stop working.

If the website launch requires changing nameservers, copy all existing DNS records first. Then recreate needed records at the new DNS provider before switching. Pay particular attention to MX and TXT records.

After launch, send test emails in both directions. Test website forms too, because forms may rely on SMTP settings or domain authentication.

Use redirects carefully

If URLs change during a rebuild, create redirects from old pages to relevant new pages. Redirects protect visitors and search visibility. A redirect from every old page to the homepage is usually poor practice. Send old service pages to equivalent new service pages where possible.

Before launch, crawl or export old URLs. Include pages that rank, receive traffic, have backlinks or are linked from emails and documents. After launch, check for 404 errors.

Redirect planning is especially important when moving away from WordPress, changing page slugs or restructuring services.

Test after DNS changes

After launch, test:

  • Root domain.
  • www version.
  • HTTPS certificate.
  • Main navigation.
  • Forms.
  • Email delivery.
  • Redirects.
  • Analytics.
  • Search Console verification.
  • Sitemap.

Use different devices and networks if possible. DNS changes may appear at different times for different people because of caching.

Keep a DNS record

Keep a simple document of DNS records and what each one does. This is useful when renewing services, migrating hosts, setting up email or troubleshooting. Include the date changed and who made the change.

DNS feels obscure until something breaks. Documentation turns it from a mystery into a manageable system.

Launch calmly

Website launches are smoother when DNS is treated as part of the project, not a last-minute task. Identify active nameservers, preserve email, prepare records, plan redirects and test after launch. That reduces risk and makes the public switch feel controlled rather than chaotic.

A pre-launch DNS checklist

Before launch, collect the active DNS records. Export them if the provider allows it, or copy them into a document. Pay special attention to MX records, SPF, DKIM, DMARC, Microsoft or Google verification records, subdomains and any records used by booking systems, CRMs or email marketing tools.

Confirm who has access to the DNS provider. Do not wait until launch day to discover that the login belongs to an old staff member or previous supplier. Check whether two-factor authentication is enabled and whether the person making changes can receive codes.

Agree a launch window. Avoid Friday afternoon launches where possible, especially if email, DNS or ecommerce is involved. Choose a time when someone can test properly and respond if anything looks wrong.

A post-launch DNS checklist

After records are changed, test the site on HTTPS, with and without www. Test from a phone on mobile data as well as office Wi-Fi. Check that old URLs redirect. Submit the sitemap if needed. Send and receive email. Submit a website form.

Use DNS lookup tools to confirm public records match the intended values. If some networks show the old site for a while, that may be normal caching. If records are wrong everywhere, investigate quickly.

Keep the old hosting available for a short period if possible, especially when migrating a larger site. This gives you a fallback if missed files, redirects or email dependencies are discovered.

Common DNS mistakes

Common mistakes include editing DNS at the registrar when nameservers point elsewhere, deleting mail records during a nameserver move, creating duplicate SPF records, forgetting the www version, pointing the root domain but not subdomains, and failing to renew the domain.

Another common mistake is changing too much at once. If website, email and nameservers all move on the same day, troubleshooting becomes harder. When possible, separate changes and test each one.

DNS is precise. Small typos can have large effects. Copy values carefully and keep screenshots or notes of what changed.

DNS and email authentication during launch

Website launch records often sit alongside email authentication records. SPF, DKIM and DMARC are usually TXT records, and they should be preserved when moving DNS. Losing them may not stop mail immediately, but it can damage deliverability and make messages more likely to be flagged.

If the website sends form notifications from the same domain, check that the website’s mail setup aligns with DNS authentication. A form that sends as hello@example.co.uk through an unauthorised server may be treated suspiciously by receiving mail systems.

This is why launch testing should include forms and email, not only page loading.

Who should manage DNS

DNS should be managed by someone careful, available and documented. That might be the business owner, web partner, IT provider or hosting company. The important thing is clarity. If everyone assumes someone else controls DNS, launches and troubleshooting become slow.

Keep ownership with the business wherever possible, even if a supplier manages day-to-day changes. The domain is a core asset. Losing control of it creates serious risk.

Treat the domain as a business asset

A domain name is not just a technical detail. It carries the website, email, search history, customer recognition and brand trust. Protect it carefully. Keep renewal payment details up to date, use a secure registrar account and make sure more than one responsible person knows where the domain is managed.

When suppliers change, confirm that domain access remains with the business. A website can be rebuilt, but losing control of a domain can create serious disruption.