Is 550 5.1.10 the same as 550 5.1.1 User Unknown?

They mean the same thing — the recipient address doesn't exist where the mail landed — but they come from different code paths, and Microsoft uses the diagnostic text to tell them apart. 550 5.1.1 with RESOLVER.ADR.RecipNotFound is the classic address-not-found bounce; any mail server on the internet can emit a 5.1.1. 550 5.1.10 with RESOLVER.ADR.RecipientNotFound is Exchange Online's own flavor: its categorizer tried to resolve the address against the directory and found no object for it. In practice 5.1.10 shows up heavily in Microsoft 365 and hybrid environments, where a cloud mailbox exists but has no on-premises object to route to, or the directory holds a stale address. Read the diagnostic, not just the number: both send you to check the address and where its mail actually routes, but 5.1.10 also points at directory synchronization.

The mailbox definitely exists in Microsoft 365, so why does mail bounce 5.1.10?

Because the bounce is about what the directory could resolve, not what exists in the admin center. The most common cause in a hybrid setup is a user created directly in the cloud with no matching on-premises object: on-premises Exchange has nothing to route to, so its categorizer returns 5.1.10 even though the mailbox is real in Microsoft 365. The fix is to create the on-premises object — a mail-enabled user or remote mailbox with New-RemoteMailbox — and let directory synchronization propagate it. The other frequent cause is stale directory data: an old proxyAddresses entry, a forwarding rule pointing at an address that was deleted, or a global address list that hasn't updated after a change. The mailbox is fine; the address the sender used, or the address a forward redirected to, isn't one the directory can resolve.

Can SPF, DKIM, or DMARC cause a 550 5.1.10?

No. Authentication and policy failures come back in the 5.7.x range — 5.7.1 for a policy or SPF block, 5.7.26 for unauthenticated mail, 5.7.509 for a DMARC reject. 5.1.10 is decided earlier, when the categorizer resolves the recipient address against the directory, before it weighs who sent the message. You can have flawless SPF, a valid DKIM signature, and a passing DMARC record and still get 5.1.10 the instant the address doesn't resolve to a directory object. Fix the recipient and the directory, not your sending authentication.

550 5.1.10 Recipient Not Found (Exchange Online)

Problem

Mail to a Microsoft 365 or Exchange address bounces with a permanent non-delivery report reading 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient <address> not found by SMTP address lookup. The message never reached a mailbox. Often the recipient swears the mailbox exists — and in the admin center, it does. The bounce is telling you something more specific than “no such user”: Exchange’s categorizer tried to resolve that address against its directory and came back with nothing.

This is a routing-and-directory failure, not an authentication one. Chasing SPF or DKIM here wastes the afternoon.

Symptoms

The NDR contains 550 5.1.10 with RESOLVER.ADR.RecipientNotFound and the phrase not found by SMTP address lookup.
The bounce names the exact recipient address it couldn’t resolve.
Other people at the same domain receive mail fine; only one address (or addresses created a certain way) bounces.
The recipient’s mailbox is visible and working in the Microsoft 365 admin center, yet mail from certain senders still bounces.
In a hybrid org, mail from on-premises senders to a cloud user bounces, or a moderation/acceptance message fails, while cloud-to-cloud mail works.

What this error actually means

Read the report in two halves. The 550 is a permanent SMTP rejection — retrying sends the same address into the same wall. The 5.1.10 sits in the 5.1.x addressing class: the fault is with the destination address itself, not with reputation, content, or authentication. (The 5.1.x addressing class comes from RFC 3463; 5.1.10 is Microsoft’s specific detail code within it, which is why the human-readable RESOLVER.ADR.RecipientNotFound matters more than the number.)

RESOLVER.ADR.RecipientNotFound is the part that tells you what happened. Exchange’s categorizer — the component that decides where a message goes — tried to resolve the recipient address against the directory (the on-premises Active Directory in a hybrid org, or the cloud directory in Exchange Online) and found no object matching it. No object means no route, so it refuses the message permanently.

The trap is the word “exists.” Existing in the admin center is not the same as being resolvable by the categorizer that handled this particular message. In a hybrid deployment those can be two different directories. A mailbox can be perfectly real in the cloud and still be invisible to an on-premises categorizer that has no object for it — and that gap is exactly what 5.1.10 reports.

Top 3 causes

The address genuinely doesn’t resolve — A typo, a deleted or renamed recipient, an offboarded user whose address was reclaimed, or a stale entry on a distribution list. The categorizer looks, finds no object, refuses. This is 5.1.10 doing its job.
A cloud mailbox with no on-premises object (hybrid) — The most common “it exists but bounces” case. A user was created directly in Microsoft 365, but on-premises Exchange has no corresponding object to route to. On-premises senders (and moderation/acceptance flows) hit 5.1.10 because their categorizer can’t resolve the cloud recipient. The fix is a remote mailbox or mail-enabled user on-premises (New-RemoteMailbox) plus directory synchronization.
Stale directory data or a bad forward — An old proxyAddresses value that never updated after a rename or migration, a global address list that hasn’t refreshed, or a forwarding rule (on the sender’s side or the recipient’s) that redirects to an address which no longer exists. The visible mailbox is fine; the address actually being resolved isn’t.

Diagnose with DechoNet

Email Check on the recipient domain shows where its mail actually routes and which provider hosts it. If the MX points at Microsoft (mail.protection.outlook.com) you know whose categorizer issued the bounce and that this is a directory question, not a delivery-path one.
Email Header Analyzer reads the bounce itself: confirm the code is 5.1.10 with RESOLVER.ADR.RecipientNotFound — not 5.1.1 (generic user unknown), not 5.4.1 (directory-based edge block), not 5.7.x (authentication/policy). The exact string decides which fix applies and whether directory sync is in play.
DNS Check confirms the domain’s MX and shows recent changes. A leftover MX from a migration, or a domain configured as authoritative when it should be an internal relay, is a classic reason a valid recipient can’t be resolved by the server that answered.

Resolution checklist

Confirm the code is 5.1.10 / RESOLVER.ADR.RecipientNotFound, not 5.1.1, 5.4.1, or 5.7.x. The exact string tells you whether to look at the address, the directory, or authentication.
Re-check the recipient address character by character. Copy-paste it from a known-good source rather than retyping — one wrong letter is the single most common cause.
If the org is hybrid, confirm the recipient has an on-premises object (remote mailbox or mail-enabled user). If it was created cloud-only, create the on-premises object and force directory synchronization.
Check for stale proxyAddresses, an out-of-date global address list, or a forwarding rule pointing at a deleted address — on both the sender’s and the recipient’s side.
If you own the recipient domain, verify the MX points at the provider that actually hosts the mailbox and that the domain’s accepted-domain type (authoritative vs internal relay) matches your topology.
Remove hard-bounced addresses from your sending list. Repeatedly hammering a 5.1.10 address is a spammer signal and erodes your sender reputation.

When to escalate

This bounce is generated by the recipient’s Exchange organization, so the fix usually belongs to their administrator. Forward them the exact NDR — the 5.1.10 code, the RESOLVER.ADR.RecipientNotFound string, and the address it couldn’t resolve tell them precisely which object or sync is missing.
If you administer a hybrid org and a cloud mailbox still bounces 5.1.10 after you’ve created the on-premises object and synced, open a message trace and check the categorizer’s resolution — a confirmed object that still won’t resolve points at a synchronization or accepted-domain fault, not the mailbox.
If the address, the directory, and the MX are all correct and a valid recipient still bounces, escalate to your mail provider with the trace. A recipient the front door can see but the categorizer can’t resolve is a routing fault on their side.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.