5.1.10 "RESOLVER.ADR.RecipientNotFound" means Exchange Online accepted the message for a domain it hosts and then could not find the recipient in the directory. The address does not exist as a mailbox, alias, contact or group in that organization.
Most common causes
- The recipient address is misspelled or no longer exists
- An alias or proxy address was removed
- Directory synchronization has not produced the expected address
- A migration or domain transition left the sender using an obsolete recipient identity
What to verify next
- Verify the exact SMTP address from the NDR
- Confirm whether the recipient or alias exists in the destination directory
- Check recent migration, alias and directory-sync changes
- Remove obsolete cached recipient addresses from the sending workflow
Where the lookup failed
Unlike edge blocking (5.4.1), this rejection happens after acceptance when the message is being resolved to a mailbox. The domain is one Exchange Online is authoritative for, and the local part matched nothing.
Causes are prosaic: a typo, an employee who left and whose mailbox was deleted, an alias that was removed, a group that was retired, or a migration where the mailbox exists elsewhere but its cloud object was never created or synchronized.
Confirm on the recipient side
If you are the recipient organization, search the directory for the exact address including proxy addresses. Confirm directory synchronization completed if the mailbox is on-premises, and check whether the domain should be internal relay rather than authoritative so unknown addresses route onward.
If you are the sender, verify the address with the recipient by another channel and remove obsolete addresses from any system that still uses them.
- The domain is hosted by Exchange Online; the local part is unknown.
- Proxy addresses and aliases count; check them all.
- Sync gaps after migration are a frequent cause.
Fix and retest
Create or synchronize the recipient object, restore a deleted mailbox if it is within the retention window, or correct the address at the source. Directory changes take effect after the next synchronization cycle.
Resend once the object exists. A repeated 5.1.10 means the directory the resolver consults still lacks the recipient.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- The sender has no visibility into the recipient directory.
- Restored mailboxes may take time to reappear in address resolution.
Common questions
Difference from 5.4.1?
5.4.1 rejects at the edge before acceptance; 5.1.10 rejects during resolution after acceptance. Both mean the recipient was not found.
The user exists in Active Directory.
Then the cloud object is missing or not mail-enabled. Check directory synchronization and the mailbox’s proxy addresses.
Can auto-reply or forwarding cause this?
Yes, if a forward targets an address that no longer exists. Check forwarding on any mailbox involved.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft Exchange Online NDR reference.