Jedna domena, dwie poczty: split delivery bez złudzeń

Firma od lat pracuje na Google Workspace. Gmail jest dobrze znany, konta są uporządkowane, a zmiana całej platformy nie ma biznesowego uzasadnienia. W pewnym momencie pojawia się jednak zespół, który potrzebuje Exchange Online: przejęta spółka korzysta z Microsoft 365, dział pracuje na rozwiązaniu wymagającym skrzynki Exchange albo wydzielona jednostka musi ściśle współpracować w Outlooku i Teams.

Pierwsza myśl jest prosta: zostawmy domenę w Google, a wiadomości tego zespołu przekierujmy do Microsoftu. Technicznie da się to zrobić. Dobrze zaprojektowane rozwiązanie może działać przez lata. Tyle że między „wiadomość przyszła” a „mamy niezawodną pocztę” znajduje się kilka ważnych warstw: routing w obie strony, ochrona przed pętlami, uwierzytelnienie nadawcy, filtrowanie spamu, obsługa aliasów, monitoring i odpowiedzialność za incydenty.

Ten model nazywa się split delivery. Warto wiedzieć, jak działa, zanim stanie się stałym elementem firmowej infrastruktury.

Co właściwie dzielimy

W split delivery jedna domena pocztowa, na przykład firma.pl, obsługuje użytkowników w dwóch systemach. Część skrzynek znajduje się w Google Workspace, a część w Exchange Online. Z zewnątrz wszyscy nadal używają adresów w tej samej domenie.

Nie oznacza to, że każda wiadomość trafia do dwóch skrzynek. To byłoby dual delivery. Nie chodzi też o zwykłą regułę przekierowania ustawioną samodzielnie przez użytkownika. Split delivery działa na poziomie transportu poczty: system rozpoznaje adres odbiorcy i wybiera jego właściwy serwer.

To rozróżnienie ma znaczenie. Przy poprawnym podziale każda osoba ma jedną skrzynkę będącą źródłem prawdy. Historia, odpowiedzi, reguły, retencja i wyszukiwanie nie rozchodzą się między Gmaila i Outlooka.

Google opisuje split delivery jako wspierany scenariusz dla organizacji, w których część użytkowników korzysta z Gmaila, a część z innego systemu. Warunek jest rozsądny: odbiorca powinien mieć skrzynkę w jednym miejscu, a nie w obu. Szczegóły znajdują się w dokumentacji Google Workspace.

Jak wygląda droga wiadomości

Najczytelniejszy model ma jedno główne wejście. Rekord MX domeny nadal wskazuje Google Workspace. Każda wiadomość z internetu najpierw trafia więc do Google, przechodzi podstawowe kontrole i dopiero potem jest dostarczana do Gmaila albo kierowana bezpośrednio do Exchange Online.

Na schemacie są dwie drogi, o których trzeba pamiętać:

1. Google kieruje wiadomości wybranej grupy odbiorców do Exchange Online.
2. Microsoft odsyła wiadomości adresowane do pozostałych użytkowników domeny przez connector do Google.

Druga droga bywa pomijana. Tymczasem Exchange musi wiedzieć, że nie jest właścicielem wszystkich skrzynek w domenie. W Microsoft 365 domenę konfiguruje się w takim modelu jako Internal Relay, a wiadomości do nierozpoznanych lokalnie użytkowników trafiają przez kontrolowany connector do Google. Microsoft opisuje ten mechanizm w swoim scenariuszu współistnienia małej grupy skrzynek.

Bez drogi zwrotnej poczta z internetu może wyglądać poprawnie, a wiadomość wysłana z Outlooka do kolegi korzystającego z Gmaila zakończy się błędem. To klasyczny przykład konfiguracji, która „działała na testach”, bo przetestowano tylko jeden kierunek.

Kiedy taki model ma sens

Split delivery sprawdza się tam, gdzie podział wynika z realnej potrzeby, a nie chwilowej preferencji interfejsu.

Przejęcie spółki lub połączenie organizacji

Jedna firma używa Google Workspace, druga Microsoft 365. Natychmiastowa migracja wszystkich skrzynek zwiększa ryzyko i pochłania czas zespołu w najtrudniejszym okresie integracji. Wspólna domena i kontrolowany routing mogą dać przestrzeń na etapowe uporządkowanie kont, danych i procesów.

Jednostka pracująca w ekosystemie Microsoft

Wydzielony dział może potrzebować funkcji Exchange Online, integracji z systemem branżowym, zaawansowanego kalendarza albo polityk dostępnych w środowisku Microsoft. Reszta organizacji nie musi z tego powodu porzucać Gmaila.

