Keep your email provider and mail DNS records in place when a website move does not require changing them. A website host, a DNS provider, and an email service can be separate companies. If changing hosts also means moving DNS or canceling a bundle that includes your mailboxes, plan for that separately.
Identify what is actually moving
Ask your new website host whether you can connect the site using changes in your current DNS account or whether the setup requires new nameservers. When the current DNS provider can stay in place, document which website records the host needs changed and which mail records should remain. If nameservers have to change, prepare the new DNS zone before switching them.
Check the old hosting bill and account before assuming email is separate. Some packages include the mailbox service, and some rely on an address at the old host even when a different company provides your inbox. Ask the old provider which services stop when you cancel. The domain, hosting, and business email guide explains where each piece fits.
Make a small mail inventory before the move
Write down the registrar, active DNS provider, mail provider, website host, and any service sending mail on your behalf. Include shared inboxes, aliases, forwarding rules, and website form destinations. An outside booking or invoice platform may send messages separately from your everyday mailbox.
What to record for each dependency
- Incoming mail: the provider, inboxes and aliases that receive messages, and current MX records, including priority.
- Outgoing mail: provider instructions and the existing SPF, DKIM, and DMARC records, plus any sending or verification subdomains.
- Website forms: the form endpoint or service, the approved sender identity, and the monitored inbox that receives notifications.
- Access: the people who can update DNS or mail settings, where the record export is stored, and who can restore the previous settings.
Copy record names, values, types, priorities, TTLs, and provider-specific settings. Export the zone where supported, and keep the export in a protected workspace. Do not include login credentials or API keys in the migration notes. Use the account ownership checklist if access is unclear.
Prepare the smallest DNS change that meets the plan
For a website-only move, use the new host's exact instructions for the root domain and any website subdomain such as www. Review mail dependencies before replacing an address record. For example, an MX target such as mail.example.com can depend on another DNS record pointing to the old host. An unchanged MX entry is not enough if its target disappears.
If you are moving the whole zone, compare the new records with the saved inventory before changing nameservers. Include subdomains, verification records, and the settings your mail provider requires. For Cloudflare, review its instructions for mail and proxy limitations. Keep the old configuration available until the new one is verified.
Test three message paths before and after cutover
- Inbound: from an external test mailbox you control, send a labeled message to the main business inbox and any critical alias. Confirm delivery in the intended inbox.
- Outbound: send a reply to your external test mailbox. Check delivery and the sender address. If your team has access to the message headers, compare authentication results with the baseline.
- Website inquiries: verify the form accepts a submission and the intended recipient receives the notification. Use a sandbox or an approved internal test destination, and check any saved submission record separately.
A working website only confirms the web path. Keep a short record of each test, the time, the inbox, and the outcome so the next person knows what was verified.
If a check fails, narrow down the path
- External mail cannot reach the business: verify which nameservers are serving the domain, the MX values and targets, and whether the recipient still exists at the provider.
- Outgoing mail is rejected or goes to spam: save the bounce or header results and have the mail provider check the configured sender and authentication records. Preserve the existing configuration while you diagnose it.
- Mailbox tests pass but the form is silent: check the new site's form endpoint, mail provider logs and configured recipient. The static website form guide explains how to distinguish a submission error from a delivery problem.
Decide who owns the follow-through
Before canceling old hosting, have the mailbox owner, website owner, and migration lead confirm what stays active and who handles failures. Keep the approved DNS change list and any rollback steps with the handoff notes. If email is still tied to the old hosting plan, confirm a separate mailbox migration or replacement before ending it.
For a self-managed static rebuild, the BUILD • PUBLISH • OWN IT guide covers the website publishing workflow. Use your mail provider's instructions for any change to the email service itself.
Sources and further reading
Plan the website move before changing DNS
Share your site URL, current web host and email provider, and which service you plan to move. Colby Technologies can review the website migration scope and identify what should stay with your mail provider.