Delivery Failed From Office 365 Mailbox To On-Premises Exchange Mailbox


In an Exchange 2010 SP3 Hybrid deployment with Office 365, a client noted that they were unable to send email from their Office 365 mailbox to an on-premises mailboxes.  The user in Office 365 received an undeliverable message stating that Delivery has failed to these recipients or groups and the email address wasn’t found at the destination domain.    That was not the case as there certainly was a mailbox on-premises with that email address assigned to it, and it was quite happily sending and receiving email to lots of other people.

The undeliverable message will help us troubleshoot the issue. 

Update 26-8-2015 – added the new enhanced NDR in addition to the older one.

This the new enhanced NDR:

image

And the older one, which has less detail. 

Remote Server returned '550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address

The relevant sections were:

DSN 5.1.10 Errors in Exchange Online and Office 365

Remote Server returned 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup.

As far as the Office 365 tenant was concerned, the other mailbox did not exist.  Why?

 

The World As The Tenant Sees It

Office 365 did not want to route the email to this mailbox.  Was the domain for the mailbox present?  The Tailspintoys.ca domain was correctly added and verified in the tenant.  We can see this below:

Domain Status In Azure Active Directory

And for the Exchange Online portion, how does Exchange see the Tailspintoys.ca domain?

Domain Status In Exchange Online

That all looks good.

 

Since the domain type is set as Authoritative this means that Exchange believes it knows all of the recipients in the given domain.  For more details on Authoritative and the other domain types please see TechNet.

Exchange Online is saying it has no knowledge about the on-premises mailbox.

What normally replicates the on-premises directory to Office 365?  AAD Sync, or the previous DirSync tool.

This begs the question - How healthy was DirSync?

 

Directory Sync (Or Rather Lack Of)

In this case the customer had changed the password for the service account that was used to authenticate to Windows Azure Active Directory (WAAD).  Since they never then updated the Directory Sync tool, no more updates were flowing between on-premises AD and WAAD.  because of this Exchange Online had no idea that there was a newly created mailbox on-premises.  After providing updated logon data, Directory Sync picked up where it left off, and once the changes had been pushed to Office 365 mail flow was working as expected.

In addition to changing the service account’s password, it is also possible to also run into the issue where AAD Sync does not automatically execute due to the option selected at installation time.

 

As a parting note, I am seeing multiple instances where AAD Sync or DirSync is installed and then never monitored.  Directory Synchronisation is a critical part of your Office 365 solution, give it the love it deserves!

For additional issues related to Directory Synchronisation, review the Managing Directory Synchronization  - Notes From The Field post.

Cheers,

Rhoderick

Comments (6)

  1. turbomcp says:

    long live dirsync
    I mean aadsync
    I mean adconnect
    🙂

  2. Scot says:

    Hello Rhoderick. Thanks for this post. Over the past week, we have set up an Exchange 2010/Office 365 Hybrid Deployment. We bought our Exchange Online licenses through Dell’s cloudstore service, which included technical support for the Hybrid setup. They have been helpful, but we have run into the problem exactly as described in this post. Our Azure AD Connect Sync is working fine, and I believe the root issue is that we are not Syncing our entire on-premise AD to the Azure AD. We are filtering based on an OU. We have many accounts, that we want to leave in the on-premise Exchange server for the time being. Is there not a way to tell Exchange Online that when it finds an address that is in the same domain, but not synced to Azure AD to use the connector that should route email back to the on-premise Exchange 2010 server? Or, is the only and best solution to sync all objects (users and distribution groups) to the on-premise AD to the Office 365 Azure AD? The Dell CloudStore support technicians directed us to create a new on-premise OU and only move the users who would be migrated into this OU. They then had us configure Azure AD Connect to filter on this OU. The end result is utility mailboxes and distribution groups cannot be reached from migrated 365 users: they get the 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup NDR message. Thanks ahead of time for any advice.

    1. Hi Scot – been OOF for a bit.

      Is this still going on?

      While we could do some things to connectors, really we do want to see objects synchronised. If not, then you will run into mailflow issues, and also will not get a complete GAL.

      Cheers,
      Rhoderick

  3. Tom says:

    Hello, I’ve run into nearly the same situation (as Scot) with my new Exchange 2010 Hybrid setup. My O365 user receives the same NDR as you have detailed above. Am I mistaken that the tenant can reach out across the ExOnline connector (to the on-prem Exchange organization) and determine that the recipient exists only on-prem? In pilot implementations where only a few on-prem user objects are sync’ed to the tenant via AADConnect (in my case via a Security Group, not an OU), how are those native-O365 users meant to be aware of the on-prem org (if they receive NDR’s when they send email to them)?

    Appreciate your posting Rhoderick, it’s presented really well. Cheers! -Tom.

    1. Hi Tom,

      Since this is bubbling up, finished off yet another draft post. It is scheduled to go out on Monday.

      Take a peek at that when it posts, and let me know if that fixes you up.

      Cheers,
      Rhoderick

Skip to main content