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