logo
Dobble - Company Logo
Main Menu
Get a Quote

Learning Centre

What Should Be Checked Before Moving Business Email To Microsoft 365?

Planning a Microsoft 365 email migration? Learn what to check first, from domain access and DNS records to mailboxes, devices, security and website forms.

—
On this page

    Definition

    Microsoft 365 Email Migration Readiness Check

    A Microsoft 365 email migration readiness check is a review of your current email setup before mailboxes are moved. It should confirm domain access, DNS records, mailbox data, users, devices, security settings, backups, website forms, and any systems that send email on behalf of your business.

    The goal is not only to move mailboxes. It is to reduce the risk of missed emails, failed sending, broken authentication, device access problems, and avoidable disruption during the change.

    Key Checks Before Moving Email to Microsoft 365

    • Check domain ownership, DNS access, MX records, SPF, DKIM, and DMARC before changing anything. Email migration depends on accurate DNS control.
    • Audit every mailbox, alias, shared mailbox, group, forwarder, calendar, contact list, and application that sends email before deciding what needs to move.
    • Plan the cutover carefully. Microsoft 365 can provide strong business email capability, but DNS propagation, device setup, user passwords, and third-party systems can still cause temporary issues.

    Quick Explanation

    What Should Be Checked First?

    Before moving business email to Microsoft 365, you should check who controls the domain, where DNS is managed, which mailboxes and aliases exist, how email is currently authenticated, and which devices or systems rely on the old email service. A business email migration affects more than Outlook. It can affect website contact forms, invoices, scanners, booking platforms, CRM notifications, shared calendars, mobile phones, and staff access. If these dependencies are not reviewed first, a technically simple migration can still cause missed messages or confusion after cutover. The checks below are designed for business owners, managers, and internal IT contacts who want a clear understanding of what should be reviewed before moving to Microsoft 365.
    A planned Microsoft 365 email migration starts with access, DNS, users, and connected systems.
    A planned Microsoft 365 email migration starts with access, DNS, users, and connected systems.

    Do Not Change DNS Until the New Email Environment Is Ready

    MX records control where email for your domain is delivered. If they are changed before Microsoft 365 mailboxes, licences, users, and authentication records are ready, messages may bounce, be delayed, or arrive in the wrong place. DNS changes should be scheduled only after the new environment has been prepared and tested.

    Microsoft 365 Email Migration Checklist

    Use this checklist before moving business email to Microsoft 365. The exact migration path depends on your current provider, mailbox size, user count, domain setup, security requirements, and connected systems.

    • Confirm domain and DNS access

      Check who owns the domain, which registrar manages it, where nameservers are hosted, and who has permission to change DNS records. Without reliable DNS access, MX, SPF, DKIM, DMARC, Autodiscover, and verification records cannot be configured correctly.

    • Document users, mailboxes, aliases, and shared access

      List every user mailbox, shared mailbox, distribution group, alias, forwarder, calendar, contact list, and mailbox permission. This avoids losing important shared addresses such as accounts@, sales@, reception@, bookings@, or support@ during the migration.

    • Review email authentication and connected systems

      Identify systems that send email through your domain, including website forms, CRMs, accounting software, scanners, booking tools, and marketing platforms. These may require updated SPF, DKIM, SMTP, or application settings after Microsoft 365 is introduced.

    Existing Setup

    What to Check in the Current Email Environment

    Start by understanding how email works today. Many businesses have email that has grown over time, often across old hosting accounts, former providers, or undocumented settings. A migration is much safer when the current state is known before anything is moved. Important checks include the current email provider, mailbox storage, user passwords, admin access, alias lists, shared inboxes, forwarding rules, calendar sharing, and any active devices. You should also check whether mail is being downloaded into local software using POP, synchronised through IMAP, or already hosted in another cloud platform. The mailbox protocol matters because it affects what can be migrated. IMAP usually moves email folders but may not include calendars, contacts, rules, signatures, or local-only mail. POP accounts can be riskier because messages may be stored on individual computers rather than on the server. If a staff member leaves, or an old computer fails, that mail may be hard to recover unless it has been backed up. It is also worth checking old email accounts that still receive important messages. These may include addresses for invoices, job enquiries, domain renewals, payment gateways, supplier portals, and staff logins. If those accounts are missed, important notifications can disappear quietly after cutover.
    Documenting the current setup reduces surprises during and after migration.
    Documenting the current setup reduces surprises during and after migration.

    Key Email Migration Terms

    These terms often appear during Microsoft 365 email migrations. Understanding them helps you ask better questions and avoid common configuration mistakes.

    MX Record
    A DNS record that tells other mail servers where email for your domain should be delivered. During migration, the MX record usually changes to point to Microsoft 365.
    SPF, DKIM, and DMARC
    Email authentication records that help receiving servers check whether messages sent from your domain are legitimate. They improve deliverability but do not guarantee inbox placement.
    Autodiscover
    A configuration record that helps email apps find the correct Microsoft 365 settings automatically. It is important for Outlook and mobile device setup.

    Migration Process

    A Practical Microsoft 365 Email Migration Sequence

    The order of work matters. A rushed cutover can interrupt business email, while a staged process gives you time to test users, DNS, devices, and sending behaviour before old services are retired.

    1. Audit and prepare

      Review the existing email provider, domain access, DNS records, mailbox list, aliases, connected systems, backup position, and user requirements. Decide what needs to migrate and what can be retired.

    2. Build and test Microsoft 365

      Create users, assign suitable licences, configure the domain, prepare authentication records, test sending and receiving, and confirm access on selected devices before the final cutover.

    3. Cut over and monitor

      Change MX and related DNS records at the planned time, help users sign in, test website forms and third-party systems, monitor delivery, and keep the old environment available until migration is confirmed.

    Example DNS Records to Review

    These are example record types only. Microsoft 365 and your DNS provider will supply the exact values for your domain. Do not copy these placeholders into a live DNS zone.

    dns 
    MX      example.com.au      points to Microsoft 365 mail protection host