Migracja wykonywana etapami

Przenoszenie wszystkich użytkowników jednego wieczoru nie zawsze jest rozsądne. Split delivery pozwala migrować grupami, obserwować efekty i poprawiać proces przed kolejną falą. W takim przypadku od początku warto ustalić datę zakończenia współistnienia, bo rozwiązanie przejściowe łatwo staje się stałym przez przypadek.

Wymogi kontraktowe lub organizacyjne

Czasem konkretny projekt, partner albo jednostka regulowana wymaga pracy w określonym środowisku. Podział poczty może odseparować tę część bez przebudowy całej organizacji, o ile retencja, audyt i ochrona danych zostały zaprojektowane świadomie.

Jeżeli jedynym wymaganiem jest aplikacja Outlook, sytuacja wygląda inaczej. Outlook potrafi obsługiwać konto Google, więc uruchamianie drugiej platformy pocztowej może być niepotrzebne. Microsoft opisuje podłączenie Gmaila do Outlooka jako standardową funkcję klienta.

Test „wysłałem z prywatnej skrzynki” nie wystarcza

Poczta firmowa porusza się wieloma drogami. Wiadomość z zewnętrznego adresu do użytkownika Exchange może dojść poprawnie, podczas gdy komunikacja między osobami w tej samej domenie jest zepsuta.

Przed uruchomieniem produkcyjnym sprawdzamy co najmniej:

1. internet → skrzynka Google,
2. internet → skrzynka Microsoft,
3. Google → Microsoft w tej samej domenie,
4. Microsoft → Google w tej samej domenie,
5. Google i Microsoft → odbiorcy zewnętrzni,
6. odpowiedzi wracające do obu środowisk.

Do tego dochodzą aliasy, grupy, kopie ukryte, autorespondery, wiadomości z aplikacji firmowych, zaproszenia kalendarzowe i załączniki podlegające filtrom bezpieczeństwa. Każdy test powinien potwierdzić nie tylko obecność wiadomości w skrzynce. Sprawdzamy nagłówki, wynik SPF, DKIM i DMARC, użyty connector, czas dostarczenia oraz to, czy wiadomość nie ominęła oczekiwanego filtra.

Najczęstszy błąd: ruch wewnętrzny

Google rozróżnia pocztę przychodzącą z internetu i wiadomości wysyłane wewnątrz organizacji. Reguła obejmująca tylko ruch przychodzący może prawidłowo dostarczać wiadomości od klientów, ale nie zadziałać, gdy pracownik Gmaila napisze do koleżanki w Exchange Online.

Po stronie Microsoftu pojawia się lustrzany problem. Jeśli domena zostanie oznaczona jako autorytatywna, Exchange zakłada, że zna wszystkich jej odbiorców. Adres użytkownika istniejącego wyłącznie w Google może wtedy zostać potraktowany jako nieprawidłowy. Typ domeny Internal Relay oraz connector zwrotny rozwiązują ten problem, pod warunkiem że reguły nie przejmują skrzynek lokalnych Microsoftu.

Właśnie dlatego podziału nie projektuje się jako pojedynczego przekierowania. To zamknięty obieg, w którym oba systemy muszą wiedzieć, kiedy dostarczyć lokalnie, a kiedy przekazać dalej.

Pętla, czyli wiadomość krążąca między chmurami

Jeżeli Google ma przekazać pocztę do Microsoftu, nie może po prostu wykonać ponownego zapytania o publiczny MX domeny. MX wskazuje przecież Google, więc wiadomość wróciłaby do punktu wyjścia.

Trasa musi prowadzić do konkretnego punktu Exchange Online przypisanego tenantowi albo do kontrolowanego adresu technicznego. W drugą stronę connector Microsoftu powinien kierować do Google tylko odbiorców, których Exchange nie posiada lokalnie.

Przed uruchomieniem warto ustawić limit liczby przeskoków, czytelne nagłówki diagnostyczne i alerty na nietypowy wzrost liczby wiadomości. Pętla pocztowa nie zawsze jest widowiskową awarią. Czasem objawia się opóźnieniem, wielokrotnym autoresponderem albo kolejką, która rośnie po cichu.

Jedna osoba, jedna skrzynka

Pozostawienie aktywnej skrzynki Gmail i Exchange tej samej osobie wydaje się bezpieczne: „przynajmniej wiadomość będzie w dwóch miejscach”. W codziennej pracy szybko pojawiają się jednak dwie historie korespondencji, różne stany przeczytania, niespójne reguły, dwa autorespondery i pytanie, z którego systemu wysłano odpowiedź.

