Наша организация использует Office 365 для электронной почты уже несколько лет и настроен с доменом, например, «@ abc.com». В прошлом году компанию приобрел @ xyz.com, который работает только на базе Exchange. Руководство нашей организации решило придумать новый домен, который отражал бы обе компании «@ abcxyz.com», чтобы наши существующие клиенты по-прежнему видели нас в своем домене электронной почты. Поскольку администраторы электронной почты в родительской организации (xyz) настроили '@ abcxyz.com' на своем DNS, чтобы все «входящие электронные письма» поступали локально, и создали учетные записи пользователей для каждого из наших пользователей и переадресацию почты в отдельном почтовом ящике. в сторону «@ abc.com». В Office 365 мы добавили дополнительный псевдоним для каждого пользователя @ abcxyz.com, чтобы их основной SMTP отражал новое изменение бренда, а все исходящие письма переносились на новый домен, когда пользователи отправляли электронные письма.
Все это работало хорошо, пока головная организация не решила перенести и переместить несколько пользователей локально.
Как мы это сделали - удалили существующее правило пересылки почты из родительской организации. Настройте перенаправление почты в почтовом ящике пользователя в O365 на адрес @ xyz.com, который находится в разделе Параметры почты пользователя.
После миграции внутренние электронные письма от пользователей «@ abcxyz.com» принимаются без проблем.
Проблема: когда почта отправляется от пользователя с адреса «@ xyz.com» на адрес «@ abc.com».
Электронная почта в этом случае должна была перейти из помещения в Office 365 и перенаправить обратно в локальную среду (из правила перенаправления), но этого не произошло. электронные письма не были получены в почтовый ящик пользователя. Отчеты о недоставке не возвращены. При отслеживании сообщений в Office 365 отображаются электронные письма, перенаправленные по назначению. Когда правило перенаправления изменено на другой адрес пересылки или в другой домен, я мог видеть, как доставляются письма.
Чтобы такое сосуществование работало, я бы предпочел, чтобы при пересылке использовались новые доменные имена.
Доменные имена, которые не «видны» пользователям или публике и существуют только для пересылки.
В Office 365 это уже есть. '@ abc.onmicrosoft.com' Локально в материнской компании, используйте что-нибудь новое ('@ 123.com "в этом примере).
Сделайте локальный сервер полномочным для "@ 123.com". Office 365 уже авторизован для @ abc.onmicrosoft.com
Задайте каждому пользователю onprem псевдоним @ 123.com.
Создайте контакт локально для каждого пользователя Office 365, используя их SMTP-адрес @ abc.onmicrosoft.com.
Это позволяет вам управлять средами, не пытаясь установить домены как «Внутренний ретранслятор» (вместо «Полномочный»).
Это выполняется вручную, но похоже на то, что делается при гибридном развертывании Exchange / O365.
================================================== ===================
Более удобной альтернативой было бы использование «Коннекторов отправки» и установка локального домена и домена O365 как «Внутренний ретранслятор» (вместо «Полномочный»). Это позволяет использовать «общее пространство имен SMTP»
Это может хорошо работать для того, что вы описываете, но каждый, кто управляет серверами, должен четко понимать, что происходит.
Ссылки на "Внутреннее реле"
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/
У вас по-прежнему нет общей адресной книги, использующей эти методы, без создания контактов с обеих сторон.
РЕДАКТИРОВАТЬ: Ой, я только что заметил, что ему четыре месяца. У вас, вероятно, есть решение.