Why should the migration scope be defined first?
Before moving to Microsoft 365, the first question is not how many mailboxes need to move, but how the current mail environment is actually being used. Calendars, contacts, archives, shared addresses, shared mailboxes, and messages generated by applications may all depend on the same environment.
Listing active employees is therefore not enough. Former-user accounts, forwarding rules, aliases, distribution lists, scanner and printer sending, website forms, and business applications such as accounting software should also be checked. If one of these is missed, user mailboxes may work while another business process quietly stops.
The migration method should be chosen from that inventory. Some methods move only mailbox content, while calendars, contacts, tasks, permissions, or archives may need different preparation. Knowing what has to move first makes it easier to confirm whether the chosen method really covers the requirement.
Why are domain ownership and administrative access critical?
Microsoft 365 requires ownership of the custom domain to be verified before it can be used. This is usually done with a DNS verification record. Migration day is not the time to start finding out who controls DNS. Registrar access, DNS administration, and the required administrator accounts should already be known.
The domain registration, DNS service, and website may all have been purchased from the same provider, but they are technically separate responsibilities. Changing a mail-related DNS record does not require moving the website. Likewise, changing name servers is not an automatic step in an ordinary mail migration.
The important point is not to make broad DNS changes without first seeing the existing zone. Website records, third-party verification records, SPF senders, and other services may already depend on the same domain. Records unrelated to Microsoft 365 should be preserved while the required Microsoft records are added or changed.
- Which registrar holds the domain and who controls the account
- The authoritative DNS panel and working administrator access
- Current MX, SPF, DKIM, DMARC, Autodiscover, and verification records
- Mail dependencies for websites, forms, printers, scanners, and applications
- Renewal dates for the domain, certificates, and related services
When should users and mailboxes be prepared?
Users and required mailboxes should be ready before the MX record is pointed to Microsoft 365. The reason is simple. Once MX changes, new inbound mail starts going to Microsoft 365. If an address does not exist on the new side, that message may not reach the intended destination.
Microsoft's administrator guidance also recommends creating users and mailboxes before changing MX. Another point is often confused here: changing MX does not move existing email into Microsoft 365. Existing content is migrated separately, or left in the old environment, depending on the migration method.
Primary addresses, aliases, shared mailboxes, and groups should be checked individually. Administrator accounts should not simply be treated like ordinary daily-use accounts either. On the licensing side, the plan should reflect the applications, storage, device management, and security controls people actually need rather than assigning the same plan to everyone by default.
How should the DNS change be sequenced?
Taking a copy of the current DNS records before making changes is a sensible starting point. The values to be used should then come from the actual Microsoft 365 tenant, not from a generic example found online. That avoids using records that belong to another tenant or an outdated configuration.
MX determines where new inbound mail is delivered. SPF helps identify which systems are authorised to send mail for the domain. DKIM deals with signing outbound messages, while DMARC describes how SPF and DKIM results are evaluated against the domain's policy. They often appear together in migration work, but they do not perform the same job.
Existing senders matter particularly for SPF. If the website, accounting software, printer, CRM, or another service sends mail on behalf of the domain, those systems must be considered when the new mail setup is prepared. Adding multiple independent SPF records for the same domain is not the right way to solve this.
DNS changes may not become visible everywhere at the same second. Caches can cause old and new answers to appear for a period of time. After the change, it is therefore not enough to see the right value in the DNS panel. Real inbound and outbound mail flow should also be tested.
What should the pilot, rollback, and acceptance plan include?
If the migration method supports it, a small pilot group helps test assumptions with real users. The test should go beyond whether Outlook opens. Web access, mobile devices, calendar sharing, shared mailboxes, and mail flow with external recipients should also be checked.
Website and business-application sending needs its own test as well. A user's mailbox can work perfectly while a website form can no longer send notifications. These are separate flows and should not be treated as one successful test.
A rollback plan is more than writing down the old MX value. The team should know what would trigger a rollback, how messages created in the old and new environments would be handled, and what users would be told. Even if the DNS change can technically be reversed, data created during the cutover still has to be accounted for.
- Inbound, outbound, and internal mail flow
- Expected SPF, DKIM, and DMARC results
- Calendars, contacts, mobile devices, and shared mailboxes
- Mail sent by the website and business applications
- How long the old environment will remain accessible
- The new sign-in, password, and MFA process for users
- Who has authority to make the rollback decision
In a Microsoft 365 migration, the DNS change is the middle of the work, not the beginning.
If users, addresses, existing mail data, application senders, and the current DNS environment are understood first, the MX cutover becomes far more predictable. The real preparation is completed before anyone presses the change button.
This article is for general information. It does not replace a technical assessment of your environment, a security guarantee, or legal advice.