Konto Google może pozostać potrzebne do Drive, dokumentów albo logowania. Nie oznacza to, że musi nadal przechowywać pocztę. Właściciel skrzynki powinien być jednoznaczny, a katalog użytkowników, aliasów i grup musi odzwierciedlać ten podział.

Ta sama zasada dotyczy archiwizacji. Dwie kopie w skrzynkach nie zastępują polityki retencji ani backupu. W przypadku kontroli lub incydentu firma powinna wiedzieć, gdzie znajduje się kompletna historia i kto może ją zabezpieczyć.

SPF, DKIM i DMARC dla dwóch nadawców

W split delivery Google i Microsoft mogą wysyłać wiadomości z tej samej domeny. Odbiorca zewnętrzny musi potrafić potwierdzić, że oba źródła są legalne.

Domena powinna mieć jeden rekord SPF obejmujący oba systemy, na przykład:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Google podaje taki wariant wprost w instrukcji konfiguracji SPF. Nie tworzymy dwóch osobnych rekordów SPF, bo to prowadzi do błędu walidacji.

DKIM uruchamiamy niezależnie u obu dostawców. Google podpisuje pocztę własnym selektorem, a Exchange Online używa selektorów Microsoftu. Rekord DMARC pozostaje wspólną polityką domeny. Jego raporty są szczególnie cenne po wdrożeniu, ponieważ pokazują, czy oba środowiska przechodzą uwierzytelnienie i czy pojawiły się nieznane źródła wysyłki.

Zmiany najlepiej wprowadzać etapami. Najpierw zbieramy raporty, sprawdzamy alignment, a dopiero później zaostrzamy politykę od p=none do kwarantanny lub odrzucania. DKIM można skonfigurować zgodnie z instrukcjami Google Workspace oraz Microsoft 365.

Dwa filtry bezpieczeństwa i możliwe obejście

Wiadomość do skrzynki Exchange może najpierw przejść przez ochronę Gmaila, a następnie przez Exchange Online Protection. Dwie warstwy brzmią dobrze, lecz mogą inaczej klasyfikować phishing, załączniki i linki. Administrator musi wiedzieć, która platforma zatrzymała wiadomość i gdzie jej szukać.

Istnieje też mniej oczywisty problem. Publiczny adres ochrony poczty Exchange Online jest osiągalny niezależnie od rekordu MX. Nadawca może próbować dostarczyć wiadomość bezpośrednio do Microsoftu i ominąć pierwszy filtr w Google. Dlatego ruch Google → Microsoft powinien być objęty dedykowanym connectorem, wymaganiem TLS i warunkami identyfikującymi zaufane źródło. Microsoft pozwala ograniczać connectory między innymi przez certyfikat, domenę lub zakres adresów IP; opisuje to w dokumentacji bezpiecznego przepływu poczty.

Gdzie naprawdę może zaginąć wiadomość

Na drodze od nadawcy do skrzynki nie ma jednego magicznego punktu „poczta”. Jest łańcuch usług, z których każda może opóźnić, odrzucić albo inaczej sklasyfikować wiadomość.

Typowe słabe miejsca to:

• nieaktualny MX lub błędny cel trasy,
• adres nieuwzględniony w regule odbiorców,
• certyfikat niespełniający warunków connectora,
• wiadomość zatrzymana przez drugi filtr antyspamowy,
• alias albo grupa istniejąca tylko w jednym katalogu,
• reguła transportowa powodująca pętlę,
• skrzynka bez licencji lub przekroczony limit,
• brak osoby odbierającej alert z kolejki.

Niezawodność powstaje z widoczności. Potrzebne są logi obu dostawców, Message Trace w Microsoft 365, Email Log Search w Google, raporty DMARC oraz testowe wiadomości przechodzące cyklicznie najważniejszymi trasami. Alert bez właściciela ma niewielką wartość, dlatego każda nieudana ścieżka powinna mieć ustaloną procedurę reakcji.

Czy to jest zapasowa poczta u drugiego dostawcy

Nie. Jeśli MX wskazuje Google, Google pozostaje pierwszym punktem wejścia dla całej domeny. Awaria lub błędna reguła po stronie Google może wpłynąć również na odbiorców Exchange Online.

SMTP potrafi kolejkować wiadomości i ponawiać próbę po krótkiej niedostępności następnego serwera. To ogranicza skutki chwilowych awarii, lecz nie zastępuje ciągłości działania. Microsoft informuje, że wiadomości niedostarczone przez connector są ponawiane przez ograniczony czas, obecnie do 24 godzin. Po jego przekroczeniu nadawca może otrzymać błąd.

