Migracja poczty do Google Workspace lub Microsoft 365

Przeprowadzka do Google Workspace albo Microsoft 365 to w praktyce trzy osobne przeprowadzki: poczty przychodzącej (rekordy MX), poczty wychodzącej (SPF i DKIM) oraz zawartości istniejących skrzynek. Wiadomości giną na stykach — w godzinach, gdy zmieniają się rekordy MX, i w zapomnianych systemach, które wciąż wysyłają pocztę przez stary serwer. Ten poradnik prowadzi przez część DNS w kolejności, w jakiej będzie Ci potrzebna.

Nazwy menu podajemy tak, jak brzmią w angielskiej wersji konsoli administracyjnych.

Krok 1: zrób inwentaryzację

Zanim cokolwiek zmienisz w DNS, spisz:

• Wszystkie adresy, które odbierają pocztę: użytkowników, aliasy, grupy i listy dystrybucyjne, skrzynki współdzielone, reguły catch-all i przekierowania. Każdy z nich musi istnieć u nowego dostawcy przed zmianą MX. Dokumentacja Microsoftu wprost zaleca dodanie użytkowników przed aktualizacją rekordu MX; wiadomość na adres, którego u nowego dostawcy nie ma, zostanie odbita.
• Wszystkie systemy, które wysyłają pocztę z Twojej domeny: sklep internetowy, CRM, fakturowanie, helpdesk, narzędzie do newsletterów, skanery, skrypty monitorujące. Te, które korzystają z serwera SMTP starego dostawcy, przestaną działać po jego wyłączeniu i będą wymagały nowych ustawień.
• Obecne rekordy DNS: MX, SPF, selektory DKIM (selektor._domainkey), _dmarc, _mta-sts i rekordy weryfikacyjne. Zachowaj kopię strefy — przyda się do porównania.
• Kto może zmieniać DNS w dniu przełączenia.

Krok 2: z wyprzedzeniem obniż TTL

Resolwery przechowują rekord w pamięci podręcznej tak długo, jak wskazuje jego TTL. Jeśli Twoje rekordy MX mają TTL 86400 sekund (doba), część nadawców będzie korzystać ze starych serwerów jeszcze do doby po zmianie.

Co najmniej jeden pełny TTL przed przełączeniem — zwykle dzień wcześniej — obniż TTL rekordów MX i SPF do około 300 sekund. Aktualna wartość jest w drugiej kolumnie:

$ dig +noall +answer MX example.com
example.com.  86400  IN  MX  10  mx.old-provider.example.

Samych rekordów nie zmieniaj, dopóki nie minie stary TTL.

Krok 3: przygotuj nowego dostawcę

1. Dodaj i zweryfikuj domenę. Obaj dostawcy podają rekord TXT, który potwierdza, że domena należy do Ciebie. Nie wpływa on na przepływ poczty.
2. Utwórz użytkowników, grupy i aliasy z inwentaryzacji.
3. Zacznij kopiować istniejącą pocztę. Google udostępnia w konsoli administracyjnej usługę migracji danych (data migration service); Microsoft opisuje migracje z Exchange Server, z systemów IMAP i z Google Workspace. Większość poczty skopiuj przed przełączeniem, a po nim wykonaj ostatnią synchronizację.

Krok 4: przełącz rekordy MX

Google Workspace

Obecna konfiguracja MX Google to jeden rekord:

example.com.  3600  IN  MX  1  smtp.google.com.

Domeny skonfigurowane przed 2023 rokiem mogą używać starszych wartości — kilku rekordów, których nazwy zaczynają się od aspmx. Google nadal je obsługuje, więc działającej konfiguracji nie trzeba zmieniać. Gdy rekord jest już opublikowany, kliknij Activate Gmail przy domenie w konsoli administracyjnej (Account > Domains > Manage domains). Według Google rozpoznanie nowych rekordów MX może potrwać do 72 godzin.

Microsoft 365

Nie składaj wartości samodzielnie — skopiuj ją z centrum administracyjnego Microsoft 365 (Settings > Domains, wybierz domenę, potem DNS records). W wielu domenach ma ona taką postać, gdzie example-com to tzw. MX token, czyli nazwa domeny z kropkami zamienionymi na łączniki:

example.com.  3600  IN  MX  0  example-com.mail.protection.outlook.com.

Domeny z włączonym DNSSEC w Exchange Online używają zamiast tego nazwy w strefie mx.microsoft, w postaci <MX token>.<subdomain>.mx.microsoft. Właściwa jest zawsze wartość, którą centrum administracyjne pokazuje dla Twojej domeny. Microsoft zaleca najwyższy priorytet (zwykle 0) i zaznacza, że Exchange Online obsługuje tylko TTL krótsze niż sześć godzin.

Microsoft 365 korzysta też z rekordu CNAME autodiscover wskazującego na autodiscover.outlook.com — dzięki niemu Outlook sam znajduje skrzynkę.

Zastąp stare rekordy, nie dokładaj nowych obok

Google każe usunąć pozostałe rekordy MX. Microsoft dopuszcza też pozostawienie ich z niższym priorytetem, ale wtedy nadawcy dostarczają pocztę do starego systemu za każdym razem, gdy nowy jest nieosiągalny — i to są właśnie wiadomości, których potem zabraknie. Przy równych priorytetach nadawcy wybierają serwer losowo, więc poczta rozkłada się na oba systemy.

Usuń stare rekordy i sprawdź wynik w wyszukiwaniu MX, które ostrzega, gdy rekordy wskazują serwery różnych dostawców.

Krok 5: SPF — jeden rekord dla obu systemów

W trakcie migracji pocztę wysyłają i stary, i nowy system, więc SPF musi autoryzować oba. Zostaw jeden rekord SPF i dopisz do niego include nowego dostawcy:

; Google Workspace
example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.old-provider.example ~all"

; Microsoft 365
example.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:spf.old-provider.example -all"

Google zaleca zakończenie ~all, a przykłady Microsoftu kończą się -all. Ważniejsze jest to, żeby istniał tylko jeden rekord v=spf1 — Microsoft wprost zastrzega, by nie tworzyć drugiego. Przy dwóch rekordach każde sprawdzenie SPF kończy się wynikiem permerror.

Każdy include kosztuje zapytania DNS, a SPF dopuszcza ich dziesięć. Po każdej zmianie uruchom sprawdzanie SPF; jeśli zbliżasz się do limitu, zajrzyj do poradnika SPF: za dużo zapytań DNS.

Krok 6: DKIM w konsoli każdego dostawcy

To zwykle DKIM sprawia, że DMARC przechodzi, więc jeśli możesz, skonfiguruj go, zanim przeniesiesz pocztę wychodzącą.

Google Workspace. W konsoli administracyjnej przejdź do Apps > Google Workspace > Gmail > Authenticate email. Po włączeniu Gmaila może być konieczne odczekanie 24–72 godzin, zanim da się wygenerować klucz. Wybierz klucz 2048-bitowy, jeśli Twój dostawca DNS go obsługuje, zostaw domyślny selektor google i opublikuj pokazany przez Google rekord TXT pod nazwą google._domainkey.example.com. Dopiero potem kliknij Start authentication. Według Google od dodania rekordu może minąć do 48 godzin, zanim uwierzytelnianie DKIM zacznie działać.

Microsoft 365. Według dokumentacji Microsoftu poczta z domen niestandardowych nie jest podpisywana DKIM Twoją domeną, dopóki tego nie skonfigurujesz. W portalu Microsoft Defender otwórz Email & collaboration > Policies & rules > Threat policies > Email authentication settings, kartę DKIM i wybierz domenę. Portal pokaże dwa rekordy CNAME do opublikowania, w takiej postaci:

selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.<initial>.<partition>-v1.dkim.mail.microsoft.
selector2._domainkey.example.com.  CNAME  selector2-example-com._domainkey.<initial>.<partition>-v1.dkim.mail.microsoft.

<initial> to pierwsza część Twojej domeny onmicrosoft.com, a <partition> — pojedynczy znak przydzielany przez Microsoft; dokładne wartości skopiuj z portalu. (Domeny dodane przed majem 2025 roku zachowują starszą postać, kończącą się na <initial>.onmicrosoft.com.) Gdy Microsoft wykryje rekordy, włącz Sign messages for this domain with DKIM signatures.

