split domain routing

Split domain routing to kierowanie części poczty danej domeny lokalnie, a części do chmury, w zależności od odbiorcy.

Na czym polega split domain routing

Split domain routing, nazywane także hybrydowym kierowaniem poczty dla jednej domeny, oznacza podział obsługi adresów e-mail pomiędzy dwa niezależne systemy. Część skrzynek znajduje się w lokalnym serwerze pocztowym, a pozostałe są utrzymywane w usłudze chmurowej. Użytkownik wysyłający wiadomość nadal korzysta z jednej domeny, na przykład firma.example, lecz dalsza trasa wiadomości zależy od adresata. Adres Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript. może być obsługiwany lokalnie, natomiast Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript. może wskazywać skrzynkę w chmurze. Z punktu widzenia nadawcy oba adresy należą do tej samej domeny, ale system routingu musi rozpoznać, gdzie faktycznie znajduje się dana skrzynka.

W zwykłym modelu poczta dla domeny jest kierowana według rekordów DNS typu MX do jednego zestawu serwerów. Split domain routing wymaga dodatkowej logiki po stronie systemu pocztowego. Serwer odbierający wiadomość dla własnej domeny nie może automatycznie uznać każdego adresu za lokalną skrzynkę. Musi sprawdzić, czy konkretny odbiorca istnieje w lokalnym katalogu. Jeżeli nie istnieje, wiadomość jest przekazywana do drugiego środowiska, zwykle przez ustalony host SMTP lub regułę konektora. Rekord MX wskazuje zatem punkt wejścia dla domeny, ale sam nie opisuje wszystkich tras poszczególnych użytkowników.

Rozpoznawanie odbiorcy i przekazanie wiadomości

Przepływ wiadomości w takim układzie zaczyna się od zapytania DNS o rekordy MX domeny odbiorcy. Nadawca lub jego serwer pocztowy łączy się z serwerem wskazanym przez MX i rozpoczyna sesję SMTP. Po komendzie EHLO następuje między innymi komenda MAIL FROM, a następnie jedna lub więcej komend RCPT TO. To właśnie adres z pola RCPT TO jest używany do ustalenia, czy odbiorca jest obsługiwany lokalnie, czy powinien zostać przekazany do drugiego systemu.

Jeżeli lokalny serwer zna adres odbiorcy, przyjmuje wiadomość do swojej kolejki dostarczenia. Jeżeli adres nie jest lokalny, serwer może przekazać wiadomość do skonfigurowanego środowiska chmurowego. W zależności od architektury przekazanie może odbywać się przez ponowne wyszukanie MX, przez określony host pośredniczący albo przez dedykowany konektor SMTP. Ważne jest, aby trasa do drugiego systemu nie prowadziła z powrotem do pierwszego serwera. Błędne wskazanie hosta docelowego może utworzyć pętlę pocztową, w której wiadomość krąży między systemami aż do wyczerpania limitu hopów lub odrzucenia przez serwer.

Podział może działać także w kierunku odwrotnym. Wiadomość wysłana ze skrzynki chmurowej do odbiorcy lokalnego musi zostać przekazana do serwera obsługującego lokalną część domeny. Wymaga to zgodnej konfiguracji tras wychodzących, autoryzacji połączenia i akceptowania wiadomości od zaufanego systemu. Sam fakt, że nadawca i odbiorca używają tej samej domeny, nie gwarantuje poprawnego dostarczenia. Oba środowiska muszą mieć spójne informacje o zakresie lokalnych adresów oraz o tym, które adresy należy przekazywać dalej.

DNS, SMTP i typowe miejsca niespójności

Najczęstsze problemy wynikają z pomieszania funkcji DNS z funkcjami routingu aplikacyjnego. Rekord MX określa serwer przyjmujący pocztę dla domeny, lecz nie zawiera listy wszystkich skrzynek ani reguł podziału odbiorców. Rekordy TXT związane z SPF również nie wyznaczają trasy przychodzącej poczty. SPF opisuje, jakie serwery mogą wysyłać wiadomości z danego zakresu adresów IP lub za pośrednictwem wskazanych mechanizmów, natomiast nie rozstrzyga, gdzie znajduje się konkretna skrzynka.

