How to Validate Office 365 Mailbox Migration Success

Why Migration Validation Matters

Most migration failures are not dramatic. Mail does not stop entirely. The server does not go down. Instead, problems surface quietly over days and weeks: a few folders missing from a specific user's mailbox, a shared mailbox that most people can access but one person cannot, a recurring calendar event that did not carry over, mobile devices that appear connected but are pulling from a cached copy of old data.

These issues share one cause: the migration was assumed successful rather than verified. Proper validation catches them before users notice, before the source environment is decommissioned, and before the evidence needed to fix them disappears.

Validation is not optional. It is the final stage of migration, and it deserves the same structured attention as the migration itself.

Step 1 - Verify Mailbox Item Counts

The first and most fundamental check is confirming that what was in the source environment is now in the destination.

What to check:

Compare the total item count and total mailbox size in the source against the destination for each migrated mailbox. A destination mailbox that is significantly smaller than the source is a clear sign that items did not transfer.

Small size differences are normal and expected. When Office 365 stores items, it compresses attachments and removes certain metadata that inflates PST or Exchange sizes. A destination mailbox that is 5 to 15 percent smaller than the source is typically fine. A difference of 30 percent or more warrants investigation.

How to check in the Microsoft 365 admin center:

1. Go to the Exchange Admin Center (EAC) in Microsoft 365.
2. Navigate to Recipients and select Mailboxes.
3. Select a mailbox and view the mailbox usage details.
4. Compare total item count and storage used against your pre-migration source audit.

How EdbMails helps:

EdbMails generates a detailed migration report after each migration job that logs the number of items migrated per folder, per mailbox, and across the entire batch. You can compare this report directly against your pre-migration mailbox audit to confirm every item was processed. If any items were skipped or failed, the report identifies them by folder and item type so you can rerun just those items. This removes the guesswork from item count verification completely.

Step 2 - Test Mail Flow

After migration, mail must flow correctly in all four directions. Testing only one direction and moving on is a common mistake.

The four mail flow tests to run:

Internal to internal: Send an email from one migrated Office 365 mailbox to another. Confirm it arrives promptly without errors.

Internal to external: Send an email from a migrated Office 365 mailbox to an external address (Gmail, another domain). Confirm the recipient receives it and the sender address shows the correct domain.

External to internal: Send an email from an external account to a migrated Office 365 mailbox. This is the most important test because it confirms your MX records are routing incoming mail to Office 365 and not still pointing at your old server.

Reply chain test: Initiate a reply conversation between an internal and external address. Confirm that threading, headers, and reply-to addresses are all correct.

What to look for:

• Emails arriving with correct sender display names
• No NDR (non-delivery report) bounce messages
• Correct timestamps in received headers
• No mail still arriving at the source server after MX record update

If external mail is still arriving at your old server after the MX record change, check DNS propagation. Use a tool like MXToolbox to confirm your domain's MX record is resolving to Office 365 globally.

Step 3 - Confirm DNS Records Are Correctly Updated

DNS errors are the most common cause of post-migration mail flow problems. An MX record pointing to the wrong server, a missing SPF record, or an incorrect Autodiscover CNAME will cause issues that are easy to miss if you only look at whether Outlook opens.

DNS records to verify after Office 365 migration:

MX record: Must point to your Office 365 MX endpoint (formatted as yourdomain-com.mail.protection.outlook.com). If this still points to your old server or hosting provider, all incoming mail is going to the wrong place.

Autodiscover CNAME: Must point to autodiscover.outlook.com. This record controls how Outlook and mobile clients automatically discover and connect to Office 365. A missing or incorrect Autodiscover record means users have to configure Outlook manually, and mobile devices will fail to configure automatically.

SPF record: Must include include:spf.protection.outlook.com. Without this, emails sent from Office 365 on behalf of your domain may be flagged as spam by receiving mail servers.

DKIM: Enable DKIM signing for your domain in the Microsoft 365 Defender portal. Without DKIM, your domain's outbound emails lack a cryptographic signature that many receiving servers now require.

DMARC: A DMARC record ties SPF and DKIM together and tells receiving servers what to do with mail that fails both checks. At minimum, set a DMARC policy of p=none during migration to begin collecting reports without affecting delivery.

How to verify:

Use MXToolbox (mxtoolbox.com) to run a full DNS health check against your domain. It will flag any missing, incorrect, or conflicting records. Run this check from outside your organization's network to see what external mail servers actually see.

Step 4 - Validate Calendar and Contact Migration