Rekordy DKIM starego dostawcy zostaw na miejscu: selektory mają różne nazwy, więc nie wchodzą sobie w drogę, a pocztę ze starego systemu da się weryfikować, dopóki ten system nie przestanie wysyłać. Każdy selektor sprawdź w sprawdzaniu DKIM — google dla Google, selector1 i selector2 dla Microsoftu; narzędzie potrzebuje nazwy selektora. Więcej w poradniku Jak działa DKIM.

Krok 7: DMARC

Jeśli domena ma już rekord DMARC, nie zmieniaj go w trakcie migracji, ale wiedz, co robi:

• Przy p=none nic nie jest blokowane; raporty zbiorcze pokażą, czy serwery nowego dostawcy przechodzą weryfikację.
• Przy p=quarantine lub p=reject poczta od nowego dostawcy przejdzie DMARC tylko wtedy, gdy SPF albo DKIM da wynik pass i będzie zgodny z Twoją domeną (alignment). Opublikuj include w SPF i włącz DKIM, zanim użytkownicy zaczną wysyłać z nowego systemu.

Jeśli nie masz jeszcze DMARC, najpierw dokończ migrację, a potem skorzystaj z poradnika Jak skonfigurować DMARC.

Przełączenie i okres przejściowy

W dniu przełączenia:

1. Upewnij się, że każda skrzynka, alias i grupa istnieje u nowego dostawcy.
2. Zastąp rekordy MX.
3. Sprawdź je w wyszukiwaniu MX i w publicznym resolwerze (dig @1.1.1.1 MX example.com).
4. Wyślij wiadomości testowe z zewnętrznego konta na kilka adresów.

Przez kolejne dni poczta może jeszcze trafiać do starego systemu: od nadawców, których resolwery pamiętają stare rekordy, oraz w postaci wiadomości czekających w kolejce na ponowną próbę — według RFC 5321 nadawca powinien zwykle próbować co najmniej 4–5 dni, zanim się podda. Utrzymaj stare skrzynki przynajmniej tak długo i wykonaj ostatnie kopiowanie (albo ustaw przekierowanie), żeby nic nie zostało po drodze.

Przenoszenie użytkowników partiami

Jeśli przenosisz ludzi grupami, a nie wszystkich naraz, oba systemy muszą jednocześnie przyjmować pocztę dla domeny i przekazywać dalej wiadomości do osób, których jeszcze nie przeniesiono:

• Google Workspace nazywa to split delivery: Gmail dostarcza pocztę swoim użytkownikom, a resztę kieruje na drugi serwer. Google zaleca, by najpierw wypróbować to na małej grupie.
• Microsoft 365 opisuje pilotaż, w którym MX zostaje u starego dostawcy, a ten przekierowuje pocztę użytkowników pilotażowych do Microsoft 365; domena ma w centrum administracyjnym Exchange ustawiony typ Internal Relay, a łącznik (connector) prowadzi z powrotem do dotychczasowego serwera. Przy lokalnym Exchange Server tę rolę pełni wdrożenie hybrydowe.

Sprawdź, czy wszystko działa

Zaraz po przełączeniu i ponownie po kilku dniach:

1. Wyszukiwanie MX — tylko serwery nowego dostawcy, wszystkie z poprawnymi adresami.
2. Sprawdzanie SPF — jeden rekord, poniżej dziesięciu zapytań.
3. Sprawdzanie DKIM — poprawny klucz pod każdym nowym selektorem.
4. Sprawdzanie DMARC — polityka, której się spodziewasz.
5. Prawdziwa wiadomość — wyślij ją z nowego systemu na zewnętrzną skrzynkę i wklej nagłówki do analizatora nagłówków e-mail. Szukasz spf=pass, dkim=pass dla Twojej domeny i dmarc=pass.

Sprzątanie po migracji

Gdy stary system od dłuższego czasu nic nie odbiera i nic przez niego nie wychodzi:

• usuń stary include z SPF i rekordy DKIM starego dostawcy;
• usuń stary serwer MX z polityki MTA-STS;
• zmień ustawienia urządzeń i aplikacji, które wciąż wskazują stary serwer SMTP;
• przywróć wyższe TTL, na przykład 3600;
• dopiero wtedy zrezygnuj ze starej usługi.