Dodanie drugiego, niższego priorytetem MX nie rozwiązuje automatycznie problemu. Alternatywny serwer musiałby umieć bezpiecznie obsłużyć wszystkich odbiorców i skierować ich do właściwych systemów. Bez pełnego projektu taki „backup MX” tworzy nowe obejście filtrów i kolejne miejsce na pętlę.

Kalendarze, grupy i procesy też należą do projektu

Sama poczta może działać idealnie, a użytkownicy nadal odczuwać podział. Dostępność free/busy między platformami, rezerwacja sal, delegowanie skrzynek, grupy dystrybucyjne, kontakty organizacyjne i zaproszenia kalendarzowe nie zawsze przechodzą tak naturalnie jak zwykły e-mail.

Microsoft w opisie małego pilota zaznacza brak automatycznej informacji free/busy dla użytkowników drugiego systemu. W stałej architekturze trzeba więc ustalić, które funkcje współpracy są wymagane, kto prowadzi katalog i jak synchronizowane są zmiany personalne.

Offboarding również obejmuje dwa środowiska. Usunięcie konta z jednego panelu może pozostawić alias, regułę routingu albo aktywny dostęp w drugim. Proces odejścia pracownika powinien zamykać skrzynkę, licencję, grupy, delegacje i reguły transportowe w jednym kontrolowanym zadaniu.

„Na zawsze” oznacza stałe utrzymanie

Split delivery może być architekturą docelową. Nie powinien być jednak konfiguracją pozostawioną bez właściciela. Dostawcy zmieniają interfejsy, certyfikaty są odnawiane, zespoły powstają i znikają, a kolejne aplikacje zaczynają wysyłać pocztę z firmowej domeny.

Minimalny model utrzymania obejmuje:

• aktualną listę skrzynek i systemów, które je obsługują,
• przegląd reguł routingu oraz connectorów po każdej większej zmianie,
• automatyczne testy krytycznych kierunków,
• kontrolę kolejek, opóźnień i liczby odrzuceń,
• monitoring SPF, DKIM i raportów DMARC,
• test procedury awaryjnej,
• udokumentowanego właściciela po obu stronach integracji.

Wtedy rozwiązanie przestaje zależeć od osoby, która pamięta, „gdzie kiedyś kliknęła przekierowanie”. Staje się normalną, obserwowalną usługą.

Kiedy lepiej wybrać jedną platformę

Podział nie zawsze jest wart swojej ceny. Jeżeli różnica sprowadza się do preferencji aplikacji, prostsze będzie podłączenie konta Google do Outlooka. Jeżeli większość procesów firmy przenosi się do Teams i Exchange, długoterminowo tańsza może być pełna migracja do Microsoft 365. Podobnie organizacja oparta na Google Meet, Drive i Gmailu może zrezygnować z utrzymywania osobnej wyspy Exchange.

Przed decyzją warto odpowiedzieć na pięć pytań:

1. Czy wydzielona grupa potrzebuje funkcji serwerowych Exchange, czy tylko klienta Outlook?
2. Czy podział ma datę zakończenia, czy jest architekturą docelową?
3. Kto utrzymuje routing, uwierzytelnienie i monitoring?
4. Jak mają działać kalendarze, grupy, retencja i obsługa incydentów?
5. Ile kosztuje dodatkowa złożoność w porównaniu z migracją?

Jeżeli odpowiedzi są konkretne, split delivery może rozwiązać realny problem bez wywracania całej organizacji. Jeżeli brzmią „zobaczymy później”, podział prawdopodobnie zamieni się w trudny do zdiagnozowania dług operacyjny.

Dwie chmury mogą współpracować, ale potrzebują jednego projektu

Google Workspace i Microsoft 365 potrafią obsługiwać jedną domenę jednocześnie. Kluczowe jest potraktowanie tego jak integracji dwóch systemów krytycznych: z jednoznacznym właścicielem skrzynki, trasą w obie strony, zabezpieczonymi connectorami, poprawnym SPF/DKIM/DMARC oraz monitoringiem całej drogi wiadomości.

Najlepszy split delivery jest dla użytkownika niewidoczny. Wiadomość dochodzi, odpowiedź wraca, a dział IT potrafi szybko ustalić, co wydarzyło się po drodze. Osiąga się to projektem i utrzymaniem, nie pojedynczą regułą przekierowania.

Jeżeli rozważasz współistnienie Google Workspace i Microsoft 365 albo chcesz uporządkować już działający podział, w ramach usługi Partner IT możemy przeanalizować przepływ poczty, bezpieczeństwo domeny i procedury utrzymaniowe, a następnie przygotować rozwiązanie dopasowane do rzeczywistych procesów organizacji.