Troubleshooting 550 5.1.10 Recipient not found after Office 365 migration

Migrating an organization's email infrastructure to Office 365 (now Microsoft 365) is a significant undertaking. While the promise of cloud-based reliability and scalability is enticing, the journey often includes unexpected turbulence. One of the most frustrating errors you might encounter post-migration is the seemingly straightforward yet maddening 550 5.1.10 Recipient not found or Recipient address rejected: User unknown in local recipient table. This error, originating from Office 365 itself, indicates that while the mail server accepted the connection, it couldn't locate the specified recipient in its directory. This article will guide you through a systematic troubleshooting process, covering common pitfalls and less obvious culprits.

Understanding the 550 5.1.10 Error in Context

When you receive a 550 5.1.10 error from an Office 365 recipient, it means that the Microsoft Exchange Online servers believe the email address you're trying to send to does not exist within their authoritative domain. This isn't just a generic "undeliverable" message; it specifically points to an issue with how Office 365 perceives the recipient.

Common scenarios where this error crops up after an O365 migration include: * Incomplete or incorrect DNS configuration. * User provisioning issues in Azure AD or Exchange Online. * Synchronization problems in hybrid environments. * Mail flow misconfigurations.

While the error message itself is concise, the underlying causes can be complex, especially in hybrid deployments where on-premises Active Directory and Exchange still play a role.

Initial Checks: The Low-Hanging Fruit

Before diving into complex diagnostics, let's cover the basics. Many 550 5.1.10 errors are resolved with these fundamental checks.

DNS MX Records Verification

The most common cause of post-migration mail flow issues is incorrect DNS. Your domain's Mail Exchanger (MX) records must point to Office 365. If they still point to your old on-premises server or an incorrect O365 endpoint, mail won't reach the correct destination.

To verify your MX records, open a terminal and use dig (on Linux/macOS) or nslookup (on Windows):

dig MX yourdomain.com

The output should show MX records pointing to Microsoft's servers, typically looking something like yourdomain-com.mail.protection.outlook.com.

Pitfall: DNS caching. Even if you've updated your MX records, it can take time for changes to propagate globally due to TTL (Time To Live) settings. If you've recently made changes, wait an appropriate period (e.g., 24-48 hours, or whatever your old TTL was set to) before concluding it's not a DNS issue. Also, ensure you check from multiple locations or using public DNS resolvers to rule out local caching.

User Provisioning and Licensing

It might sound obvious, but is the recipient actually created and licensed in Office 365? A user might have been missed during the migration, or their account might be in an inconsistent state.

  1. Check in Microsoft 365 Admin Center: Navigate to Users > Active users and search for the recipient.
  2. Verify Exchange Online Mailbox: Ensure the user has an Exchange Online license assigned and that a mailbox has been provisioned. If the user exists but has no mailbox, they cannot receive email.
  3. Use PowerShell: For a more granular check, connect to Exchange Online PowerShell and run: powershell Get-Mailbox -Identity "user@yourdomain.com" | Select-Object DisplayName, PrimarySmtpAddress, RecipientTypeDetails, IsSoftDeleted, WhenMailboxCreated, ExchangeUserAccountControl This command provides details about the mailbox's existence and state. Pay close attention to RecipientTypeDetails (should be UserMailbox for a standard user) and IsSoftDeleted.

Deep Dive: Mail Flow and Directory Synchronization

If the initial checks don't resolve the issue, you're likely dealing with more intricate problems, especially common in hybrid Exchange environments.

Hybrid Mail Flow and Address Management

In a hybrid deployment, mail flow can be complex. You have on-premises Exchange servers potentially routing mail, and Azure AD Connect synchronizing user objects.

Crucially, for migrated mailboxes, the on-premises Active Directory user object must be correctly configured after the migration. Specifically, the TargetAddress attribute (also known as RemoteRoutingAddress) is key.

  • Migrated Mailboxes: After a mailbox is migrated from on-premises Exchange to Exchange Online, the TargetAddress attribute on the on-premises Active Directory user object should be cleared. If it's still present and pointing to the old on-premises server, mail might loop or be misdirected.
  • Mailboxes Still On-Prem (in hybrid): If the user is not migrated and their mailbox remains on-premises, their RemoteRoutingAddress attribute (which translates to TargetAddress in AD) should point to their Exchange Online address (e.g., user@yourdomain.mail.onmicrosoft.com) to facilitate mail routing from O365 back to on-prem.

You can inspect these attributes using PowerShell against your on-premises Active Directory:

Get-ADUser -Identity "username" -Properties TargetAddress | Select-Object Name, UserPrincipalName, TargetAddress

Or, if you have the Exchange Management Shell loaded:

Get-RemoteMailbox -Identity "user@yourdomain.com" | Format-List DisplayName, PrimarySmtpAddress, RemoteRoutingAddress

Pitfall: Azure AD Connect synchronization issues. Even if you correct the TargetAddress on-premises, if Azure AD Connect isn't syncing properly, the changes won't reflect in Exchange Online.

Azure AD Connect Synchronization

Azure AD Connect is the bridge between your on-premises Active Directory and Azure AD. If user objects aren't syncing correctly, Exchange Online won't see the recipient.

  1. Check Synchronization Service Manager: On your Azure AD Connect server, open the Synchronization Service Manager. Look for any errors related to the user object in question. Common issues include attribute conflicts or