Change DNS without breaking your website or email: a controlled cutover runbook

Why a small DNS edit can create a large outage

One domain can route the public website, business email, subdomains, verification challenges, security policies, and third-party services. A migration focused only on the website address can leave MX, SPF, DKIM, DMARC, CAA, or service-verification records behind. The change may look correct to one person while cached or geographically distributed resolvers still return an older answer.

Map ownership before touching the zone

Record the registrar, authoritative DNS provider, hosting platform, email provider, certificate process, and every person or system authorized to change them. Confirm that administrative access and recovery methods work before the maintenance window. Domain ownership, nameserver authority, DNS records, hosting, and email are related but distinct controls; avoid moving several of them at once unless the migration genuinely requires it.

Export and classify the complete current zone

Capture the zone through the provider export when available and supplement it with public queries. Classify each record by purpose, owner, expected value, proxy state, and rollback importance. Preserve unknown records until their function is identified rather than assuming that an unfamiliar TXT or CNAME is obsolete.

• Website routing: apex, www, application subdomains, redirects, and IPv4 or IPv6 answers.
• Email delivery and authentication: MX, SPF, DKIM selectors, DMARC, and provider-specific discovery records.
• Certificates and trust: CAA records, validation challenges, and DNSSEC configuration.
• Business services: analytics, search, support, payments, marketing, and ownership-verification records.
• Delegated subdomains and any records managed by a separate team or provider.

Understand what TTL can and cannot do

TTL controls how long a DNS record may be cached. Lowering it ahead of a planned record change can reduce the lifetime of later cached answers, but caches that already stored the previous record can keep it for the original TTL. Cloudflare also notes that local caches may outlive the nominal record interval. Record TTL and nameserver delegation behavior are not interchangeable, so do not promise an exact universal propagation time.

Protect email as a separate migration stream

MX records determine where receiving systems deliver mail for the domain. Google Workspace and Microsoft 365 both document MX as a core delivery control, while TXT and CNAME records support authentication, ownership, and client configuration. A website cutover usually does not require an email change. Copy the verified mail records exactly when moving DNS providers, and change mail routing only through the email provider’s documented migration plan.

• Confirm every active sending service before editing SPF; a domain should publish one coherent SPF policy rather than conflicting records.
• Preserve DKIM selectors and DMARC policy and reporting destinations.
• Test inbound and outbound delivery with external accounts after the change.
• Keep access to the previous mailbox system during any approved email transition.
• Do not treat a successful website load as evidence that email is healthy.

Prepare the destination before changing public answers

Configure the new origin, domain bindings, redirects, certificates, application secrets, background work, and monitoring before routing production traffic. Test through a provider preview, temporary hostname, hosts-file override, or controlled edge rule where appropriate. The destination should already return the intended status, canonical URL, security headers, and critical customer journeys.

Make the smallest reversible cutover

Choose an accountable operator and a second person to verify the proposed before-and-after values. Change only the records required for the approved step, record the exact timestamp, and retain the previous values. Keep the former service available where practical so cached visitors continue to receive a working response and rollback remains possible.

Verify authority, resolution, and real journeys

Check the authoritative answer first, then query more than one public recursive resolver and network. Validate the apex, www host, important subdomains, IPv4 and IPv6 behavior, redirects, TLS certificate, canonical tags, robots directives, forms, authentication, checkout, webhooks, and monitoring. For email-related work, verify MX and authentication records and send real inbound and outbound tests through independent providers.

Use evidence-based rollback criteria

Rollback is appropriate when the destination cannot serve critical journeys, certificates fail, mail routes incorrectly, data writes diverge, or the team cannot explain inconsistent answers. Restore the documented previous values rather than improvising a third configuration. Remember that rollback also follows DNS caching behavior; keeping the old environment healthy reduces the cost of mixed answers.

Close only after the dependency window

Do not immediately delete the old hosting account, DNS zone, mailbox, certificate, or logs. Monitor traffic, errors, form submissions, email delivery, application jobs, and resolver answers through the agreed observation period. Restore normal TTLs where they were temporarily lowered, update the infrastructure record, remove superseded access safely, and document the final authoritative configuration.