I had some issues with creating a new user in our domain. The exchange mailbox of his was corrupted and I had to remove and recreated the profile.

It's working fine now, except the user cannot receive internal emails, the sender always gets the error message

#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

The email address for this and any other of our users goes like this: John.Doe@myDomain.com . myDomain is an external mail provider, but the same address is used for internal mails.

Sending mails to John.Smith@myDomain.local works on the other hand, but this would be confusing to use, just for this one domain user.

I've checked the other topics with the #550 error, but none of the solutions there worked for me (no address book isue/NK2 file issue)

I'm a bit at a loss on where the mail name gets resolved for internal routing, or whatever causes the issue.

**I've noticed that the faulty user has 2 entrys in the attribute "ProxyAddresses", one for the external address, one for the local. Had to add the local one via exchange manager, because it was missing. But on all clients, and the global address book, the new entry is still missing. I forced and globaladdresslist update, but it's still not showing, might this be the issue? **


It actually is related to the autocomplete cache (indirectly) for those internal users trying to send email to this user. You'll need to do one of two things:

  1. Have everyone delete the relevant entry from their autocomplete cache.


  1. Create an X500 proxy address for the old LegacyExchangeDN attribute for the user.

Have a read here:


The article references Office 365 but is relevant for every version of Exchange.

  • I tried 1) on my end, but I still got the same error message. I deleted the auto complete, typed the recipient's address by hand and requested a fresh copy from the address book. I'll report back after I tested 2)
    – Yama
    Mar 10 '17 at 11:30
  • Does 2) takes some time to take effect? I altered the entry according to your article, but I still get the same error. One thing I noticed, every other user's entry just ends with ....cn=username, but the faulty user has a ...cn=username90b0a522 , some hex string attached at the end. I tried several combinations with or without this string, but none worked.
    – Yama
    Mar 10 '17 at 12:55
  • I expanded my OP, maybe you can comment on the last paragraph
    – Yama
    Mar 10 '17 at 13:20
  • As I wrote in your other question - when it comes to address issues, the first test is always through OWA as that is live. If it works in OWA then it is just the OAB that needs updating. That will happen automatically within 48 hours.
    – Sembee
    Mar 10 '17 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.