Will Moving Your Website Affect Business Email? Check the Dependencies First

Moving your website does not automatically mean moving your business email. The two can use different providers, but a website move can still disrupt mail if it changes shared settings or removes a service the mailboxes depend on. Before approving the change, establish what is moving, what must stay and who will verify each part.

That is a planning task you can do with your website team and email provider. You do not need to work out DNS settings yourself. You need a clear account of the arrangement, the proposed changes and the checks that will show whether the business can still send and receive messages.

Identify the services behind the same domain

Your business can use one domain name for its website and email while relying on several services. The registrar manages the domain registration. The DNS provider holds the records that direct requests for that domain. The website host serves the site, while the mailbox provider handles the email accounts. One company may supply several of these roles, but that needs confirmation.

An MX record is a DNS record that directs incoming email to a mail server. It can help identify part of the mail setup. Squarespace's provider-identification guide also points to account information and provider support. Treat the record as a clue: a mail gateway or reseller can make the arrangement less obvious. Ask the person responsible for email to confirm the actual service.

Ask which kind of move is being proposed

A change of website host may leave the DNS provider and mailbox service in place. Ask the website lead to identify the exact website changes, then have the email owner confirm whether any mail dependency is affected. A statement that “we are only moving the website” needs that supporting detail.

If the DNS provider is changing too, the review is broader. The team needs to account for the records required by the website, email and other connected services. Cloudflare's setup guidance warns that its automatic scan may miss existing DNS records. An imported list should therefore be checked against the actual services and their providers' requirements.

A third case is email bundled with the old hosting account. Kinsta's migration guidance distinguishes this from separately hosted email. Before anyone cancels the old package, ask that provider whether the mailboxes or other needed services would also end. Keeping email there or moving it elsewhere requires an explicit arrangement; the new website going live does not settle that decision.

A fictional garage's change register

Imagine a garage moving its website while intending to keep its existing business email. The register below is fictional. Its roles and decisions illustrate questions to resolve, not a completed ZXP migration or a configuration to copy.

The unresolved DNS row is useful. It gives the maintainer a specific question to answer before a change is approved. Keep this record with the project scope and update it when the answer arrives. Record service names and responsibilities; handle account access through the business's secure process rather than putting passwords in the register.

Ask about the whole mail dependency

Have the email administrator confirm all provider-required records and mail-host dependencies that need to survive. MX is part of that discussion. Cloudflare's email troubleshooting guidance also identifies authentication records and mail-related hostnames as possible sources of delivery trouble. You may hear terms such as SPF, DKIM and DMARC; the useful owner-level question is who will verify the required setup for the services actually in use.

Keep website-form delivery in the conversation. A form might use a separate processor or sending service even when its notifications arrive in an ordinary business inbox. Ask where the submission goes, how it is sent and who can investigate if the recipient cannot find it.

Check the website, mail and form separately

Agree the checks and recipients before the move, using clearly labelled test messages without customer or sensitive information. Record the same paths before and after the change where practical. If a path already fails, show that in the baseline rather than treating it as a new migration fault.

• Website: open the agreed public page and follow its enquiry route. Record the address, time and observed result.
• Incoming mail: have an agreed external sender send a labelled message to the business address. The intended recipient confirms it arrived.
• Outgoing mail: send from the business account to an agreed external recipient and ask that person to confirm receipt. An internal message alone does not check this route.
• Website form: submit an arranged test from the actual page. Have the maintainer trace any stored submission and the nominated recipient check the expected notification or destination.

These checks answer different questions. For example, Webflow's troubleshooting guide distinguishes a submission recorded by its platform from an email notification reaching the recipient. Other systems have their own records and delivery paths. Ask your maintainer where to look instead of assuming every form has a submission dashboard.

A successful test establishes that the sampled route worked under the recorded conditions. It does not certify every mailbox, device or future message. Note what was checked, what remains untested and who owns each follow-up. If delivery fails, preserve the time and error details for the email administrator or relevant provider, keeping private message contents out of broadly shared notes.

Agree the stop, recovery and cancellation decisions

Before the change window, name the person who can halt the move and the people responsible for investigating or recovering a failed service. Ask them to explain the recovery plan and its limits. The appropriate steps depend on the actual systems; avoid making an improvised settings change during an owner review.

Make cancellation of an old service a separate, approved decision after its remaining dependencies and agreed acceptance conditions have been checked. For the wider redesign, use the website redesign preflight checklist to record other customer paths that must survive.

Bring the dependency list into your discussion of ZXP's website services. It helps define what the website project must preserve and which questions need answers from the people responsible for email.