Zmiana hostingu i transfer domeny bez dnia przerwy w poczcie

Klientka miała jedną skrzynkę kontakt@ na własnej domenie i przez nią przychodziło wszystko: zapytania od klientów, rezerwacje konsultacji, potwierdzenia płatności. Strona miała przejść na nasz serwer, poczta razem z nią, a domena do innego rejestratora. Jedno przełączenie w złej kolejności i maile od klientów lądują w próżni, a nikt się o tym nie dowiaduje.

W tym wpisie opisujemy, jak wyglądała zmiana hostingu bez utraty maili w praktyce: w jakiej kolejności robiliśmy kroki, gdzie są pułapki i jak sprawdzić, że nic nie zginęło. Klientka przez całą przeprowadzkę pracowała normalnie i nie zauważyła ani jednego dnia przerwy.

Punkt wyjścia: trzy rzeczy w trzech różnych miejscach

Klientka prowadzi jednoosobową działalność usługową. Strona i skrzynka kontakt@ stały u małego lokalnego dostawcy, a domena była zarejestrowana przez pośrednika u jeszcze innego rejestratora. Typowy obraz po kilku latach: każdy element u kogoś innego i nikt nie ma pełnej listy dostępów.

Przy inwentaryzacji wyszły trzy rzeczy, których klientka nie była świadoma:

• Abonentem domeny nie była ona. W rejestrze figurowała inna firma, przez którą kiedyś zamawiała stronę. Formalnie domena z nazwą jej marki nie należała do niej.
• Hasła do starego hostingu leżały jawnie na czacie grupowym. Każdy uczestnik rozmowy miał dostęp do skrzynki i serwera.
• Poczta była dla niej krytyczna. Nie było drugiego kanału, przez który klienci by się z nią kontaktowali. Utrata maili z jednego dnia to utracone zapisy.

Stawka była więc prosta: strona może mieć kilka minut gorszego działania, poczta nie może mieć ani jednej dziury.

Gdzie zwykle giną maile przy przeprowadzce

Zanim cokolwiek przełączyliśmy, rozpisaliśmy sobie, co może pójść źle. Większość historii „po zmianie hostingu nie dochodzą maile” sprowadza się do jednego z czterech scenariuszy:

1. Transfer domeny jako pierwszy krok. Ktoś przenosi domenę do nowego rejestratora, a razem z nią zmieniają się serwery nazw. Nowa strefa DNS nie ma rekordu MX albo ma domyślny, a skrzynki na nowym serwerze jeszcze nie ma. Maile odbijają się albo trafiają donikąd.
2. MX przełączony przed założeniem skrzynki. Nowy serwer przyjmuje pocztę dla domeny, ale nie ma adresata. Nadawca dostaje odbitkę, klientka nie dostaje nic.
3. Poczta skopiowana raz. DNS nie przełącza się w jednej sekundzie na całym świecie. Przez pewien czas część serwerów nadawców dalej dostarcza na stary adres. Jednorazowa kopia zrobiona rano nie zawiera maili, które wpadły na stary serwer po południu.
4. Brak SPF, DKIM i DMARC na nowym serwerze. Odbiór działa, ale wysyłka z nowego serwera ląduje w spamie u klientów, bo stare rekordy wskazują stary serwer.

Moment odkrycia: to są dwie osobne przeprowadzki

Z tego wynika cała kolejność. Najpierw przenosimy to, co działa (strona i poczta), przełączając serwery nazw. Dopiero gdy wszystko chodzi z nowego serwera i jest sprawdzone, robimy transfer domeny – osobno, na końcu, jako operację czysto formalną. Klienci zwykle robią to odwrotnie, bo transfer wydaje się „najważniejszy”, i właśnie wtedy tracą maile w dniu przeprowadzki.

Kolejność, która zadziałała – krok po kroku

1. Kopia wszystkiego, zanim cokolwiek ruszymy

Najpierw zabezpieczyliśmy starą stronę: wszystkie podstrony, obrazki i opinie klientów, plus pełną kopię HTML. Starą wersję zostawiliśmy dodatkowo pod subdomeną (np. stara.TWOJA_DOMENA.pl), żeby w razie wątpliwości dało się porównać treści jeden do jednego. Usunęliśmy ją dopiero kilka dni po przeprowadzce, za zgodą klientki i z pełnym backupem plików i bazy.

2. Skrzynka na nowym serwerze, zanim przełączymy MX

Na nowym serwerze założyliśmy skrzynkę kontakt@ o tym samym adresie. Dopiero gdy istniała i dało się na nią zalogować, przełączyliśmy serwery nazw domeny na nowy hosting. Od tej chwili strona szła z nowego serwera z certyfikatem SSL, a rekord MX wskazywał skrzynkę, która już czekała.

3. Poczta przeniesiona w kilku przebiegach

To jest serce całej operacji. Na hostingu współdzielonym nie było narzędzia imapsync, które zwykle się do tego stosuje. Instalowanie go z zależnościami trwałoby dłużej niż sama migracja, więc użyliśmy własnego skryptu, który łączy się po IMAP do obu serwerów i przepisuje maile folder po folderze.

