Business Email on Your Own Domain: Migrate Without Interrupting Mail

Who manages the domain, DNS, email and website?

An address such as contact@your-domain.example depends on several components that may be managed by different providers. The domain identifies the organisation. Its DNS zone contains records directing services. The email provider hosts mailboxes, while web hosting serves the website. I start by separating those roles and identifying the necessary administrative access without asking anyone to place passwords in the working document.

This distinction prevents a common misunderstanding: moving email does not automatically mean moving the website. Microsoft says that configuring a domain for Microsoft 365 does not require transferring the website that uses the same domain. Microsoft 365 does require ownership verification and the DNS records needed by the enabled services. I therefore plan the mail change without touching unrelated website records.

I record the registrar, DNS host, current email provider, web host and the person authorised to approve each change. Microsoft warns that incorrect DNS configuration can interrupt mail or another service, so the migration stays limited to records that are understood and documented. If nobody knows where the DNS zone is managed, I resolve that first rather than improvise on cutover day.

Which addresses and services genuinely send mail?

A list of employees or volunteers is not enough. I inventory users, aliases, groups, shared mailboxes and role addresses. I add the devices and applications that still use the old email service: phones, invoicing software, website forms, scanners, printers or booking tools when they actually send mail for the domain. This map helps reveal an overlooked sender that would otherwise be forgotten.

I separate receiving, sending and forwarding functions. For each item I note an owner, useful recipients and the post-migration requirement, without storing a password. A legacy address may still feed a form or receive invoices. Removing it simply because it appears inactive in one mailbox can interrupt a real process.

The inventory also becomes the basis for domain authentication. Microsoft explains that SPF identifies sources authorised to send for the domain and that every real sending service must be identified before the SPF record is built. I therefore reject a generic SPF example copied from another domain: a valid value depends on the senders that are actually retained.

• users, aliases, groups and shared mailboxes;
• forms, software, devices and sending services;
• recovery addresses and an owner for each mailbox;
• items to retain, replace or remove after verification.

What should be backed up and prepared before cutover?

Before changing DNS, I document the existing records and useful settings from the old mail service. I agree with the organisation which data must be retained: messages, folders, contacts, calendars and any shared mailboxes. The backup or transfer method depends on the services involved. I do not promise that one export covers everything until its contents and restoration path have been checked.

I then create every required mailbox at the new provider, including the planned aliases and groups. Microsoft explicitly says that for a Microsoft 365 mail migration, users and their mailboxes must exist before the MX cutover. Each person needs to be able to sign in to the new environment and understand the intended authentication method before new mail begins arriving there.

I prepare a control sheet containing no secrets: address, mailbox type, owner, device to reconfigure, associated sender and test result. For a small business, association or holiday property in Dordogne, this simple record is more useful than an improvised switch during a busy period. It also helps separate an unprepared mailbox from a DNS fault.

In what order should DNS and MX records change?

I do not begin with the MX record. I first verify the domain using the provider’s process, then prepare the records required for the services that will genuinely be enabled. Mailboxes and user access are tested before cutover. Microsoft explains that changing the MX starts delivery of new messages to Microsoft 365, so this step is an operational handover rather than an administrative detail.

At the planned time, I modify only documented records and retain a copy of the previous values and the time of each action. I do not remove everything associated with the old service at the same time. The plan states which components must remain temporarily available for transition checks and which will be removed only after validation.

The website remains a separate check. After each important DNS stage, I confirm that its public address still responds and that the records serving it were not altered accidentally. A successful migration is not merely one message appearing in the new mailbox; it also preserves the domain’s other services.

• document the current zone;
• verify the domain and prepare services;
• create and test every mailbox;
• change the MX at the planned time;
• check email and the website before retiring the old service.

How should SPF, DKIM and DMARC match the real senders?

SPF, DKIM and DMARC are not three universal lines to copy. Microsoft says that SPF records for a custom domain are managed at its registrar or DNS host. SPF describes authorised sending sources, but Microsoft says it is not sufficient alone and also recommends DKIM and DMARC. ANSSI likewise recommends using all three together to check the authenticity of mail sent for a domain and reduce address impersonation risk.

For Microsoft 365, the custom domain must first be added and verified before DKIM signing can be enabled. Microsoft then requires two CNAME records. I do not treat the job as complete merely because they were entered: Microsoft requires detection of those records and confirmation of signing status. For another provider, I follow its official instructions rather than invent an equivalent setup.

DMARC checks alignment between the domain visible in the sender address and the SPF or DKIM results. Microsoft says SPF and DKIM should be configured for sending domains and subdomains before DMARC is applied. It recommends a progressive DMARC rollout, observing reports before reaching a reject policy. A strict policy deployed without an inventory or tests can reject legitimate mail, so I begin by understanding observed senders rather than immediately choosing the harshest rule.

Which tests confirm delivery, sending and website continuity?

I test several paths instead of sending one message to myself. An external address writes to every mailbox type; users reply externally; aliases, groups and shared mailboxes are checked according to their intended use. The inventoried forms and sending services are tested separately. Each result is associated with the relevant address and service so that nobody concludes too early that everything works.

I verify authentication using the tools and status indicators supplied by the relevant services, without publishing domain-specific values in the article. If a Microsoft account already appears compromised, a DNS migration is not enough to secure it. The process for regaining control of a hacked Microsoft account should be completed from a trusted device before credentials are reused.

I also check the public website, its forms and the devices that must continue sending. If somebody requests remote control to repair email, I apply the same caution as with any remote assistance. After suspicious access, my guide to a fake tech support remote-access incident explains what to verify before new credentials are entrusted to that computer.

What should be monitored after migration, and how can you roll back?

Cutover is not finished when the first messages arrive. I keep a monitoring period with a list of successful tests, reconfigured devices and senders still awaiting confirmation. User reports are compared with the original inventory. A missing message may point to a forgotten mailbox, an unlisted sending service or a rule that still needs investigation.

DMARC reports are observed before the policy is strengthened, following Microsoft’s progressive approach. I never promise a migration with no interruption whatsoever. The realistic objective is to prepare, test, observe and retain enough evidence to diagnose a problem quickly. Old settings are retired only after the required functions have been confirmed and according to the timetable agreed with the domain owner.

The rollback plan records the previous DNS values, the necessary administrative access, the condition that would trigger a rollback and the person authorised to decide. It does not guarantee that every situation can be reversed instantly, but it avoids searching for essential information under pressure. For a small organisation, I prefer a measured, documented migration to a fast switch that nobody can explain afterwards.