Move Business Email Domains Without Losing the Basics

A business email migration is more than replacing MX records. Inventory users, aliases, shared addresses, groups, forwarding, calendars, contacts, archives and devices. Record the full existing DNS zone and the new provider’s current requirements. Confirm ownership and administrative access without exposing credentials in a shared checklist. A website domain move does not necessarily require moving email, so define the exact objective first. Keep public website records and email routing separate in the plan, even when the same registrar hosts both.

Create the required destination mailboxes and address mappings before changing inbound routing. Use the provider’s supported migration method and check what it does not migrate: an email copy may exclude calendars, contacts, permissions or other services. Run a small pilot and compare message counts, folders or labels, attachments and date ranges. Keep the source available under a defined retention plan. A successful migration job label does not prove every account, alias and device is ready for cutover.

Document the exact MX, SPF, DKIM and DMARC changes, responsible operator and rollback values. Do not blindly replace the entire DNS zone or create competing SPF records. Third-party senders such as invoicing, newsletters and support systems need their own authentication review. Schedule the change with an overlap and monitoring plan because resolver caching can produce a transition period. A rollback should restore known values and preserve mail already received at either provider, not simply point traffic back and forget the split inboxes.

Test inbound and outbound mail with independent external addresses, replies, aliases, shared mailboxes and important automated senders. Inspect authentication results in received headers and verify calendar or contact behavior where relevant. Record actual delivery and reply outcomes rather than treating a provider dashboard as end-to-end proof. Check delayed mail, bounces and source inboxes during the transition. Retire the source only after the agreed verification and retention steps, with a documented owner for any remaining discrepancy.

List missing folders, unsupported data types and addresses still using the source provider. Assign an owner and a safe resolution path to each. Closing the migration means those exceptions are resolved or explicitly accepted with retained access, not hidden behind one overall successful job status.