Email items are straightforward to count and verify. Calendar events and contacts require a different kind of validation because they are time-sensitive and relationship-dependent.

Calendar checks:

• Open the calendar for a selection of migrated users and verify that historical appointments exist and display correctly.
• Check recurring events specifically — these are the most likely to be incomplete or missing an instance.
• Verify that future appointments are present and show the correct time, attendees, and location.
• Confirm that calendar sharing permissions are intact for users who had shared their calendar with colleagues.
• Check free/busy visibility: if you are in a hybrid environment with on-premises mailboxes still active, on-premises users should be able to see free/busy for migrated Office 365 users and vice versa.

Contact checks:

• Open the Contacts folder for several migrated users and confirm that contacts are present.
• Spot-check a few contacts against the source to confirm that phone numbers, email addresses, and other fields transferred correctly.
• Verify that distribution group membership is correct in the Exchange Admin Center.
• Confirm that contacts saved in users' personal address books appear in their migrated mailboxes.

A practical approach:

Rather than checking every user, select a representative cross-section: one power user with a large and active calendar, one user who had shared calendar access, one user with a high contact count, and one user who used public contacts heavily. If these four pass, the broader population is likely clean.

Step 5 - Verify Shared Mailbox Access and Delegate Permissions

Shared mailboxes and delegate access are two of the most commonly broken items in an Office 365 migration. They fail silently — the mailbox appears in Office 365, but the users who need to access it find they cannot, or find their permissions have changed.

Shared mailbox validation:

• Open each shared mailbox in Outlook or Outlook on the web and confirm it loads correctly.
• Verify that all users who had access to the shared mailbox before migration can still open it.
• Send a test email to the shared mailbox from an external address and confirm it arrives.
• Send an email from the shared mailbox and confirm the From address shows the shared mailbox address, not the delegate's personal address.
• Check that sub-folders inside the shared mailbox are visible and accessible.

Delegate permission validation:

• For each user who had delegate access (Send As, Send on Behalf, or Full Access) before migration, verify those permissions are in place in the migrated environment.
• Test Send As and Send on Behalf specifically by sending a test email using each permission type and confirming the received message shows the correct From or Sender header.
• Check that users with Full Access can open the delegated mailbox from their own Outlook profile without being prompted for credentials.

In EdbMails:

EdbMails preserves mailbox permissions during migration and includes permission migration status in its post-migration report. Check the report for any mailboxes where permission migration was flagged, and reapply those permissions manually if needed before the source environment is decommissioned.

Step 6 - Validate Archive Mailboxes

If your organization uses archive mailboxes, these need to be validated separately from primary mailboxes. Archive mailbox items do not automatically appear in the primary mailbox count and are easy to overlook in a post-migration review.

What to check:

• Confirm that archive mailboxes are enabled in Office 365 for users who had them in the source environment.
• Open the archive mailbox in Outlook (it appears as a separate mailbox in the folder pane) and verify that archived items are present.
• Compare archive mailbox item counts against your pre-migration audit.
• Check that auto-archive policies are correctly applied if you had them configured in the source environment.
• For users with auto-expanding archives (more than 100 GB of archive data), confirm that all auxiliary archive portions transferred correctly.

Why this matters:

Archive mailboxes often contain years of compliance-relevant email. A primary mailbox that looks complete can mask a partially migrated or entirely missing archive. Organizations subject to legal holds, eDiscovery requirements, or data retention policies cannot afford to discover archive gaps after the source has been decommissioned.

See Office 365 archive mailbox migration guide

Step 7 - Check Public Folder Migration

Public folders are the most commonly incomplete item in an Office 365 migration. They are often left until last, and because not every user accesses them daily, gaps can go undetected for a long time.

What to check:

• Confirm that the public folder hierarchy in Office 365 matches the source hierarchy exactly — same folder names and the same nesting structure.
• Open a selection of public folders across different branches of the hierarchy and verify that items are present.
• Check that permissions on each public folder have carried over correctly — users who had read-only access should not now have edit access, and vice versa.
• Send an email to any mail-enabled public folders and confirm delivery works.
• Confirm that sub-folders within public folders are accessible and not missing items.

Practical tip:

Compare the total item count of the source public folder tree against the migrated destination using PowerShell or your migration tool's report. A quick count comparison is faster than manually opening every folder and is a reliable early signal of completeness.

See Office 365 public folder migration guide

Step 8 - Validate Outlook Client Connectivity