Podczas analizy należy sprawdzić zarówno publiczne rekordy DNS, jak i konfigurację lokalnego serwera oraz środowiska chmurowego. Istotne są: aktualny rekord MX, rozwiązywanie nazw hostów, możliwość nawiązania połączenia TCP z portem SMTP, certyfikat TLS, nazwa używana w poleceniu EHLO, reguły akceptowania domeny oraz lista adresów uznawanych za lokalne. Błąd w jednym miejscu może wyglądać jak awaria innego elementu. Na przykład odrzucenie komunikatem „user unknown” może oznaczać brak adresu w lokalnym katalogu, ale także nieprawidłowe ustawienie trybu obsługi nieznanych odbiorców. Z kolei kod SMTP 4xx zwykle wskazuje na problem tymczasowy, taki jak niedostępność hosta, limit połączeń albo opóźnienie w kolejce.

Trzeba również uwzględnić uwierzytelnianie i kontrolę antyspamową. System przekazujący wiadomość powinien być rozpoznawany przez odbiorcę jako dozwolony nadawca, a reguły antyspamowe nie powinny traktować prawidłowego przekazania jako próby podszycia się. Znaczenie mają także podpisy DKIM, polityka DMARC i sposób zachowania nagłówka Return-Path. Ich konfiguracja nie zastępuje split domain routing, ale wpływa na ocenę wiadomości po przekazaniu. Diagnostyka powinna obejmować pełny ślad wiadomości: czas przyjęcia, serwer pośredniczący, odpowiedź SMTP, identyfikator kolejki oraz końcowy status dostarczenia.

Diagnostyka trasy wiadomości w podzielonej domenie

Praktyczne sprawdzenie konfiguracji zaczyna się od ustalenia dwóch kontrolowanych adresów: jednego obsługiwanego lokalnie i drugiego znajdującego się w chmurze. Dla obu należy wykonać osobną próbę dostarczenia z zewnętrznego nadawcy, z systemu lokalnego oraz z systemu chmurowego. Porównanie wyników pozwala ustalić, czy błąd dotyczy przyjęcia wiadomości, rozpoznania odbiorcy, przekazania, czy końcowego dostarczenia do skrzynki. Warto zachować pełne nagłówki, ponieważ pola Received pokazują kolejne serwery uczestniczące w transporcie.

W logach SMTP należy szukać adresu odbiorcy, kodu odpowiedzi, identyfikatora wiadomości i informacji o wybranej trasie. Komunikat 550 może oznaczać trwałe odrzucenie, na przykład nieistniejącego adresu albo braku uprawnień do przekazania. Kod 451 lub temporary failure wskazuje na sytuację przejściową i wymaga sprawdzenia ponawiania dostarczenia oraz stanu kolejki. Jeżeli wiadomość jest przyjmowana, lecz nie pojawia się w drugim środowisku, należy sprawdzić reguły przekazania, połączenie SMTP, filtrowanie po adresie IP i logi serwera docelowego. Jeżeli wiadomość wraca do nadawcy po kilku minutach, trzeba zweryfikować, czy oba systemy nie reklamują się wzajemnie jako właściwy punkt dostarczenia.

Przy zmianie konfiguracji bezpieczniej jest testować pojedyncze adresy i obserwować logi po każdej zmianie. Zbyt szeroka reguła przekazywania może spowodować przekierowanie wiadomości lokalnych do chmury, a zbyt wąska może pozostawić część odbiorców bez działającej trasy. Należy także pamiętać o aliasach, grupach, adresach współdzielonych i automatycznych odpowiedziach, ponieważ nie zawsze są reprezentowane w katalogu tak samo jak zwykłe skrzynki. Prawidłowa konfiguracja split domain routing wymaga zgodności DNS, katalogów adresowych, reguł SMTP, zabezpieczeń transportu i monitorowania kolejek, a nie tylko ustawienia jednego rekordu domeny.