550 5.1.1 and 550 5.1.10: Exchange Online cannot find the recipient

Fix it now

550 5.1.1 is “Bad destination mailbox address” and 550 5.1.10 is “Recipient not found”: Exchange Online looked the address up and found nothing it will deliver to. Sometimes a typo. More often a leaver whose licence was pulled, taking the mailbox with it.

Get-Recipient -Identity leaver@contoso.com -ErrorAction SilentlyContinue
Get-Recipient -Identity leaver@contoso.com | Select Name,RecipientTypeDetails,EmailAddresses

1. Copy the exact address out of the bounce. A single wrong character is still the commonest cause and the easiest to dismiss.
2. If Get-Recipient returns nothing and the person has left, decide what the address should do now: a shared mailbox, an extra address on a colleague, or a clean retirement.
3. To keep a leaver’s mailbox as a shared mailbox, the account must still hold a licence. Restore the account if it was deleted, licence it, wait for the mailbox to be re-created, then convert it – and leave the account in place afterwards.
4. If only one internal sender fails, have them delete the suggestion from Outlook’s AutoComplete list and pick the recipient fresh from the address book.
5. Read the diagnostic line. RESOLVER.ADR.ExRecipNotFound and 5.1.20 are different faults with different fixes – see the table below.

Deleting the user account after converting to a shared mailbox breaks the shared mailbox. The account anchors it.

If mail is being delivered again you can stop here. If not, the next section covers the several different failures that all arrive as 550.

Why it happens

When mail arrives for one of your domains, Exchange Online resolves the address against the directory. If the domain is authoritative – your tenant is the final destination for it – an address that does not exist is rejected immediately rather than forwarded anywhere. That is deliberate: it stops your tenant accepting and then bouncing mail for addresses that were never real, which is exactly what spammers exploit.

Microsoft’s own text for the two headline codes is worth having in front of you. 550 5.1.1 is “Bad destination mailbox address”, with four listed conditions: the sender mistyped it, the address does not exist in the destination system, the mailbox was moved and the sender’s Outlook cache did not update, or the recipient has an invalid legacy domain name. 550 5.1.10 is “Recipient not found”: SMTP address lookup did not find the address.

The leaver case generates most of these tickets. Remove a user’s licence and the mailbox enters a grace period, then is disabled and removed. Delete the account and it sits recoverable for around thirty days, then it is gone. Neither path leaves anything behind that will accept mail, so customers writing to that address start bouncing, usually without telling you.

Two of the codes here are not recipient-resolution failures at all, and reading them as such wastes an afternoon. 550 5.1.20 is “Multiple From addresses are not allowed without Sender address” – a message-format rejection to be fixed in the sending application. 550 5.7.504 is “Recipient address rejected: Access denied”, an authorisation refusal most usefully read as a delivery restriction on the recipient or group.

Full reference

Reading the bounce before you change anything

Keeping a leaver’s address alive, properly

1. Restore the user account from the admin centre if it has been deleted.
2. Assign a Microsoft 365 licence and reset the password.
3. Wait for the mailbox to be re-created – Microsoft allows up to 24 hours.
4. Convert to a shared mailbox from the Mail tab, or with Set-Mailbox -Type Shared.
5. Remove the licence from the account once the conversion has completed.
6. Add the people who should read it as members of the shared mailbox.
7. Leave the user account in place. Deleting it breaks the shared mailbox that depends on it.

Existing mail, calendar items and inbox rules are retained through the conversion. Microsoft also notes that the original username and password keep working against the shared mailbox unless you reset the password, which is a good reason to reset it as part of offboarding.

When it is a whole domain rather than one address

• List the accepted domains on the tenant and check each one’s type against the way mail is meant to flow.
• An authoritative domain rejects unknown recipients outright. A domain that relays on to another system must be configured as such, not left authoritative.
• In hybrid, confirm the recipients exist in the directory the cloud can see, not only on-premises.
• Retest from outside the organisation after any change. Internal resolution can succeed while external delivery still fails.

Checks that save the most time

• Get-Recipient against the exact string from the bounce, not against what you think the address is.
• Whether the failure is external-only, internal-only, or both. Internal-only points at a client cache or an X.500 address; external-only points at accepted domains or DNS.
• Whether the recipient is a group. Groups have their own delivery restrictions, and “require that all senders are authenticated” is the commonest reason an external sender gets 5.7.504.
• Message trace in the Exchange admin centre for the failed message, which shows the refusal from the service’s side rather than the sender’s.

Every code this article covers

Confirm the fix worked

1. Get-Recipient against the address now returns the object you expect.
2. A test message from an external account is delivered.
3. The internal sender who was failing succeeds after clearing their AutoComplete entry.
4. If you added an X500 address, a reply to an old message from that recipient now goes through.
5. The user account behind a converted shared mailbox is still present and unlicensed, not deleted.

Questions people ask about this