Change DNS without breaking your website or email

Estimated reading time : 3 min · Published October 5, 2026

Inventory the zone and responsibilities

Identify the domain holder, registrar, DNS provider, website host and email host. Record renewal dates and the person authorised to approve the change. Keep a dated record inventory in the project workspace, without exposing access methods publicly.

Cover the main domain, www, subdomains, A and AAAA addresses, CNAME aliases, email MX records and TXT records used for authentication or service verification. Check CAA and DNSSEC dependencies where present. A working homepage does not demonstrate that email and other services work.

Prepare the destination first

When replacing the DNS provider, recreate the required zone and compare it with the approved inventory. When moving only website hosting, limit changes to affected records. Ask service owners to confirm dependencies rather than deleting TXT records whose purpose is unclear.

TTL describes how long a response may remain cached. Reducing it sufficiently before a change may limit persistence of the old value, but does not replace validation or recovery planning. Where DNSSEC is enabled, zone signing and the parent DS record must be coordinated; a mismatch can make the domain unavailable to validating resolvers.

Test the website, email and related services

Define trials for the main domain and www over HTTPS, an internal page, external email sending and receiving, a contact form and important subdomains. Compare results across several resolvers and networks. Record times, returned values and discrepancies.

Visitors may temporarily reach different destinations depending on cached responses. Plan how to prevent divergent writes if orders or enquiries continue during that period. A static presentation page and an active shop need different continuity arrangements.

Define recovery conditions

Before changing anything, name the operator, the symptoms that trigger rollback and the old values to retain. DNS recovery is not instantaneous for every visitor; caching and TTL also belong in the plan.

After stabilisation, check certificates, automated email and provider verification. Retire old dependencies only after confirming they are unnecessary. Registrar transfers may follow extension-specific rules: consult the registry or registrar rather than assuming identical timing for every domain.

Reference documents

Content updated on October 5, 2026

Record checks and findings in the acceptance log

Acceptance matrix to adapt to your project

These proposed checks use synthetic cases. Decide the required behaviour with the team, record the result and assign unresolved gaps before release.

Test cases, expected outcomes and useful evidence
Case	Expected outcome	Evidence to retain
Prepared zone	Required services have their expected records.	Before-and-after comparison.
HTTPS website	Main domain, www and internal pages work.	URLs, statuses and certificates.
Email	Sending, receiving and forms work.	Test messages and authentication checks.
Recovery	Old values and responsibilities are documented.	Procedure approved before the change.

Frequently asked questions

Does moving hosting require transferring the domain?

No. Registration may stay with the same registrar while DNS points to a different host. Registration transfer, DNS and hosting are separate operations.

Why does the website work while email fails?

MX or authentication records may have been lost when replacing the zone. Compare values with the email provider’s requirements and the original inventory.

Does DNS propagation always take 48 hours?

There is no universal duration for every response. TTLs, caches and the changes made affect the result. Observe values from several points and maintain service continuity.