TXT     example.com.au      SPF record authorising permitted senders
CNAME   autodiscover        points to Microsoft 365 Autodiscover
TXT     selector._domainkey DKIM record supplied by Microsoft 365
TXT     _dmarc              DMARC policy for authentication handling

    DNS values vary by tenant, domain, provider, and sending requirements.

    DNS and Deliverability

    Why DNS Records Matter During the Move

    DNS connects your domain to the services that use it. For email, the most important records usually include MX, SPF, DKIM, DMARC, and Autodiscover. If these records are missing, duplicated, or incorrectly formatted, your business may experience delivery failures, spam filtering issues, or device setup problems. The MX record controls where inbound email is delivered. SPF lists servers that are authorised to send email for your domain. DKIM signs outgoing messages so receiving servers can check that the message has not been altered. DMARC tells receiving servers how to handle messages that fail authentication checks. Autodiscover helps email apps locate mailbox settings. Email authentication improves trust, but it does not guarantee that every message will reach the inbox. Delivery and inbox placement can also depend on domain reputation, message content, recipient behaviour, Microsoft 365 policies, third-party mail systems, and spam filtering rules. This is why DNS should be correct from day one, but expectations still need to be realistic. If your domain also sends email through a website, CRM, accounting platform, booking system, scanner, or marketing tool, those senders need to be reviewed before SPF and DKIM records are changed. Otherwise, messages from those systems may fail authentication after the migration.
    Email authentication depends on correctly configured DNS records.
    Email authentication depends on correctly configured DNS records.

    Common Problems After a Poorly Planned Migration

    These symptoms are often preventable when the right checks are completed before moving to Microsoft 365.

    Some users receive email while others do not

    Likely cause

    Mailboxes, aliases, forwarding rules, or shared inboxes may not have been created correctly in Microsoft 365 before the MX record was changed.

    Solution

    Compare the old provider’s mailbox and alias list with Microsoft 365, then test each important address. Keep the old service accessible until the migration is verified.

    Website forms stop sending notifications

    Likely cause

    The website may still be sending through the old mail server, or SPF and SMTP settings may not authorise the website to send through the domain.

    Solution

    Review form notification settings, SMTP configuration, SPF records, and any application-specific sending requirements. Test form delivery after cutover.

    Emails land in spam after the move

    Likely cause

    SPF, DKIM, or DMARC may be missing, duplicated, too restrictive, or not aligned with all legitimate sending sources.

    Solution

    Audit the domain’s authentication records and identify every system that sends email on behalf of the business. Adjust records carefully rather than adding random entries.

    Mistakes to Avoid Before Moving to Microsoft 365

    Most email migration issues are caused by incomplete preparation rather than Microsoft 365 itself. These mistakes are common when email, DNS, websites, and domains are managed separately.

    Only migrating named staff mailboxes

    Do this instead

    Check role-based addresses, shared mailboxes, aliases, groups, and forwarders. Addresses such as accounts@, jobs@, admin@, and info@ often carry business-critical messages.

    Forgetting systems that send automated email

    Do this instead

    Review website forms, invoicing tools, CRMs, booking platforms, scanners, and marketing systems. These may need updated SMTP settings or DNS authentication after the migration.

    Assuming DNS propagation is instant

    Do this instead

    Plan for a transition period. DNS changes can take time to update across networks due to TTL values, caching, provider behaviour, and local device settings.

    Before and After Migration Checks

    A Microsoft 365 migration should not end the moment the MX record changes. The checks before and after cutover are different, and both matter.

    Check Area Before Cutover After Cutover
    Mailboxes and aliases Confirm every mailbox, shared inbox, alias, forwarder, and group that needs to exist in Microsoft 365. Test sending and receiving for critical addresses, especially accounts, support, sales, bookings, and website notification addresses.
    DNS and authentication Prepare MX, SPF, DKIM, DMARC, Autodiscover, and verification records using provider-supplied values. Check propagation, run test messages, review authentication results, and adjust records if legitimate senders are failing.
    Users and devices Plan passwords, multi-factor authentication, Outlook profiles, mobile access, and staff communication. Support users with sign-in, profile setup, cached credentials, mobile mail apps, and any shared mailbox access issues.

    Security and Access

    Security Settings That Should Be Considered

    Moving to Microsoft 365 is a good time to review email security, but security still depends on correct configuration and user behaviour. At a minimum, businesses should consider administrator access, password practices, multi-factor authentication, recovery methods, and how former staff accounts are handled. Administrator accounts should be limited to people who genuinely need that level of control. Shared administrator logins can make accountability difficult and increase risk if a password is exposed. User accounts should be created with clear ownership, and access for former staff should be removed or converted carefully so important business records are not lost. Multi-factor authentication can reduce the risk of account compromise, but it needs to be introduced with proper staff communication. Users should know what to expect, how to set up authentication, and who to contact if they lose access to a phone or authenticator app. You should also check whether old mailboxes contain sensitive information that needs to be retained, archived, or handled under your own business policies. We cannot provide legal or compliance advice in this article, but migration planning should take retention and access requirements seriously.
    Security planning should include access control, authentication, staff communication, and account ownership.
    Security planning should include access control, authentication, staff communication, and account ownership.

    Related Service

    Email Hosting and Management

    We help businesses manage professional email on their own domain, including Microsoft 365 business email where suitable, DNS authentication, migration support, user setup, and ongoing technical management. Email services are subject to the relevant provider’s availability, policies, and limitations.

    View Email Hosting and Management

    Our Approach

    How We Approach Microsoft 365 Email Migrations

    We primarily use Microsoft 365 for business email hosting, although other reputable third-party providers may be used where client requirements call for them. Our approach is to treat email, DNS, domains, hosting, and websites as connected business infrastructure rather than isolated services. Before migration, we review the existing email, domain, and DNS settings so the new environment can be prepared properly. Where practical, mailboxes and settings are prepared before final cutover, DNS changes are coordinated carefully, and testing is completed for sending, receiving, authentication, and user access. This planning is designed to minimise disruption, but no email provider can guarantee uninterrupted availability, inbox placement, or spam filtering outcomes. Microsoft 365 and other third-party platforms are subject to their own service availability, policies, and technical limits. DNS propagation, third-party outages, internet caching, device settings, and old provider restrictions can also affect the migration window. For businesses already using our domain, hosting, website, or maintenance services, having one technical contact can reduce provider finger-pointing. If the website form stops sending, the domain records look wrong, or a Microsoft 365 record needs checking, the same technical view of the environment can make diagnosis more practical.
    A connected view of email, DNS, domains, and websites helps reduce migration risk.
    A connected view of email, DNS, domains, and websites helps reduce migration risk.

    Microsoft 365 Email Migration FAQs

    These questions cover common concerns before moving business email to Microsoft 365.

    Will moving to Microsoft 365 stop emails going to spam?
    Not by itself. Correct SPF, DKIM, and DMARC records can improve email authentication, but inbox placement also depends on sender reputation, message content, recipient behaviour, and mail provider filtering.

    Can email be migrated without downtime?
    A well-planned migration can minimise disruption, but temporary issues may still occur due to DNS propagation, third-party providers, device settings, cached records, or old provider limitations.

    What access is needed before a Microsoft 365 migration?
    You usually need access to the domain registrar or DNS provider, the current email administrator account, user mailbox details, and any systems that send email using the business domain.

    Planning a Move to Microsoft 365?

    If your business email, domain, website, and DNS records are spread across different providers, migration planning matters. We can review your current setup, identify risks, and help plan a Microsoft 365 email migration with practical checks before cutover.

    Discuss Your Email Requirements View Domain Name Management

    Keep learning

    Related articles

    See all articles
    Tap to call
    Enquire now

    Ask Dobble

    Ask a question

    Send us your question and the Dobble team will get back to you.

    Prefer to talk to us directly?

    0423 016 104 [email protected]

    Get in touch

    Contact us

    Tell us about your project and the Dobble team will be in touch shortly.

    Prefer to talk to us directly?

    0423 016 104 [email protected]