Hi Peter,
Thanks for your response in the private message.
I understand that this issue happens when on-premise users send emails to the migrated users.
For a staged migration, the migration service will configure mail forwarding by configuring the TargetAddress property on the on-premises mailbox with the email address of the Exchange Online mailbox. This means that mail sent to the on-premises mailbox is forwarded to the corresponding Exchange Online mailbox.
Before the staged migration is completed, the MX record should still point to the on-premise Exchange. Therefore, when an on-premise user (such as user1) sends an email to one migrated user (user2), the email will first be delivered to user1’s on-premise mailbox, and then be redirected to user2’s cloud mailbox. Based on the NDR you provided, I notice the mail flow fails when the on-premise Exchange tries to redirect the email to the cloud mailbox.
You also mention “sender does not need to be on-premise user can be external incoming email”. When external users send emails to user2, the emails are also delivered to user2’s on-premise mailbox, and then redirected to user2’s cloud mailbox.
Based on my experience, the possible cause is that: the on-premise Exchange cannot resolve the MX of this domain “xxxx.onmicrosoft.com”, just like the NDR says: “The destination server for this recipient could not be found in Domain Name Service (DNS)”
Do you use internal DNS server? I think we can perform a test to narrow down this issue:
1. Directly create an Office 365 account test@xxxx.onmicrosoft.com, and assign a license to this user.
2. Send test emails to test@xxxx.onmicrosoft.com from on-premise users and external emails. Emails from on-premise users will be directly sent to the cloud mailbox. On this situation, if on-premise users still cannot send emails to cloud users, but external users can send emails to cloud users, we can see this issue is indeed related to on-premise Exchange settings, such as internal DNS server.
Moreover, to resolve this issue effectively, I suggest you involve on-premise Exchange engineers to cooperate on this issue. They are more proficient in on-premise Exchange configurations and analyzing on-premise logs. Here is the Exchange server forum:
social.technet.microsoft.com/.../home
You can ask them why on-premise Exchange cannot resolve a specific domain “xxxx.onmicrosoft.com”. If you get any feedback from op-premise Exchange engineers, you can also share the information with us.
If there is anything unclear, please feel free to let us know.
Moreover, you’re right. This issue will be resolved automatically when the whole cutover migration is fully completed, as you mention “resolve itself when the staged migration is complete and the old server is not relaying the messages”.
Thanks,
Young Yang