A mailbox that exists in Office 365 is only useful if Outlook can connect to it. After migration, each user's Outlook profile needs to be pointing at the new Office 365 mailbox rather than the old server.

What to check:

• In Outlook, go to File and look at the account information. The account type should show Microsoft 365 or Exchange (pointing to outlook.office365.com), not your old Exchange server name or hosted provider.
• Check the connection status by holding Ctrl and right-clicking the Outlook system tray icon, then selecting Connection Status. All connections should show Connected to Microsoft Exchange via HTTPS.
• Send and receive a test email from Outlook to confirm it is using the new mailbox.
• Check that the full folder structure is visible in Outlook, including subfolders that existed before migration.
• Verify that the Offline Address Book (OAB) has updated so that autocomplete in the To field reflects the current Office 365 address book.

For Outlook on Mac:

Remove the old Exchange account from Outlook for Mac and add the Office 365 account fresh. Autodiscover will configure the settings automatically if your Autodiscover CNAME is correctly pointed to autodiscover.outlook.com.

For Outlook on the Web:

Log into outlook.office.com and verify that mail, calendar, and contacts are all accessible and correctly populated.

Step 9 - Validate Mobile Device Connectivity

Mobile devices are one of the most overlooked areas in post-migration validation. Many users simply do not report mobile mail issues — they switch to checking email on a desktop browser and assume the mobile problem will resolve itself.

What to check:

• Ask a representative sample of users to confirm their mobile email app is receiving new mail and can send email.
• On iOS and Android, remove the old Exchange ActiveSync or IMAP account and add the Office 365 account fresh using the Microsoft Outlook app or the native mail client with the correct Office 365 server settings.
• Confirm that calendar sync is working on mobile — new appointments created in Office 365 should appear on the mobile calendar within minutes.
• Check that contacts are syncing to the mobile device's address book if the organization uses Exchange ActiveSync contact sync.

Server settings for manual mobile configuration if Autodiscover does not work:

• Server: outlook.office365.com
• Port: 443
• Security type: SSL/TLS
• Username: Full email address

Step 10 - Run a Final Incremental Migration Pass

Even after your main migration is complete and validated, some items may have arrived in the source mailbox during the migration window and not yet transferred to Office 365. Running a final incremental pass before decommissioning the source catches these.

What this covers:

• New emails that arrived at the source mailbox after the main migration batch completed.
• Calendar updates or meeting responses that were processed during migration.
• Contact changes made by users during the migration period.

How EdbMails handles this:

EdbMails incremental migration compares the source and destination mailboxes and migrates only items that are new or changed since the last run. You can run incremental passes as many times as needed without creating duplicate items in the destination. This is the safest way to close the gap between migration completion and MX record cutover. See incremental migration

When to run it:

Run one final incremental pass immediately before or immediately after switching MX records, but before decommissioning the source. The source mailbox should remain active and accessible until this pass is confirmed complete.

Step 11 - Verify Security and Compliance Settings

A successful mailbox migration is not only about data completeness. Your security and compliance configuration also needs to be verified in the new Office 365 environment.

What to check:

Multi-factor authentication (MFA): Confirm that MFA is enforced for all migrated users. Users who were not enrolled before migration should complete enrollment before their first login to Office 365.

Litigation holds and eDiscovery: If any mailboxes were under litigation hold in the source environment, verify that the hold has been applied in Office 365 before decommissioning the source. Mailbox items under legal hold must not be deleted between environments.

Retention policies: Confirm that any email retention or deletion policies you configured in Office 365 are applied correctly to migrated mailboxes. Items that should be retained are not expiring early, and items that should be deleted are not being retained indefinitely.

Audit logging: Confirm that unified audit logging is enabled in the Microsoft 365 compliance center. This should have been enabled before migration began, but verify it is active now that users are working in the new environment.

Anti-spam and anti-malware policies: Verify that Microsoft Defender for Office 365 anti-phishing, anti-spam, and safe links policies are active and applied to migrated user mailboxes.

Step 12 - Confirm with End Users and Close Out

Technical validation by IT is necessary but not sufficient. End users are the final judge of whether a migration worked. Some issues only surface through daily use — an Outlook add-in that no longer works, a rule that was not migrated, a contact that appears under a different name.

End user validation steps:

• Send a post-migration confirmation email to all migrated users asking them to verify three things: that they can send and receive email, that their calendar history is intact, and that their contacts are accessible.
• Set up a short feedback window (48 to 72 hours) where users can report issues directly to the IT helpdesk without going through the normal ticket queue.
• Follow up specifically with users who had complex setups: delegates, shared mailbox access, large mailboxes, or heavy use of public folders.
• Confirm that line-of-business applications that send or receive email (CRM systems, ticketing systems, scanners, automated alerts) are working correctly with the new Office 365 mailboxes.

Before closing out:

• Keep the source environment running in read-only mode for a minimum of 30 days after migration. This gives you a recovery option if a significant item is discovered missing after decommissioning pressure increases
• Document the migration completion date, the tool used, the item counts before and after, and all DNS changes made. This record is valuable for audits, future migrations, and troubleshooting any issues that surface months later

Office 365 Migration Validation Checklist at a Glance

Use this as your sign-off checklist before decommissioning the source environment:

Data completeness:

• Mailbox item counts compared against the pre-migration audit for all users.
• EdbMails migration report reviewed, with all failed items identified and rerun.
• Archive mailboxes verified separately.
• Public folder hierarchy and item counts confirmed.

Mail flow:

• Internal to internal mail tested.
• Internal to external mail tested.
• External to internal mail tested (most critical).
• Reply chain tested.

DNS:

• MX record pointing to Office 365.
• Autodiscover CNAME pointing to autodiscover.outlook.com.
• SPF record includes Office 365.
• DKIM enabled and verified.
• DMARC record in place.

Data types:

• Calendar events verified (historical, recurring, and future).
• Contacts verified.
• Shared mailbox access confirmed for all users.
• Delegate permissions (Send As, Send on Behalf, and Full Access) tested.

Client connectivity:

• Outlook desktop connected to Office 365.
• Outlook on the web accessible.
• Mobile devices reconnected and syncing.

Security and compliance:

• MFA enforced for all users.
• Litigation holds verified.
• Retention policies applied.
• Audit logging active.

Final steps:

• Incremental migration pass completed.
• End-user confirmation received.
• Migration documentation saved.
• Source environment retained in read-only mode for 30 days.

Common Validation Failures and How to Fix Them

External mail still arriving at the old server after MX record change

DNS propagation can take 24 to 48 hours globally even after you update the record. If external mail continues arriving at the old server beyond 48 hours, check your DNS TTL — if it was set high before migration (3600 seconds or more), it may take longer to propagate. Use MXToolbox to check what external DNS resolvers are seeing for your domain.

Outlook showing Connected but not syncing new mail

This usually means Outlook is still caching data from the old server. Create a new Outlook profile rather than modifying the existing one. A fresh profile forces Autodiscover to reconfigure from scratch.

Calendar events present but showing wrong times

This is a timezone mismatch issue. It most commonly happens when migrating from systems where the server timezone and the user's profile timezone were different. Check the user's timezone settings in Outlook and in their Office 365 account settings and make sure they match.

Shared mailbox accessible but Send As permissions broken

Send As permissions in Office 365 are managed differently from on-premises Exchange. They must be explicitly granted through the Exchange Admin Center under mailbox delegation, or via PowerShell using Add-RecipientPermission. Granting a user Full Access to a mailbox does not automatically grant Send As.

Item count is lower than expected after migration

First check the EdbMails migration report for any items flagged as skipped or failed. Common causes are oversized items (attachments above the Office 365 attachment size limit), corrupted source items, or items with invalid metadata. EdbMails logs each skipped item with the reason, making it straightforward to identify and address.

Mobile devices showing old email after reconnecting

After adding the new Office 365 account on a mobile device, the local mail cache from the old account may still be visible. Delete the old account profile from the device completely before adding the new one to ensure a clean connection to Office 365.

Additional Resources

For the steps that come before validation, these EdbMails guides cover each stage of the migration process:

• Office 365 migration methods and types guide
• Office 365 migration checklist
• Office 365 migration best practices
• Office 365 migration challenges and how to avoid them
• Zero downtime Office 365 migration
• Incremental migration with EdbMails
• Office 365 tenant to tenant migration
• Exchange to Office 365 migration
• Office 365 migration software

Conclusion

A migration is not complete when the last mailbox appears in Office 365. It is complete when every item has been verified, every client is connected, DNS is routing correctly, shared mailboxes and delegates work, security policies are in place, and users have confirmed everything is accessible.

The twelve validation steps in this guide give you a structured, repeatable process to confirm your Office 365 migration is genuinely done rather than just technically finished. Working through them systematically, with EdbMails migration reports as your evidence trail, means you can decommission your source environment with confidence rather than with fingers crossed.