Poczta i strona to dwa osobne przełączenia: MX decyduje o poczcie, rekordy A i AAAA o stronie. Dzięki temu pocztę można przenieść przed końcem abonamentu u starego dostawcy, a stronę później. Stare wiadomości przenosi import IMAP serwer–serwer, uruchomiony przed zmianą MX i powtórzony po niej. Najwięcej pracy wymagają rzeczy, których nie widać w panelu: konta używane przez stronę, adresy, które istnieją tylko na papierze, i rekord SPF w okresie przejściowym.
| Element | Stan po przenosinach |
|---|---|
| Skrzynki | 3 skrzynki i 1 alias, który wcześniej istniał tylko z nazwy |
| Dane | ok. 3,1 GB poczty |
| Wiadomości po imporcie | 12 067, 3 349 i 416 w trzech skrzynkach |
| Od zmiany MX do pierwszego maila w nowej skrzynce | ok. 2 minuty |
| Wysyłka z nowego serwera | SPF, DKIM i DMARC: pass |
| Programy pocztowe | Outlook 2016 i Outlook z Microsoft 365 na dwóch komputerach, pozostałe skrzynki przez przeglądarkę |
Zanim cokolwiek przełączysz: co naprawdę jest na starym serwerze
Lista skrzynek od właściciela firmy to punkt wyjścia, nie inwentaryzacja. W panelu starego dostawcy sprawdziliśmy cztery rzeczy, z których każda zmieniła plan.
- Rzeczywiste użycie, a nie rezerwacja. Pulpit panelu pokazywał 66 GB, ale to była suma limitów skrzynek. Poczty było ok. 3,1 GB, więc wystarczył najmniejszy pakiet z trzema skrzynkami.
- Konta techniczne. Czwarte konto, o którym nikt nie wspomniał, służyło najpewniej do wysyłki powiadomień z formularza strony. Po wyłączeniu starej poczty formularz przestałby wysyłać, więc to konto trzeba uwzględnić w planie przenosin strony.
- Adresy, które istnieją tylko z nazwy. Adres do zamówień, który firma uważała za „chyba nieaktywny”, nie istniał w domenie firmy. Była tylko skrzynka o tej nazwie w technicznej domenie serwera, pusta. Maile wysyłane na ten adres najpewniej nie dochodziły. W nowym hostingu założyliśmy go jako alias do głównej skrzynki, bez zajmowania miejsca na kolejną skrzynkę.
- IMAP czy POP3. Przy POP3 program zwykle pobiera wiadomości i usuwa je z serwera, chyba że ma włączone zostawianie kopii, a wysłane i foldery lokalne są wyłącznie na komputerze. Import z serwera tego nie zabierze. Główna skrzynka miała na serwerze prawie 10 tys. wysłanych wiadomości, co wskazywało na IMAP. Potwierdziło to dopiero sprawdzenie typu konta w Outlooku.
Do tego data końca opłaconego okresu. Poczta była rozliczana miesięcznie, więc przełączenie musiało nastąpić przed kolejnym okresem rozliczeniowym. Kopia zapasowa u starego dostawcy okazała się płatnym dodatkiem, a nie istniejącą kopią, dlatego oryginały zostawiliśmy na starym serwerze do końca abonamentu.
Kolejność: poczta i strona osobno, import przed zmianą MX
Strona firmy była u innego dostawcy niż poczta, a dostęp do niej miał przyjść później. Rozdzieliliśmy więc przenosiny: najpierw poczta, strona dopiero po otrzymaniu dostępu. Na nowym serwerze DNS strefa przez cały ten czas kierowała stronę na stary serwer.
- w nowym hostingu założone skrzynki i uruchomiony import IMAP z każdej starej skrzynki
- strefa na nowych serwerach DNS przygotowana tak, żeby nic nie zmieniło się dla odbiorców: strona na starym serwerze, MX tymczasowo na starej poczcie
- zmiana serwerów DNS domeny, potem przełączenie MX na nową pocztę
- następnego dnia drugi import z każdej skrzynki: dociąga wiadomości, które w okresie przejściowym trafiły jeszcze do starych skrzynek
Import przy pierwszym przebiegu odrzucił jedną skrzynkę z powodu błędnych danych logowania, a druga próba przeszła. Warto więc po każdym imporcie sprawdzić jego status przy każdej skrzynce, a nie tylko przy pierwszej.
Serwery DNS i DNSSEC: dlaczego nie wystarczyła zmiana samych rekordów
Plan zakładał, że DNS zostanie u rejestratora, a zmienimy tylko rekordy MX, SPF i DKIM. Instrukcja aktywacji poczty w dhosting opisuje dwa warianty: przeniesienie delegacji domeny na ns1 i ns2.dhosting.pl albo pozostawienie DNS u dotychczasowego operatora i ustawienie u niego rekordów MX (mx-1 i mx-2.dpoczta.pl) oraz SPF dhosting, a dopiero potem aktywację poczty w panelu.
W naszym przypadku aktywację uruchamialiśmy, gdy domena była zaparkowana w dhosting, a MX u rejestratora wskazywał jeszcze starą pocztę, żeby nowe maile nie trafiały do nowych skrzynek przed importem. W tej konfiguracji panel odrzucał aktywację z informacją o delegacji domeny poza dhosting.pl. Artykuł o parkowaniu domeny mówi, że ustawienia DNS zaparkowanej domeny są nieaktywne do czasu zmiany delegacji. Przenieśliśmy więc całą strefę, z MX tymczasowo na starej poczcie. Kolejności z instrukcji, czyli najpierw MX i SPF u rejestratora, a potem aktywacja, nie sprawdzaliśmy. Przy niej nowe maile trafiają do nowych skrzynek od chwili zmiany MX, więc skrzynki i import trzeba przygotować wcześniej.
Domena miała włączony DNSSEC. W panelu nazwa.pl nie było osobnego wyłącznika: DNSSEC wyłączył się sam przy przejściu na zewnętrzne serwery DNS. Zalecana kolejność według RFC 6781 to usunięcie rekordu DS, odczekanie jego czasu życia i dopiero potem zmiana serwerów nazw. Rekord DS w rejestrze .pl ma czas życia 24 godziny. Panel nie pozwalał rozdzielić tych kroków, więc resolver, który zapamiętał DS, mógł przez ten czas odrzucać odpowiedzi nowej, niepodpisanej strefy. Poczta wysłana w takim oknie zwykle przychodzi z opóźnieniem, bo serwery nadawców ponawiają doręczenie. Nowa strefa była przygotowana przed zmianą, z tymi samymi adresami strony i poczty co dotąd, żeby odbiorcy niczego nie zauważyli. Rejestr pokazał nowe serwery nazw i usunięty DS po kilku minutach, a publiczne resolvery, które sprawdziliśmy, nie zgłaszały błędów. Jeden z dwóch serwerów nazw dhosting synchronizował strefę ok. 20 minut, drugi od razu.
Pułapki panelu dhosting
- Okres próbny. Przed opłaceniem pakietu skrzynki da się zakładać tylko w domenach współdzielonych dostawcy, z limitem 50 maili na dobę. Skrzynki we własnej domenie powstają dopiero po zapłacie, więc opłata musi wyprzedzić dzień przenosin.
- Poczta działa dopiero po zmianie MX. Po przeniesieniu serwerów DNS panel pokazywał usługę poczty jako aktywną, ale mail wysłany z jednej nowej skrzynki do drugiej nie dotarł. Helpdesk potwierdził, że dhosting obsługuje pocztę domeny, gdy MX wskazuje na ich serwery. Etykieta „Nieaktywna usługa poczty” przy skrzynkach została jeszcze następnego dnia, mimo że odbiór działał. Nie warto na nią czekać.
- Przycisk przekierowania poczty nadpisuje SPF. Akcja w strefie DNS „Przekierowanie poczty → Do dhosting.pl” ustawia MX, ale zamienia też rekord SPF na wersję domyślną z
-all. Przy takim rekordzie wiadomości z adresem nadawcy w domenie firmy wysyłane z innych serwerów, np. powiadomienia formularza przez skrzynkę na starym serwerze, nie przechodzą sprawdzenia SPF. Czy serwer odbiorcy je odrzuci, przeniesie do spamu, czy przyjmie, zależy od niego i od polityki DMARC domeny. Po kliknięciu trzeba od razu przywrócić własny rekord.
SPF, DKIM i DMARC w okresie przejściowym
W dniu przenosin z domeny wysyłały trzy miejsca: nowa poczta, stara poczta, z której jeszcze korzystały programy pocztowe, i serwer strony z formularzem. SPF sprawdza adres nadawcy w kopercie wiadomości (MAIL FROM), a nie adres widoczny w polu „Od”, więc powinien obejmować każdy serwer, który wysyła z kopertą w domenie firmy. Dlatego rekord przejściowy zawierał nowego dostawcę oraz adresy serwera strony i starej poczty, z końcówką ~all. Przy ~all wiadomość spoza listy dostaje wynik softfail, który sam zwykle nie powoduje odrzucenia, a co najwyżej obniża ocenę wiadomości. Odrzucenie grozi przy -all albo przy ścisłej polityce DMARC.
Formularz strony to osobny przypadek. Jeśli wysyła przez SMTP skrzynki w domenie firmy, podlega SPF tej domeny. Jeśli wysyła funkcją mail() serwera, koperta często ma techniczny adres hostingu i wtedy SPF domeny w ogóle nie jest sprawdzany, a wiadomość nie przechodzi DMARC, bo nic nie zgadza się z domeną w polu „Od”. Dlatego formularz najlepiej przestawić na SMTP skrzynki w domenie.
DKIM i DMARC dodał dhosting w nowej strefie, DMARC z polityką p=none, czyli bez żądania szczególnego traktowania wiadomości; raporty przychodzą, jeśli rekord ma tag rua, a ten od dhosting go miał. Adres starego serwera poczty zostaje w SPF, dopóki formularz strony nie wysyła przez nową pocztę, i jest usuwany zaraz potem. Wiadomość testowa z nowej skrzynki do Gmaila przeszła SPF, DKIM i DMARC. Uwierzytelnienie nie gwarantuje, że każdy odbiorca umieści wiadomość w odebranych, ale usuwa jedną z częstych przyczyn trafiania do spamu.
Outlook i poczta w przeglądarce
Na obu komputerach Outlook miał jedno konto IMAP. Zamiast zakładać nowe, zmieniliśmy w nim serwery na nowe (IMAP 993 z SSL, SMTP 587 ze STARTTLS). Konto, foldery lokalne i pliki archiwum zostały na miejscu, a pliku danych nie kasowaliśmy. W Outlooku 2016 zmiana jest w ustawieniach konta. W Outlooku z Microsoft 365 przycisk „Zmień…” otwierał tylko nazwę konta, a serwery były dostępne w ścieżce Plik → Informacje → Ustawienia konta → Ustawienia serwera.
Po zmianie test konta przeszedł od razu, a w skrzynce pojawił się mail testowy, który był już tylko na nowym serwerze. To potwierdziło, że Outlook czyta nowy serwer. Pierwsza synchronizacja folderu wysłanych, ok. 8 tys. wiadomości, trwała dłużej i nie blokowała pracy. Osoby, które czytają pocztę w przeglądarce, dostały tylko nowy adres poczty w przeglądarce i same zmieniły hasła po pierwszym logowaniu.
Efekt przenosin
Liczby pochodzą z odczytu folderów w poczcie przeglądarkowej starego dostawcy (20.10) i z panelu nowego hostingu po imporcie (01.11).
- odbiór poczty na nowym serwerze od chwili zmiany MX; mail testowy z zewnątrz doszedł po ok. 2 minutach
- główna skrzynka: 11 839 wiadomości w odczycie z 20.10 i 12 067 po drugim imporcie 01.11, w tym poczta z tych 12 dni; dwóch mniejszych skrzynek nie policzyliśmy w całości przed przenosinami, więc dla nich takiego porównania nie ma
- wysyłka z nowej poczty uwierzytelniona: SPF, DKIM i DMARC pass
- Outlook na dwóch komputerach wysyła i odbiera przez nowy serwer, bez utraty historii
- adres do zamówień zaczął przyjmować pocztę jako alias głównej skrzynki
Odbioru wszystkich folderów nie traktujemy jeszcze jako potwierdzonego: własne foldery jednej ze skrzynek sprawdza ich użytkownik. Formularz strony zostanie przestawiony na nową pocztę razem z przeniesieniem strony.
Pocztę przeniesiesz sam czy z kimś?
Jedna lub dwie skrzynki w IMAP, DNS u tego samego dostawcy co nowa poczta, brak strony, która wysyła maile z domeny. Wtedy wystarczy import w panelu nowego hostingu, zmiana MX i ustawienie programu pocztowego.
Strona i poczta u różnych dostawców, DNSSEC, konta techniczne strony, programy pocztowe na kilku komputerach i termin wyznaczony końcem abonamentu. Każdy z tych elementów osobno jest prosty, ale błędna kolejność kończy się utratą maili albo pocztą w spamie.
Przenosiny poczty i strony robimy razem z ustawieniem SPF, DKIM i DMARC, programów pocztowych i formularza strony. Po przełączeniu sprawdzamy liczby wiadomości i wysyłkę. Jeśli przenosisz też stronę, zobacz jak przenieść stronę WordPress na nowy hosting. O stronach, które budujemy i utrzymujemy, przeczytasz na stronie strony internetowe.
Dokumentacja, na której opiera się poradnik
- dhosting: jak aktywować usługę poczty e-mail w dPanelu: dwa warianty, z delegacją na serwery dhosting albo z rekordami MX i SPF u dotychczasowego operatora
- dhosting: jak zaparkować domenę: ustawienia DNS zaparkowanej domeny nieaktywne do czasu zmiany delegacji
- RFC 7208 (SPF): wyniki fail i softfail oraz to, że reakcję na nie wybiera serwer odbiorcy
- RFC 7208 (SPF), sekcja o kopercie: SPF sprawdza adres MAIL FROM, nie pole „Od”
- RFC 9989 (DMARC): polityka
p=nonei raporty zbiorcze tylko z tagiemrua - RFC 6781 (DNSSEC w praktyce): kolejność usuwania rekordu DS i wyłączania DNSSEC
Przebieg i liczby pochodzą z naszych przenosin z 31.10–01.11.2026. Opisujemy je bez nazwy firmy i adresów skrzynek.