Configuration is as follows:
- Domain hosting.contoso.com hosts an on-premises Exchange 2013 organization, that hosts several second level domains, including the contoso.com domain. The domain is in a separate forest, and has a forest trust with domain office.contoso.com, which is also a root domain of a separate forest.
- There is a VPN connection established between office.contoso.com and hosting.contoso.com, and all Exchange servers are available to both sides via internal IP ranges.
- Users in domain office.contoso.com have an UPN suffix of contoso.com, and connect to Exchange organization via MAPI over HTTPS resolved to external IP ranges of Exchange servers on hosting.contoso.com domain.
- The contoso.com name server is a standalone DNS server exposed as NS1.contoso.com to the Internet, and hosts all required MX, A, TXT and SRV records for contoso.com Exchange organization necessary to locate it from outside. OWA is also published and working.
- The office.contoso.com domain has recently been integrated with AD FS to Microsoft Office 365 tenant organization, which happens to have an Exchange organization of their own, however none of the DNS records of contoso.com are pointing to microsoft.com, office.com, outlook.com or elsewhere from Microsoft. All configuration is complete, neither side reports problems with AD integration.
A user from office.contoso.com has sent a message with Outlook 2016 from within internal network of office.contoso.com domain to a third party, with a CC address of one of public folder mailboxes in on-premises Exchange organization, and didn't get the message in that public folder. Investigation eventually discovered that the e-mail got sent via Office 365's Exchange organization which does not have the public folder's e-mail address registered, therefore an NDR was generated and placed into a cloud-based Exchange mailbox associated with this user. The third party had received the message properly, despite the SPF record of contoso.com domain that should have prevented Microsoft's servers to successfully send that email, as their external IP addresses do not reversely resolve to any of the contoso.com DNS names. (Third party mail server configuration is out of scope of this question)
The question is:
- HOW can Outlook discover that there is another Exchange organization set up to both connect and send e-mails for domain office.contoso.com?
- WHY did it actually decide to connect elsewhere but the primary Exchange account already configured to use the address from @contoso.com?
- WHY did Outlook NOT show the contents of the wrong mailbox after such a failover, and WHY did Outlook post the "Sent" message to the right mailbox, while sending it via wrong mailbox?
- HOW COME Office 365's Outlook installed on a PC in an external network connects to Office 365's organization despite valid autodiscover address existing in contoso.com domain? If a standalone installation of same Office version that's not using Office 365 for activation is used, autodiscovery process completes in a snap, with it getting connected with RPC/MAPI over HTTPS to the on-premises Exchange CAS server.
- What should the systems administrator of office.contoso.com domain perform to BOTH allow Office 365's Exchange organization to exist, and completely eliminate any chance of users' Outlooks to ever connect to it unless directly specified?