How to Move Website Hosting Without Affecting Your Email

Move your website to a new host while protecting business email: inventory DNS, check MX and authentication records, test and prepare a rollback.

You can often move website hosting without affecting email, but only if you know where your mailboxes and DNS are managed. The website, domain registration, DNS and email service are separate pieces, even when one company bills you for all of them. If a new nameserver does not contain your existing mail records, the website can load while business email stops arriving. Use this migration checklist to plan the move, test it and keep a rollback path.

Key takeaways

• Identify the domain registrar, authoritative DNS provider, website host and email provider before changing anything.
• Changing website A, AAAA or CNAME records is different from changing nameservers for the entire domain.
• Preserve the correct MX and email authentication records, plus verification and service records.
• If mailboxes are hosted by the old provider, arrange mailbox migration before cancelling that service.
• Test website, form notifications and inbound and outbound email; keep rollback access until checks pass.

First, identify what you are actually moving

Start with your invoices and account dashboards. The registrar controls the domain registration and usually where you set nameservers. The DNS provider publishes the records that tell browsers and mail servers where to go. The website host serves your site. The email provider stores mailboxes or forwards mail. One vendor can fill several roles, but changing one role does not automatically transfer the others.

Four separate pieces of a domain

If your mailbox is included in the old hosting package, moving the website does not move those messages or accounts. Plan a separate mailbox migration, confirm licenses and storage at the new provider, and preserve old access until the mailbox migration is verified. If an independent provider hosts email, its service can often remain in place while the website moves.

Website record change vs nameserver change

The least disruptive path is often to keep the current authoritative DNS provider and change only the website records required by the new host. Whether that is possible depends on the destination and existing configuration. A root A or AAAA record, or a www CNAME, can point web traffic to the new platform while existing MX and mail-related records remain unchanged.

Changing nameservers is broader. It tells the internet to ask a different DNS provider for the entire zone. The new provider must have all records your services need, not only the website address. Scans and imports can miss records. Compare the old and new zones manually, including subdomains, service records and verification tokens, before changing delegation.

Before the move: capture a complete inventory

Prepare a migration record

• Record the registrar, current nameservers, DNS provider, web host and email provider.
• Export or document all DNS records, including hostnames, values, priorities and TTLs.
• Identify MX records, SPF TXT, DKIM selector records, DMARC, mail hostnames and autodiscover or service records.
• Document ownership and verification records for Google, Microsoft, payment and other services.
• Confirm who controls the domain, DNS, hosting, mailbox accounts and any DNSSEC keys.
• Create and test website and database backups; record the rollback steps and contacts.

Never publish passwords, private keys or API tokens in a shared migration checklist. A DNS zone export normally contains public DNS values, but account credentials and mail data are separate and must be protected. Confirm the old host will stay active during the transition and that cancellation will not delete mailboxes you still need.

What each email-related DNS record does

Records to verify with your provider

Do not copy example values from another company. Your email provider supplies the exact records, and each sending service may have its own requirements. Cloudflare’s email record documentation explains the roles; Google’s sender guidelines describe requirements for sending to personal Gmail accounts.

Plan DNS caching, DNSSEC and the rollback

DNS changes do not reach every resolver at the same instant. Existing caches can retain older answers for their remaining TTL, and nameserver and registrar changes can take longer to settle. Where your DNS provider permits it, plan TTL changes in advance and wait at least the old TTL before the migration; lowering a TTL at the last minute does not shorten records already cached elsewhere.

If DNSSEC is enabled, an incorrect parent DS record can cause validation failures. Follow the current and new DNS providers’ documented DNSSEC migration procedure before changing nameservers. There is no universal instruction to delete or replace keys in every situation: the safe sequence depends on whether you use a coordinated multi-signer approach and on provider support. Cloudflare’s migration preparation guide describes the timing and checks.

Write down the exact prior record values and the person who can restore them. A rollback is a new DNS change and is also subject to caches. Keep the old website environment available when possible, but avoid letting staff change critical data in two systems at once. If the website has orders, bookings or accounts, plan a controlled data cutover rather than treating it as a static file copy.

Move and verify in a controlled order

A practical hosting migration sequence

• Build and test the destination — Move the site and database to a staging or preview environment. Check redirects, HTTPS, forms and integrations without exposing private data.
• Prepare DNS — If changing DNS providers, recreate and verify the complete zone. Check mail, verification and DNSSEC requirements with their providers.
• Make the planned change — Update the website records or nameservers as agreed. Record the time and exact change.
• Test website and email independently — Check the apex and www hosts, HTTPS, important pages, inbound mail, outbound mail, forwarding and form notifications.
• Monitor and finish — Watch delivery logs and both environments through the transition. Cancel old services only after mailbox and data migration are verified.

A website form can fail after a successful move even when normal mailbox email works. Its sending service, API key, authorized From address or background job may still point to the old host. Use a controlled test and follow the handoffs in our contact form email troubleshooting guide. For URLs, redirects and indexing checks, follow the website redesign SEO checklist.

If email stopped working after the move

First distinguish incoming mail from outgoing mail and form notifications. Check the registrar’s current nameservers and query the active MX records, then compare the results with your email provider’s documented values. If nameservers changed, inspect the new authoritative zone. If only the website record changed, investigate whether mail records or the mailbox service were changed separately.

Check whether the old provider hosted the mailbox itself. Restoring an MX record cannot recover a mailbox that was deleted or a service that is no longer active. Ask the provider about restoration and message queues. For outgoing failures, inspect the sending service’s logs, sender verification, SPF/DKIM and mailbox authentication. If your website uses Cloudflare, MX records are DNS-only and mail server hostnames generally need an appropriate DNS-only configuration; confirm the exact design with your provider.

• Avoid creating a second SPF TXT record for the same hostname.
• Avoid changing MX records based on generic examples instead of your provider’s values.
• Do not assume a website loading successfully proves email works.
• Do not delete old hosting or mailboxes until owners verify the migration.

Sources and further reading

Use Cloudflare’s DNS migration preparation guide, Cloudflare’s Google Workspace DNS guide and your own provider’s current migration instructions. A migration plan should reflect your actual accounts and DNS configuration.