550 5.1.10 RecipientNotFound: the Microsoft 365 user unknown
550 5.1.10 means Microsoft 365 searched its directory for the recipient address and found nothing. Check the address, forwards, license, accepted domain and MX.
On this page(9 sections)
- What does 550 5.1.10 RESOLVER.ADR.RecipientNotFound mean?
- How is 5.1.10 different from a plain 5.1.1?
- What are the causes, in the order to check them?
- What should the sender check first?
- Could the bounce be backscatter?
- What should the receiving admin check?
- What should you do with the address afterward?
- What can you tell the person you were emailing?
- Bottom line
You send a message to someone at a company that runs on Microsoft 365 and get back "550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup". It reads like a vague directory error, but it is Microsoft's version of "user unknown": the service looked for that exact address and found no mailbox, contact or group that owns it.
This guide explains what the code says, the causes in the order you should check them, and what to do whether you are the sender or the admin of the receiving domain.
What does 550 5.1.10 RESOLVER.ADR.RecipientNotFound mean?
550 5.1.10 is a permanent rejection from Exchange Online saying its address lookup did not find the recipient. The 550 is the SMTP reply from RFC 5321, and 5.1.10 is Microsoft's own subcode under the "bad destination mailbox address" family (5.1.x) from RFC 3463. The text after it, "RESOLVER.ADR.RecipientNotFound", names the stage: the recipient resolver, which maps an address to a directory object.
Microsoft documents it in its NDR reference for Exchange Online and in a dedicated fix guide for 550 5.1.10. The same reference says a 5.5.0 "mailbox unavailable" bounce for a hotmail.com or outlook.com recipient is similar. For the wider code family, see SMTP enhanced status codes.
How is 5.1.10 different from a plain 5.1.1?
Both mean the address was not found. 5.1.1 is the generic code every mail server can use, and the one most providers send. 5.1.10 is the Exchange Online flavor, so seeing it tells you the receiving side is Microsoft 365 and the rejection came from its directory lookup, not from a spam or reputation filter.
That matters for what you do next. A reputation block would use a 5.7.x code. A 5.1.10 is about the address. The troubleshooting for the generic code is in why a bounce says 5.1.1 for an address that used to work, and most of it applies here too.
What are the causes, in the order to check them?
| Order | Cause | Who can fix it | Quick test |
|---|---|---|---|
| 1 | Typo or stale autocomplete entry | Sender | The address in the bounce differs from what the person gave you |
| 2 | Mailbox never existed, was deleted or renamed | Receiving admin | The user is missing or has a different primary address in the admin center |
| 3 | User exists but has no email license | Receiving admin | The user has no Exchange Online license assigned |
| 4 | A forward or redirect rule points at a dead address | Recipient or admin | The address in the bounce is not the one you typed |
| 5 | Accepted domain set to Authoritative while some users live elsewhere | Receiving admin | Hybrid setup, the missing user is on-premises |
| 6 | Directory sync has not caught up | Receiving admin | A new on-premises user is missing in Microsoft 365 |
| 7 | Wrong or duplicate MX records for the domain | Domain owner | More than one MX record, or one that points at an old host |
Rows 1 and 4 are by far the most common in practice for a sender. Rows 2 and 3 are what the admin finds most often. Rows 5 to 7 are mostly seen in migrations and hybrid setups.
What should the sender check first?
Compare the address in the bounce with the one you meant to type. Microsoft's own fix guide starts there: resend the message to a freshly typed address, and remove the recipient from the autocomplete list first, because a bad or outdated cached entry can cause exactly this error.
If the two addresses do not match, a forward is involved. The recipient may have a rule that forwards your mail to another destination, and that destination bounced. Ask the person by phone or chat whether they forward mail, and have them correct or remove the rule. The forwarding rules post explains how these chains fail. If you need to see which server generated the bounce, tracing delivery with Received headers shows how to read it.
Could the bounce be backscatter?
Yes. If you never sent a message to that address, the bounce is probably backscatter: a spammer forged your address in the From line, the message went to a non-existent recipient, and the rejection came back to you. Microsoft says this kind of bounce can be ignored or deleted, and that it does not mean your account was compromised. If you receive a lot of it, check your devices for malware and make sure your domain has SPF, DKIM and DMARC so forged mail is easier to reject.
What should the receiving admin check?
Work through these in order, and ask the sender to retry after each change.
- Confirm the user exists and the address matches. In the Microsoft 365 admin center, open Active users and search for the person. The primary or alias address must be exactly what the sender used.
- Confirm an email license is assigned for users whose mailbox is hosted in Exchange Online. A user with no license has no mailbox to receive into.
- Check forwarding. Look at account forwarding on the user, any inbox rules, and organization-wide mail flow rules that redirect messages.
- Check the accepted domain type under Mail flow, Accepted domains. Microsoft describes the two behaviors this way: with Authoritative, the service looks for the recipient in the Exchange Online organization and stops with this bounce if it is not found. With Internal Relay, it relays unknown recipients to your on-premises Exchange organization, which needs a matching connector. Microsoft warns that changing the type can cause other problems, so change it only if you really run a hybrid setup.
- Run a directory sync if the person lives on-premises. On the server that runs Microsoft Entra Connect Sync,
Start-ADSyncSyncCycle -PolicyType Deltastarts a delta cycle, then recheck that the address exists in Microsoft 365. - Check the MX record. There should be one MX record for a domain enrolled in Exchange Online, normally pointing at the
mail.protection.outlook.comormx.microsofthost Microsoft gives you. DNS changes can take a few hours to propagate. See MX records explained for how to read them.
If the bounce came with a 5.4.1 code and "Access denied" text instead, that is a different filter; see Exchange Online 550 5.4.1 recipient address rejected.
What should you do with the address afterward?
Treat it as a hard bounce. Do not keep retrying, and take the address off mailing lists until someone confirms it. Repeated sends to non-existent mailboxes hurt your reputation, which is why hard bounces should end sending to that address.
In Koltrix, a permanent 5xx rejection adds the address to the workspace suppression list so that later sends skip it. See the deliverability docs for where the list lives. Before you remove an address from it, confirm with the person that the mailbox now exists.
What can you tell the person you were emailing?
Keep it short and give them one action:
Our message to [email protected] came back with "recipient not found". Your Microsoft 365 directory has no mailbox with that address. Could you confirm the exact address, and check that you have no forwarding rule pointing at an address that no longer exists?
Bottom line
550 5.1.10 RESOLVER.ADR.RecipientNotFound means Microsoft 365 looked up the address and found no recipient. As a sender, retype the address, clear the autocomplete entry, and compare the bounce address with yours to catch a dead forward. As the admin, confirm the user exists, has an email license, has no broken forwarding, sits in the right accepted-domain mode and has one correct MX record. If you never sent the message, it is backscatter and you can delete it.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