Skrypt ma cztery zasady wbudowane na stałe:

• Źródła nie ruszamy. Tylko odczyt: zero kasowania, zero zmiany flag po stronie starego serwera. Jeśli coś pójdzie źle, oryginał stoi nietknięty.
• Drugie uruchomienie nie robi duplikatów. Przed kopiowaniem skrypt czyta, co już jest na nowym serwerze, i pomija te maile.
• Flagi i daty zostają. Przeczytane zostają przeczytane, a każdy mail ma swoją pierwotną datę, nie datę migracji.
• Na końcu liczy. Liczba maili w każdym folderze źródła i celu musi się zgadzać, inaczej wynik to błąd.

Jedna pułapka wyszła przy okazji mapowania folderów: stary serwer trzymał foldery pod przedrostkiem INBOX. (np. INBOX.Sent), a nowy bez niego (Sent). Bez mapy wysłane maile wylądowałyby w nowym, dziwnie nazwanym folderze obok właściwego.

mapa folderów (stary serwer -> nowy serwer)
INBOX         -> INBOX
INBOX.Sent    -> Sent
INBOX.Drafts  -> Drafts
INBOX.Trash   -> Trash
INBOX.Spam    -> Junk

Druga pułapka jest mniej oczywista i poznaliśmy ją przy wcześniejszej migracji u innego klienta. Jeśli kluczem „ten mail już jest” jest sam nagłówek Message-ID, skrypt potrafi pominąć legalne kopie: ten sam list dostarczony dwa razy ma ten sam Message-ID. Wtedy cel ma o jeden czy dwa maile mniej niż źródło, a żaden błąd się nie pojawia. Dlatego kluczem jest para Message-ID i data dostarczenia, liczona razem z liczbą wystąpień.

Pierwszy przebieg poszedł przed przełączeniem DNS, kolejne w trakcie i po nim. Ostatni, kontrolny, zrobiliśmy wieczorem następnego dnia, żeby złapać maile, które w czasie propagacji mogły jeszcze trafić na stary serwer. Wynik: 28 z 28 wiadomości na nowym serwerze, a na starym nie pojawiło się nic nowego.

4. SPF, DKIM i DMARC na nowy serwer, potem test realnym mailem

Rekordy uwierzytelniające pocztę ustawiliśmy pod nowy serwer od razu przy przełączeniu. Wysyłkę sprawdziliśmy w serwisie mail-tester (wynik 10/10), a odbiór realną wiadomością z zewnątrz: potwierdzenie z systemu płatności dotarło do nowej skrzynki. Strona WordPress przez pierwsze dni wysłała kilkanaście maili (dokładnie 19) bez jednego błędu.

Do szybkiego podglądu rekordów wystarczy kilka zapytań:

dig +short NS TWOJA_DOMENA.pl
dig +short MX TWOJA_DOMENA.pl
dig +short TXT TWOJA_DOMENA.pl          # tu jest SPF (v=spf1 ...)
dig +short TXT _dmarc.TWOJA_DOMENA.pl   # tu jest DMARC (v=DMARC1 ...)

Rekord SPF ma być dokładnie jeden. Dwa rekordy SPF obok siebie to częsty skutek przeprowadzki (stary zostaje, nowy dochodzi) i dla serwerów odbiorców oznaczają błąd, a nie sumę.

5. Klientka pracuje w jednym okienku, jak wcześniej

Klientka nie chciała uczyć się nowego programu pocztowego. Ustawiliśmy więc przekierowanie kontakt@ na jej prywatną skrzynkę Gmail, a ona sama, według krótkiej instrukcji, dodała w Gmailu funkcję „Wyślij jako”. Odpowiada z adresu firmowego, wysyłka idzie przez nowy serwer, a ona dalej ma wszystko w jednym okienku.

Jeśli nie chcesz przechodzić przez to sam, właśnie tak wygląda u nas hosting premium: strona, poczta i domena w jednym miejscu, a przeprowadzkę robimy w kolejności, w której klienci nie tracą maili.

6. Transfer domeny na końcu i osobno

Gdy strona i poczta działały z nowego serwera, przyszła kolej na domenę. Klientka poprosiła starego rejestratora o kod AuthInfo (dla domen .pl jest ważny 30 dni), a my zleciliśmy transfer na nasze konto. Przy okazji abonentem domeny została wreszcie ona sama, a nie firma pośrednika.

Dwie rzeczy, które warto wiedzieć przed transferem domeny .pl:

• Rejestr wysyła mail z prośbą o potwierdzenie na adres abonenta zapisany u STAREGO rejestratora. Tego adresu nie widać w publicznym whois. Jeśli domenę zakładał pośrednik, mail może pójść do niego – trzeba to ustalić wcześniej.
• Rejestr nie lubi częstych zapytań. Sprawdzanie whois co dwie minuty kończyło się odpowiedzią o błędzie połączenia z bazą. Co pięć minut działało bez problemu.

