Menu Zamknij

Office 365 (Exchange Online) i wysyłanie maili z tego samego username w obydwu domenach

Exchange Online, jak to Exchange w ogólności może być irytujący. Tego, że tak oczywista sprawa, jak posiadanie dwóch domen i chęć wysłania maili używając tego samego użytkownika, ale różnych domen może być utrudnione – to się nie spodziewałem. Przykład konkretny i wcale nie tajny – dwa maile [email protected] i [email protected] hostowane na Office 365.

Office 365 dość dobrze obsługuje kilka domen podpiętych do jednej organizacji – domyślnie ustawia każdemu użytkownikowi alias w każdej dostępnej domenie (na przykład [email protected] i [email protected]) i pozwala administratorom na ręczne ustawienie dowolnego aliasu w obrębie wszystkich domen (na przykład dodatkowo [email protected], ale już [email protected]).

Rozwiązanie pierwsze – EmailAddressPolicyEnabled

Teoretycznie, jeśli użytkownik Exchange’a posiada kilka aliasów, na które poczta przychodząca trafia do jego skrzynki, to powinien też móc wysyłać z nich maile. Nic bardziej mylnego. Stoi za tym domyślna polityka EmailAddressPolicy.

W webowym centrum administracyjnym powinna być gdzieś tutaj, ale nie zawsze będzie widoczna.

Odkąd Microsoft stworzył PowerShella, część zadań administracyjnych da się wykonać tylko z PowerShella – także w hostowanym przez Microsoft Exchange Online. Wyłączenie domyślnej polityki może brzmieć groźnie, ale jeśli tyczy się to administratorów Office 365 (najczęściej nas samych) to raczej wiedzą co robią 😉

Problem polega na tym, że Knowledge Base Microsoftu zaleca w opisanej powyżej sytuacji użycie cmldetu Set-Mailbox z przełącznikiem -EmailAddressPolicyEnabled:$false (https://docs.microsoft.com/en-us/powershell/module/exchange/set-mailbox?view=exchange-ps). Poza koniecznością odpalenia tego na Windowsie – żaden problem – prawda?

Odpowiedź na powyższy błąd znajdziemy w pierwszym akapicie dokumentacji tego cmldetu:

This cmdlet is available in on-premises Exchange and in the cloud-based service. Some parameters and settings may be exclusive to one environment or the other.

https://docs.microsoft.com/en-us/powershell/module/exchange/set-mailbox?view=exchange-ps

Istota problemu

Krótkie uzupełnienie co takiego robi domyślna polityka adresów e-mail: kiedy wysyłamy maila, sprawdza, czy mamy uprawnienia do wysyłania z adresu podanego w polu From. Jeśli nie mamy – podmieni adres From na nasz bazowy adres. Niestety polityka ta sprawdza tylko identity, czyli odpowiednik userPrincipalName, nie zaś aliasy. Także posiadając alias – nie mamy uprawnień do wysyłania z niego maili.

To assign a different SMTP address as the primary SMTP address for a recipient, you must disable the option to automatically update an email address based on the email address policy applied to the recipient.

https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-150/jj156614(v=exchg.150)?redirectedfrom=MSDN

Rozwiązanie drugie – Shared Mailbox

Inne źródła od razu wskazywały konieczność założenia skrzynki współdzielonej (Shared Mailbox) o takim adresie, jak alias, z którego chcemy wysyłać maile. Następnie należałoby ustawić sobie uprawnienia do tej skrzynki współdzielonej i przekierowanie maili na nią wpadających na podstawowe konto.

Zatem do dzieła:

Problem drugi – automatyczne aliasy

To jednak moment, kiedy w naszym przypadku dostaniemy taki oto przemiły błąd:

The proxy address „SMTP:[email protected]” is already being used by the proxy addresses or LegacyExchangeDN. Please choose another proxy address.

Czy to oznacza, że trzeba jedynie usunąć sobie proxy address, czyli alias z konta Exchange i po kłopocie? Otóż nie.

Problem polega na tym, że kiedy posiadamy kilka domen to Exchange z automatu doda nam alias w każdej domenie – nawet dla skrzynek współdzielonych. Czyli ta świeżo tworzona skrzynka poza adresem [email protected] dostanie alias… [email protected]

Obejście na szczęście jest dość proste – należy stworzyć Shared Mailbox z adresem o innej nazwie (tutaj: not_daniel), a następnie podmienić jej alias w domenie dsinf.net na właściwy [email protected], drugi zaś ([email protected]) można usunąć.

Zakończenie implementacji od strony użytkownika

Skoro mamy gotową skrzynkę współdzieloną użytkownik musi ją jeszcze podpiąć do swojej własnej. Jak to zrobić pokażę na przykładzie Outlook Web App (OWA).

Testowanie

Aby potwierdzić, że wszystko działa, jak należy, sprawdzimy, czy możemy wysłać maile z nowego aliasu poprawnie oraz, czy możemy je odebrać. Najłatwiej wykorzystać darmowe usługi online do testowania maili – ja użyłem 10minutemail.com do testu poczty wychodzącej oraz ismyemailworking.com do testu maili przychodzących.

Mail wpada do spamu, ale przychodzi poprawnie

Podsumowanie

Exchange jest nietrywialny, a w wersji Online – tym bardziej. Na szczęście da się obejść pewne problemy i cieszyć się wysyłaniem maili z aliasów w innych domenach.

Na zakończenie – taki oto maili wpada na główną skrzynkę odbiorczą, informując, iż skrzynka współdzielona właśnie zaczęła forwardowanie wszystkich maili – na tę główną 😉

Leave a Reply