What the bounce says
Exact wording as it appears in the rejection or NDR. Placeholders such as x.x.x.x and example.com stand for your own address and domain.
550 5.1.1 RESOLVER.ADR.RecipNotFound; not found 550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found
RESOLVER.ADR.RecipNotFound is the most frequent Exchange non-delivery report. Exchange resolved the domain, accepted the message, then could not match the address to any mailbox, contact, group or alias it hosts.
Most common causes
- The address is mistyped
- The mailbox was deleted or the user left
- An alias was removed or never existed
- A cached or stale address is being used by the sending client or application
What to verify next
- Verify the address with the recipient by another channel
- If you host the recipient, confirm the object exists and is mail-enabled
- Clear stale autocomplete entries in Outlook that resolve to old addresses
- For migrated users, confirm the cloud object and proxy addresses are synchronized
The four usual causes
A typo: one wrong character in the local part. A departed user: the mailbox was deleted and the address released. A removed alias: the person still exists but that particular proxy address was taken away. A stale cache: Outlook autocomplete or an application remembers an old address or, worse, an old internal identifier that no longer resolves.
The autocomplete case deserves attention because the visible address looks right while the underlying entry points at a deleted object. Deleting the autocomplete entry and typing the address fresh resolves it.
- Verify the address independently.
- Clear autocomplete for the recipient in Outlook.
- For your own domain, check proxy addresses on the object.
If you host the recipient
Search the directory for the exact address including all proxy addresses. Confirm directory synchronization is healthy if the object lives on-premises. If the user was recently migrated, verify the cloud object carries the same addresses as the on-premises one.
A domain configured as authoritative rejects unknown recipients; if some addresses live on another system, the domain type should be internal relay so unknown recipients route onward.
Distinguish from edge blocking
5.4.1 "Recipient address rejected: Access denied" is the same underlying fact — recipient unknown — but rejected at the connection stage by directory-based edge blocking. 5.1.1 occurs after acceptance during resolution. The fix is the same; the timing differs.
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 can take time to reappear in resolution.
Common questions
The address worked last month.
The mailbox or alias was probably removed since. Confirm with the organization.
Why does Outlook say the name is resolved?
Autocomplete resolves against a cached entry. Delete the entry and type the address again.
Is 5.1.1 ever temporary?
Rarely — during directory synchronization gaps after a migration. Otherwise treat it as permanent.
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: Fix error codes 5.1.1 through 5.1.20.