Our organization is on Office 365 for email for quite few years and configured with a domain say '@abc.com'. Last year the company got acquired by '@xyz.com' which runs only on premise of Exchange. The leadership in our organization decided to come up with a new domain which would reflect both the companies '@abcxyz.com' so that our existing customers still see us in their email domain. As the email admins in the parent org(xyz) configured '@abcxyz.com' on their DNS so that all the "incoming emails" flows on-premise and created user accounts for each of our users and a mail forwarding on the individual mailbox towards '@abc.com' On Office 365, we have added additional alias for each user @abcxyz.com so that their primary SMTP reflects the new brand change and all outgoing mails carried the new domain when users sent emails.

All these were working good until the parent organization decided to migrate and move few users on-premise.

How we did - Remove the existing mail forward rule from parent org. Configure Mail redirection on individual's mail box in O365 to '@xyz.com' which is found under user's Mail Options.

After migrating, Internal emails from '@abcxyz.com' users gets received without issues.

Issue: when mail sent from a user at '@xyz.com' to '@abc.com'.

The email in this case supposed to go from on premise to Office 365 and redirects back to On premise (from redirection rule) but didn't. emails weren't received in user's mailbox No NDRs returned Message tracing on Office 365 shows emails redirected to destination When the redirection rule is changed to a different forwarding address or to a different domain, I could see mails getting delivered.

1 Answer 1


For this coexistence to work, I would choose to have all the forwarding to use new domain names.

Domain names that aren't "seen" by the users or public, and exist just for forwarding.

In Office 365, you already have this. '@abc.onmicrosoft.com' On-prem at parent company, use something new ('@123.com" for this example).

Set the on-prem server to be authoritative for '@123.com'. Office 365 is already authoritative for '@abc.onmicrosoft.com'

Set each onprem user to have a '@123.com' alias.

Create a contact on-prem for each Office 365 user, using their '@abc.onmicrosoft.com' SMTP address.

Doing this lets you manage the environments without trying to set domains as "Internal Relay" (instead of "Authoritative").

This is manual, but similar to what is done in a Exchange/O365 Hybrid Deployment.


A smoother alternative would be to utilize "Send Connectors" and set the on-prem and O365 domains as "Internal Relay" (instead of "Authoritative"). This allows a “shared SMTP namespace”

This can work well for what you describe, but everyone managing the servers needs to clearly understand what is going on.

References for "Internal Relay"

https://technet.microsoft.com/en-us/library/bb124423(v=exchg.150).aspx#BKMK_InternalRelayDomains https://technet.microsoft.com/en-us/library/jj657737(v=exchg.150).aspx https://gaptheguru.wordpress.com/exchange-2/understanding-exchange-server-accepted-domain/

You still don't have a shared address book using these methods, without creating contacts on both sides.

EDIT: Ooops, I just noticed this is four months old. You probably have a solution by now.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .