Jak skonfigurować Microsoft 365 ze skrzynkami w swojej domenie w trybie hybrydowym (M365 + obecny serwer)

Dodano dnia przez Dawid Sobieraj

Cel: uruchomić pocztę w Microsoft 365 dla wybranych użytkowników w domenie willi.com.pl, pozostawiając istniejący serwer oraz obecny rekord MX bez zmian. Ruch przychodzący trafia nadal na dotychczasowy serwer, a wybrane skrzynki w M365 są obsługiwane przez mechanizm przekierowań oraz wewnętrzne trasowanie (Internal Relay) w Exchange Online.

Kiedy to ma sens?

  • chcesz migrację etapową (nie wszyscy naraz),
  • chcesz zachować MX na aktualnym hostingu,
  • chcesz równolegle działać: część skrzynek na starym serwerze, część w Exchange Online.

Architektura przepływu poczty (w skrócie)

  • Przychodząca: Internet → stary serwer (MX)
    • jeśli adres należy do użytkownika już przeniesionego do M365 → forward na jego alias @tenant.onmicrosoft.com
    • jeśli użytkownik pozostaje na starym serwerze → normalna dostawa lokalnie
  • Wychodząca:
    • z M365 → Internet (zgodnie z politykami M365, SPF/DMARC)
    • ze starego serwera → jak dotychczas

Wymagania wstępne (checklista)

  • Dostęp do: panelu DNS domeny willi.com.pl, centrum administracyjnego M365 (Microsoft 365 admin, Exchange admin), panelu administracyjnego obecnego serwera poczty.
  • Znajomość nazwy dzierżawy M365 (np. tenant.onmicrosoft.com).
  • Możliwość ustawienia forwardów na starym serwerze (na wybrane skrzynki).
  • Publiczny adres IP starego serwera (do SPF).

Krok 1. Autoryzuj domenę willi.com.pl w Microsoft 365

  1. Wejdź do Microsoft 365 Admin Center → Ustawienia → Domeny → Dodaj domenę.
  2. Wprowadź willi.com.pl.
  3. Potwierdź własność dodając wskazany rekord TXT w DNS (najczęściej w formie MS=msXXXXXXXX).
  4. Nie zmieniaj MX (zostaje na starym serwerze). W kreatorze pomiń/odznacz kroki dotyczące MX, jeśli są sugerowane.

Efekt: Microsoft 365 „zna” domenę, ale mail przychodzący nadal płynie zgodnie z obecnym MX.

Krok 2. Zaktualizuj rekord SPF (by legalnie wysyłać z M365)

W rekordzie SPF domeny dodaj Microsoft 365, czyli include:spf.protection.outlook.com.
Przykład bezpiecznej, hybrydowej polityki (dopasuj IP starego serwera):

willi.com.pl  TXT  v=spf1 ip4:XX.XX.XX.XX include:spf.protection.outlook.com -all
  • ip4:XX.XX.XX.XX – publiczny IP starego serwera poczty (jeśli on również wysyła e-maile).
  • include:spf.protection.outlook.com – autoryzuje wysyłkę z Exchange Online.
  • -all – odrzucaj źródła nieujęte w SPF.

Rekomendacje dodatkowe (opcjonalnie, ale warto): włącz DKIM dla willi.com.pl w M365 i skonfiguruj DMARC.

Krok 3. Utwórz użytkowników / skrzynki w M365

Dla osób, które mają działać już w chmurze:

  1. W Microsoft 365 Admin Center → Użytkownicy → Aktywni użytkownicy dodaj użytkownika i licencję Exchange Online.
  2. Nadaj mu adres w domenie willi.com.pl (np. [email protected]).
  3. Zwróć uwagę, że każda skrzynka w M365 ma też automatycznie alias @tenant.onmicrosoft.com (np. [email protected]). Ten alias będzie użyty do forwardu.

Dla osób, które jeszcze zostają na starym serwerze:

  • Możesz nic nie tworzyć w M365 albo (lepiej dla książki adresowej i reguł transportu) utworzyć Mail Contact z adresem zewnętrznym [email protected]. Dzięki temu katalog M365 „widzi” użytkownika i można wygodniej trasować.

Krok 4. Ustaw domenę willi.com.pl w Exchange Online jako Internal Relay

  1. Wejdź do Exchange admin center: https://admin.exchange.microsoft.com → Mail flow → Accepted domains.
  2. Otwórz willi.com.pl.
  3. Zmień typ domeny z Authoritative na Internal relay i zapisz.

Co to daje?
Jeśli wiadomość dla willi.com.pl trafi do M365, a skrzynka docelowa nie istnieje w chmurze, Exchange Online przekaże (relay) ją dalej – do Twojego serwera (przez skonfigurowany konektor).

Krok 5. (Zalecane) Skonfiguruj konektor Outbound z M365 do Twojego serwera

Aby Internal Relay mógł faktycznie wysłać dalej do starego serwera, utwórz konektor:

  1. Exchange admin center → Mail flow → Connectors → Add (+).
  2. From: Office 365 → To: Partner organization.
  3. Nazwij np. To-legacy-willi.
  4. Use the sender’s domain → wskaż willi.com.pl albo wybierz warunek „For email messages sent to these domains” i dodaj willi.com.pl.
  5. Smart host: podaj host Twojego serwera (np. mail.willi.com.pl) lub jego publiczny FQDN.
  6. Sposób uwierzytelnienia:
    • najprościej TLS opportunistic z walidacją certyfikatu (jeśli serwer ma poprawny cert),
    • alternatywnie MX na smart hoście i/lub ograniczenia po IP.
  7. Zakończ kreator testem.

Dzięki temu Exchange Online wie, gdzie dostarczyć pocztę dla skrzynek, których nie ma w chmurze (Internal Relay + Outbound Connector).

Krok 6. Na starym serwerze włącz forwardy dla przeniesionych użytkowników

Dla każdego użytkownika zmigrowanego do M365 ustaw przekierowanie:

Skąd wziąć alias @tenant.onmicrosoft.com?
W panelu M365 – po utworzeniu skrzynki jest on widoczny na liście aliasów/adresów (powstaje automatycznie).

Dzięki temu, gdy poczta wpadnie na stary serwer (bo MX został), wiadomości do migrowanych osób polecą dalej do Exchange Online.

Krok 7. Testy end-to-end

  1. SPF: sprawdź rekord TXT (np. nslookup -type=txt willi.com.pl). Upewnij się, że zawiera include:spf.protection.outlook.com i IP starego serwera.
  2. Dostawa do chmury: wyślij wiadomość na adres użytkownika, który ma forward do @tenant.onmicrosoft.com – sprawdź, czy trafia do skrzynki M365.
  3. Dostawa na stary serwer: wyślij wiadomość do użytkownika, który nie ma skrzynki w M365 – powinna zostać dostarczona lokalnie.
  4. Wysyłka z M365: z konta M365 wyślij wiadomość na zewnątrz – sprawdź nagłówki (powinny wskazywać protection.outlook.com).
  5. Wysyłka ze starego serwera: bez zmian – upewnij się, że SPF pokrywa ten serwer (brak „fail” w testach).

Najczęstsze pułapki i jak ich uniknąć

  • Zły include w SPF – prawidłowy to include:spf.protection.outlook.com, nie include:microsoft....
  • Brak konektora w M365 – Internal Relay nie zadziała skutecznie, jeśli M365 nie wie, dokąd przesłać pocztę (Krok 5).
  • Forward dla niewłaściwych kont – ustawiaj przekierowanie tylko dla użytkowników przeniesionych do M365, w przeciwnym razie stworzysz pętle.
  • TLS/certyfikat na starym serwerze – jeśli nie masz poprawnego certyfikatu, rozważ prostsze ustawienia lub aktualizację certu.
  • Autorytatywna domena w M365 – jeśli przez pomyłkę zostawisz Authoritative, M365 będzie odrzucać pocztę dla skrzynek nieistniejących w chmurze zamiast ją relayować.
  • Brak DKIM/DMARC – nie wymagane do działania, ale zdecydowanie poprawiają dostarczalność i reputację.

(Opcjonalnie) Wersja PowerShell dla administratorów

# Połącz z Exchange Online
Connect-ExchangeOnline

# Ustaw domenę jako Internal Relay
Set-AcceptedDomain -Identity "willi.com.pl" -DomainType InternalRelay

# Dodaj/zweryfikuj konektor outbound do starego serwera
New-OutboundConnector -Name "To-legacy-willi" `
 -ConnectorType Partner `
 -RecipientDomains "willi.com.pl" `
 -SmartHosts "mail.willi.com.pl" `
 -TlsSettings Opportunistic `
 -IsTransportRuleScoped $false

# (Przykład) Mail Contact dla użytkownika pozostającego na starym serwerze
New-MailContact -Name "Jan Nowak (legacy)" `
 -ExternalEmailAddress "[email protected]" `
 -FirstName "Jan" -LastName "Nowak"

W DNS rekord SPF aktualizujesz w panelu domeny – PowerShellem tego nie zrobisz.

Plan migracji „na raty” (propozycja)

  1. Tydzień 1: dodanie domeny w M365, SPF, Internal Relay, konektor; pilotaż 1–2 skrzynek.
  2. Tydzień 2: stopniowe przenoszenie kolejnych użytkowników (forwardy na starym serwerze).
  3. Tydzień 3+: po zakończeniu migracji wszystkich – przełączenie MX na M365 (jeśli chcesz) i wyłączenie relay/forwardów.

FAQ – krótkie odpowiedzi

  • Czy muszę od razu zmieniać MX?
    Nie. W tym scenariuszu MX zostaje na starym serwerze, dopóki chcesz.
  • Skąd wziąć adres @tenant.onmicrosoft.com?
    Z karty użytkownika w M365 – tworzy się automatycznie przy zakładaniu skrzynki.
  • Co z rekordami Autodiscover/Exchange?
    Dla użytkowników w M365 warto wskazać autodiscover na chmurę (CNAME do autodiscover.outlook.com), ale przy MX na stary serwer rób to ostrożnie – najlepiej po użytkownikach, którzy już są w M365.
  • Czy potrzebuję inbound connector do M365 (z legacy)?
    Nie jest wymagany w tej wersji przepływu, bo przychodzący ruch idzie do legacy (MX), a nie do M365. Outbound z M365 do legacy tak – żeby Internal Relay miał trasę.

Lista kontrolna (do odhaczenia)

  • Dodana domena willi.com.pl do M365, potwierdzona TXT
  • SPF: v=spf1 ip4:XX.XX.XX.XX include:spf.protection.outlook.com -all
  • Utworzone skrzynki w M365 dla migrowanych + weryfikacja aliasu @tenant.onmicrosoft.com
  • Accepted domain w M365 → Internal relay
  • Konektor Outbound z M365 do starego serwera (smart host)
  • Forwardy na starym serwerze → @tenant.onmicrosoft.com (tylko dla migrowanych)
  • Testy przychodzącej i wychodzącej poczty, nagłówki, SPF/DKIM/DMARC

Podsumowanie

W powyższej konfiguracji nie zmieniasz MX, a mimo to możesz płynnie przenosić skrzynki do Microsoft 365. Kluczem jest:

  • SPF z include:spf.protection.outlook.com,
  • Internal Relay w Exchange Online,
  • konektor z M365 do starego serwera,
  • forwardy z legacy do aliasów @tenant.onmicrosoft.com dla przeniesionych użytkowników.

Dodaj komentarz