Post-Migration Checklist: Mail Flow, MFA, Mobile and Backups

The batches are complete and the MX points at Microsoft. The migration is not finished. The two weeks after cutover are when the quiet dependencies show up: the copier that stopped scanning, the rule that forwards a mailbox to a personal Gmail, the sales team on phones still using basic authentication, and the backup that nobody set up because the cloud was supposed to handle it.

This checklist is what we run through after every migration, in the order that catches the most problems soonest.

Mail flow in every direction

Test inbound from an outside address, outbound to an outside address, internal between two migrated users, and every relay path you found in discovery. Then read the message trace for each one and confirm it went through the connector you expect and not through a leftover hybrid path.

Check the things that send mail without a user: the scan-to-email copier, the ERP invoice run, the website form, the monitoring alerts, the backup report. Each of those is a support call if you wait for it to fail.

• Message trace shows inbound mail delivered to the cloud mailbox, not redirected.
• SPF, DKIM and DMARC pass on outbound to an external address.
• Every SMTP relay device sends successfully through its new path.
• Transport rules, disclaimers and journaling recreated in Exchange Online and tested.
• Distribution groups have owners and deliver to all members; external senders allowed where needed.
• Old hybrid connectors and organization relationships removed once nothing uses them.

Connect-ExchangeOnline
Get-MessageTrace -StartDate (Get-Date).AddHours(-24) -EndDate (Get-Date) -RecipientAddress user@domain.com | Select Received, SenderAddress, Subject, Status
Get-TransportRule | Format-Table Name, State, Priority
Get-DkimSigningConfig | Format-Table Domain, Enabled

Authentication: MFA on, legacy off

A migration that leaves basic authentication enabled or MFA optional has moved the risk to the cloud rather than reducing it. Microsoft has disabled basic authentication for most Exchange Online protocols, but SMTP AUTH can still be on per mailbox, and security defaults or conditional access decide whether MFA is actually enforced.

Confirm that every user has registered an MFA method, that conditional access or security defaults require it, and that SMTP AUTH is off for everyone except the service accounts that relay through it. Check for accounts excluded from MFA policies, because migration admin accounts and break-glass accounts often get excluded and forgotten.

Get-CASMailbox -ResultSize Unlimited | Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } | Select DisplayName, PrimarySmtpAddress
Get-TransportConfig | Select SmtpClientAuthenticationDisabled

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All", "Policy.Read.All"
Get-MgReportAuthenticationMethodUserRegistrationDetail -All | Where-Object { -not $_.IsMfaRegistered } | Select UserPrincipalName
Get-MgIdentityConditionalAccessPolicy | Select DisplayName, State

Mobile devices and the native mail app

Outlook for iOS and Android reconnects on its own in a hybrid migration and needs a remove-and-add in others. The native mail apps are the problem. Many were set up years ago against the on-prem server with a password, and after the move they either keep failing quietly or, worse, keep working through a path you meant to close.

Pull the list of active mobile devices per mailbox, see which client each one is, and decide the policy. The simplest is Outlook mobile for everyone with app protection through Intune if you have Business Premium or E3. If you must allow native apps, make sure they use modern authentication and that ActiveSync device access rules are set the way you intend.

Get-EXOMobileDeviceStatistics -Mailbox user@domain.com | Select DeviceModel, DeviceOS, DeviceType, LastSuccessSync, Status
Get-ActiveSyncOrganizationSettings | Select DefaultAccessLevel
Get-ActiveSyncDeviceAccessRule

Forwarding, rules and permissions

Two kinds of forwarding matter. Mailbox-level forwarding set by an admin usually survives the move and should be reviewed. Inbox rules that forward to external addresses are the classic sign of a compromised account, and some of them were created by users years ago for convenience. List both and decide each one.

Then check delegation. Full Access and Send As permissions on shared mailboxes move in hybrid, but permissions to mailboxes that moved in a different batch can break during the gap. Calendar delegation for executives and assistants is worth a direct test.

Get-Mailbox -ResultSize Unlimited | Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } | Select DisplayName, ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward
Get-Mailbox -ResultSize Unlimited | ForEach-Object { Get-InboxRule -Mailbox $_.Identity | Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo } | Select MailboxOwnerId, Name, ForwardTo, RedirectTo }
Get-Mailbox sales@domain.com | Get-MailboxPermission | Where-Object { $_.User -notlike "NT AUTHORITY*" } | Select User, AccessRights

Logging, backups and the old server

Turn on unified audit logging if it is not already on, so the next investigation has data. Confirm mailbox auditing is on by default. Then decide the backup question deliberately: Microsoft's retention features are not a point-in-time backup of mail and files, and if the business expects to restore a mailbox from three weeks ago, something has to be making that copy. Our post on backing up Microsoft 365 covers the options.

Finally, set the date for the old server. Shut it down after the relay devices are repointed and the tracking log is quiet, keep it off for a week, then follow the decommissioning process. A migrated organization with an unpatched Exchange server still on the network has not reduced its risk at all.

1. Unified audit log enabled and mailbox auditing confirmed.
2. Backup product selected, deployed, and a test restore of one mailbox completed.
3. Retention policy applied and documented.
4. Old Exchange server shut down, then removed after the quiet week.
5. Firewall rules for the old server removed, certificate revoked or allowed to lapse.
6. Documentation updated: DNS records, connectors, relay paths, admin accounts.

Get-AdminAuditLogConfig | Select UnifiedAuditLogIngestionEnabled
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
Get-OrganizationConfig | Select AuditDisabled

Frequently asked questions

Takeaway

Cutover is the midpoint. Test every mail path including the devices, enforce MFA and turn off SMTP AUTH where it is not needed, sort out phones, review forwarding, turn on auditing, and decide backups on purpose. Then shut the old server down and let the quiet week prove it is safe to remove.