A user sends a message to a colleague, a shared mailbox or someone in a domain you share with another system, and it bounces with 5.1.10. Exchange Online looked the address up and found nothing. The cause ranges from a stale Auto-Complete entry to a domain set up the wrong way for hybrid routing. In this post I'll show how to tell which one you have, fix it and prove the fix with message trace.
Errors this guide fixes
550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookupNDR / message trace5.1.10 Recipient not foundNDR550 5.5.0 Requested action not taken: mailbox unavailableNDR (Outlook.com and Hotmail recipients)
Symptoms#
The sender gets a non-delivery report (NDR) saying the recipient wasn't found. In Diagnostic information for administrators, the code reads:
550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup- Microsoft's NDR table summarizes it as
5.1.10 Recipient not found: the SMTP address lookup didn't find the recipient's address. - For recipients at
@outlook.comor@hotmail.com, the equivalent bounce is550 5.5.0 Requested action not taken: mailbox unavailable. - Message trace shows the message as Failed, with the same text in the details.
- Sometimes the address in the NDR isn't the one the sender typed. That points to a forwarding rule on the recipient's side.
Why it happens#
Exchange Online resolves every recipient by SMTP address. Whether a failed lookup bounces depends on the accepted domain type. When the domain is Authoritative, a missing recipient stops delivery and produces this NDR. That's why Microsoft notes that on-premises users must exist in Exchange Online as mail users or mail contacts. When it's Internal relay, Exchange Online passes unknown recipients on through a connector instead. The usual causes:
| Cause | Clue |
|---|---|
| Typo, a removed alias, or a leaver whose mailbox was deleted | Get-Recipient returns nothing |
| Stale Auto-Complete entry in Outlook | Works when the address is typed in full |
| The recipient's forwarding points to a bad address | The NDR address differs from the sent address |
| Mailbox without a license | The user exists, but no Exchange Online license is assigned |
| Domain shared with another mail system but set to Authoritative | Only recipients hosted elsewhere fail |
| Hybrid object missing on one side | Not synced to Exchange Online, or a cloud-only mailbox with no on-premises object |
One more possibility: the bounce is backscatter. A spammer forged your user's address as the sender, and the NDR came back to them for a message they never sent. Microsoft says you can ignore those NDRs, and that publishing SPF helps prevent the spoofing.
How to fix it#
- Confirm the address exists. Compare the NDR address with the copy in Sent Items, then look it up, including mailboxes deleted recently:
PowerShell
Connect-ExchangeOnline Get-Recipient -Identity megan@contoso.com | Format-List Name, RecipientTypeDetails, PrimarySmtpAddress, EmailAddresses Get-Mailbox -SoftDeletedMailbox -Identity megan@contoso.comIf the user exists, check in the Microsoft 365 admin center under Users › Active users that a license with Exchange Online is assigned.
- Clear stale Auto-Complete entries. The sender deletes the suggestion from the To line and types the full address. After migrations, old cached entries can also produce
IMCEAEXbounces, which need an X500 address instead (X500 guide). - Fix broken forwarding on the recipient: mailbox forwarding, Inbox rules and mail flow rules that redirect.
PowerShell
Get-Mailbox -Identity megan@contoso.com | Format-List ForwardingAddress, ForwardingSmtpAddress Get-InboxRule -Mailbox megan@contoso.com | Where-Object { $_.ForwardTo -or $_.RedirectTo } | Format-List Name, ForwardTo, RedirectTo Get-TransportRule | Where-Object { $_.RedirectMessageTo } | Format-Table Name, State, RedirectMessageTo - Check the accepted domain type. If some recipients in the domain live on another system (on-premises Exchange that isn't synced, or another provider during a migration), the domain should be Internal relay. First create an outbound connector that routes the domain to that system. Microsoft warns that switching without one breaks mail flow to those recipients. In the Exchange admin center, go to Mail flow › Accepted domains, or use PowerShell:
PowerShell
Get-AcceptedDomain | Format-Table DomainName, DomainType Set-AcceptedDomain -Identity contoso.com -DomainType InternalRelayChanging the type has side effects, especially in hybrid, so do it only when the domain is genuinely shared. The 5.4.1 guide explains how the same setting affects Directory-Based Edge Blocking.
- Close hybrid sync gaps. If the recipient is on-premises, make sure it's in scope for Microsoft Entra Connect Sync and run a delta cycle on the sync server. Then confirm it exists in Exchange Online as a mail user:
PowerShell
# On the Microsoft Entra Connect Sync server Start-ADSyncSyncCycle -PolicyType Delta # In Exchange Online PowerShell Get-MailUser -Identity megan@contoso.com | Format-List ExternalEmailAddress, EmailAddressesMicrosoft also documents the reverse case. A mailbox created directly in Microsoft 365 has no object on-premises, so lookups for its address fail there. The fix is to create a remote mailbox on-premises with the same name, alias and UPN, set its
ExchangeGuidto the cloud mailbox's value withSet-RemoteMailboxand let sync match them. For routing from on-premises to the cloud, see remote mailbox management.
Verify the fix#
Ask the sender to send the message again with the address typed in full rather than picked from Auto-Complete, then trace it:
Get-MessageTraceV2 -RecipientAddress megan@contoso.com -StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date) |
Format-Table Received, SenderAddress, Subject, Status- Delivered: fixed. For a recipient hosted elsewhere, this means Exchange Online handed the message to the next system through your connector.
- Failed with 5.1.10 again: the address still doesn't resolve. Re-run
Get-Recipient, and in hybrid wait for the next sync cycle. - Failed with another code: the lookup now works and the failure is elsewhere (reading trace results).
Tell it apart from similar NDRs#
550 5.4.1 Recipient address rejected: Access denied: external mail to an unknown address rejected at the edge by Directory-Based Edge Blocking.5.1.1 Bad destination mailbox address: the destination system, often a non-Microsoft server named in the NDR, says the user doesn't exist.550 5.1.11 RESOLVER.ADR.ExRecipNotFoundor anIMCEAEXaddress: a legacy Exchange DN from an old cache entry, fixed with an X500 proxy address.
Prevent it next time#
- Before you change MX records or accepted domain types, make sure every recipient exists in Exchange Online as a mailbox, mail user or contact.
- When a user leaves, convert the mailbox to a shared mailbox or keep the address as an alias somewhere for a while.
- After migrations, tell users to clear Auto-Complete entries for moved colleagues, and add X500 addresses where needed.