Przed transferem i po nim zrobiliśmy skryptem „zdjęcie” stanu domeny: rejestrator, serwery nazw, rekordy A i www, MX, SPF, DMARC i odpowiedź strony. Porównanie wyszło jednoznacznie: zmienił się tylko rejestrator, wszystko inne zostało bez zmian. Od zlecenia do zakończenia transferu minęło około półtorej godziny.

# zdjęcie stanu przed i po transferze - porównujesz dwa pliki
for r in NS MX TXT; do echo "$r: $(dig +short $r TWOJA_DOMENA.pl | sort | tr '\n' ' ')"; done
echo "DMARC: $(dig +short TXT _dmarc.TWOJA_DOMENA.pl)"
echo "HTTP: $(curl -s -o /dev/null -w '%{http_code}' https://TWOJA_DOMENA.pl/)"

7. Kopie i dostępy od pierwszego dnia

Kopie zapasowe strony do zewnętrznej chmury ruszyły od pierwszego dnia na nowym serwerze. Dostępy przenieśliśmy do zaszyfrowanego sejfu w naszym systemie, a klientkę poprosiliśmy o skasowanie wiadomości z hasłami z czatu. Domena i hosting mają terminy odnowienia zapisane w kalendarzu usług, więc nic nie wygaśnie przypadkiem.

Efekt: przeprowadzka, której klientka nie odczuła

• Zero dnia bez poczty i zero zgubionych wiadomości – 28 z 28 maili przeniesionych, a nowe wiadomości po przełączeniu trafiały już do nowej skrzynki.
• Wysyłka z dobrą reputacją – mail-tester 10/10, maile ze strony wychodzą bez błędów.
• Transfer domeny bez zmiany DNS – porównanie przed i po pokazało zmianę wyłącznie rejestratora.
• Domena wreszcie na właścicielkę, a nie na pośrednika.
• Hasła poza czatem i jedna lista dostępów zamiast trzech.

Jak sprawdzić u siebie przed zmianą hostingu

1. Sprawdź, kto jest abonentem Twojej domeny. Jeśli nie Ty, załatw to przy transferze.
2. Ustal, gdzie dziś stoi strefa DNS (dig +short NS) i gdzie wskazuje MX. To często trzy różne firmy.
3. Załóż skrzynki na nowym serwerze, zanim przełączysz MX.
4. Przenoś pocztę narzędziem, które nie robi duplikatów i porównuje liczby, w kilku przebiegach wokół przełączenia.
5. Ustaw SPF, DKIM i DMARC pod nowy serwer i sprawdź, że rekord SPF jest jeden.
6. Wyślij realny mail z zewnątrz na nową skrzynkę i realny mail ze skrzynki na zewnątrz.
7. Transfer domeny zrób na końcu, z porównaniem stanu DNS przed i po.

Czego nauczyła nas ta historia

Przeprowadzka poczty to nie jest jedno kliknięcie, tylko kilka kroków, z których każdy ma swoją kolejność. Najpierw działa nowe miejsce, potem przełączamy ruch, potem dokładamy to, co wpadło po drodze, a formalności (transfer domeny) na samym końcu. Każdy etap kończymy dowodem: liczbą maili, wynikiem testu, porównaniem rekordów. Dzięki temu klient nie musi nam wierzyć na słowo, że „wszystko przeszło”.

FAQ

Czy zmiana hostingu zawsze oznacza przerwę w poczcie?

Nie. Przerwa pojawia się, gdy MX zostaje przełączony na serwer, na którym nie ma jeszcze skrzynki, albo gdy poczta jest kopiowana tylko raz. Przy skrzynce założonej wcześniej i migracji w kilku przebiegach przerwy nie ma.

Czy transfer domeny zmienia rekordy DNS?

Sam transfer rejestratora nie musi niczego zmieniać. Jeśli strefa DNS jest już u nowego hostingu i serwery nazw wskazują jego serwery, transfer zmienia tylko to, kto prowadzi rejestrację domeny.

Jak długo trwa transfer domeny .pl?

U nas od zlecenia do zakończenia minęło około półtorej godziny. Czas zależy głównie od tego, jak szybko abonent potwierdzi transfer w mailu z rejestru i czy kod AuthInfo jest aktualny (ważny 30 dni).

Czy maile, które przyszły w trakcie przeprowadzki, przepadną?

Nie, jeśli stara skrzynka działa do końca, a poczta jest przenoszona kilka razy. Ostatni przebieg warto zrobić po pełnej propagacji DNS, zwykle następnego dnia, żeby zebrać maile, które jeszcze trafiły na stary serwer.

Czy mogę dalej odpisywać z Gmaila po zmianie hostingu?

Tak. Przekierowanie skrzynki firmowej na Gmail plus funkcja „Wyślij jako” z danymi serwera pocztowego pozwalają odpowiadać z adresu firmowego bez zmiany nawyków. Ważne, żeby wysyłka szła przez serwer z poprawnym SPF i DKIM.

Po co zostawiać starą stronę pod subdomeną?

Żeby przez kilka dni móc porównać treści i niczego nie zgubić przy przenoszeniu. Gdy klient potwierdzi, że nowa wersja jest kompletna, starą kopię usuwamy, zostawiając pełny backup.