Wtorek, dzień po przełączeniu firmy na nową pocztę. Skrzynki działają, wiadomości przychodzą, wszystko wygląda dobrze. Do czasu, aż handlowiec dowiaduje się od klienta, że wczorajsza oferta wylądowała w spamie, a dwie inne w ogóle nie dotarły. Formularz kontaktowy na stronie przestał wysyłać powiadomienia, a faktury z systemu księgowego wracają z komunikatem o odrzuceniu.
W większości takich przypadków sama migracja skrzynek poszła poprawnie, a problem leży w DNS. Rekordy, które mówią innym serwerom, kto może wysyłać pocztę z Twojej domeny, nadal wskazują stary serwer albo są ustawione tylko w połowie. Poniżej znajdziesz, które wpisy trzeba zmienić przy przenosinach, w jakiej kolejności i jak sprawdzić, że wysyłka działa.
Dlaczego po migracji poczta nagle traci wiarygodność
Serwer odbiorcy, np. Gmail albo Outlook.com, nie ufa wiadomości tylko dlatego, że w polu nadawcy jest adres w Twojej domenie. Sprawdza trzy rzeczy: czy serwer, z którego przyszła wiadomość, jest wpisany w rekordzie SPF domeny, czy wiadomość ma poprawny podpis DKIM i czy domena publikuje politykę DMARC, która mówi, co robić z wiadomościami niespełniającymi tych warunków.
Po zmianie dostawcy poczta zaczyna wychodzić z zupełnie innych serwerów. Jeśli rekord SPF nadal wymienia tylko stary hosting, a nowy dostawca nie ma jeszcze włączonego podpisu DKIM dla Twojej domeny, z punktu widzenia odbiorcy wiadomość wygląda jak próba podszycia się pod firmę. Efekt to folder spam albo odrzucenie.
Wymagania odbiorców są coraz ostrzejsze. Od 2024 roku Google i Yahoo wymagają od nadawców wysyłających duże wolumeny poczty jednoczesnego SPF, DKIM i DMARC, a Microsoft wprowadził podobne zasady dla Outlook.com w 2025 roku. Zwykła korespondencja firmowa nie podlega tym progom, ale filtry antyspamowe oceniają ją według tych samych sygnałów, więc domena bez pełnej konfiguracji ma po prostu gorszy start.
Do tego dochodzi czas propagacji DNS. Nawet poprawnie zmienione rekordy nie zaczynają działać wszędzie w tej samej chwili. Serwery na świecie trzymają stare wartości w pamięci podręcznej tak długo, jak pozwala na to TTL rekordu, więc przez kilka godzin część odbiorców może widzieć jeszcze starą konfigurację.
Rekordy MX i TTL – jak przygotować przełączenie
Rekord MX decyduje, dokąd trafia poczta przychodząca do Twojej domeny. To jego zmiana jest momentem przełączenia, dlatego trzeba ją zaplanować, a nie zrobić przy okazji. Zacznij od sprawdzenia, gdzie w ogóle zarządzasz DNS domeny. Często jest to inny panel niż hosting poczty, np. u rejestratora domeny albo w usłudze typu Cloudflare.
Na dobę lub dwie przed migracją obniż TTL rekordów MX i Autodiscover, np. do 300 sekund. Domyślne wartości bywają ustawione na kilka godzin albo dobę i właśnie przez nie poczta potrafi trafiać na stary serwer długo po przełączeniu. Krótki TTL sprawia, że zmiana rozchodzi się w kilka minut, a w razie problemu równie szybko wrócisz do poprzedniej konfiguracji.
W dniu przełączenia zamieniasz rekordy MX na wartości podane przez nowego dostawcę i usuwasz stare. Zostawienie starego MX z niższym priorytetem „na wszelki wypadek” to typowy błąd: część serwerów nadawców wybierze go przy chwilowym problemie z połączeniem i wiadomość wyląduje w skrzynce, której nikt już nie czyta.
Przy przejściu na Microsoft 365 nie zapomnij o rekordzie Autodiscover. To on podpowiada Outlookowi, gdzie jest skrzynka, i bez niego użytkownicy dostają pytania o hasło albo błędy konfiguracji profilu. Po zmianie MX przez kilka dni monitoruj starą skrzynkę, bo pojedyncze wiadomości od nadawców z długo cache’ującymi serwerami mogą tam jeszcze docierać.
SPF – jeden rekord dla wszystkich serwerów, które wysyłają w Twoim imieniu
SPF to rekord TXT, który wymienia serwery uprawnione do wysyłania poczty z Twojej domeny. Po migracji musisz dodać do niego nowego dostawcę, np. include:spf.protection.outlook.com dla Microsoft 365 albo include:_spf.google.com dla Google Workspace. Sam dopisek to jednak dopiero połowa pracy.
Najczęstszy błąd to dodanie drugiego rekordu SPF obok starego. Domena może mieć tylko jeden taki rekord, a dwa równoległe wpisy zaczynające się od v=spf1 powodują błąd i weryfikacja SPF przestaje działać w ogóle. Wszystkie serwery wpisujesz więc w jednym rekordzie, a stary usuwasz albo edytujesz.
Zanim usuniesz stary hosting z SPF, sprawdź, kto jeszcze wysyła pocztę z Twojej domeny. Formularz kontaktowy na stronie WordPress często korzysta z serwera hostingu WWW, system księgowy wysyła faktury z własnej infrastruktury, a newslettery wychodzą z platformy marketingowej. Każde z tych źródeł musi zostać w rekordzie albo przejść na wysyłkę przez nową skrzynkę SMTP.
Pilnuj też limitu. Specyfikacja SPF dopuszcza najwyżej 10 zapytań DNS podczas sprawdzania rekordu, a każdy include może zawierać kolejne. Przy kilku narzędziach marketingowych i dwóch dostawcach poczty łatwo ten limit przekroczyć, a wtedy weryfikacja kończy się błędem, nawet jeśli każdy wpis z osobna jest poprawny. Na końcu rekordu ustaw ~all, a na -all przejdź dopiero wtedy, gdy masz pewność, że lista jest kompletna.
DKIM – podpis, który trzeba włączyć u nowego dostawcy
DKIM dodaje do każdej wysyłanej wiadomości podpis kryptograficzny, który odbiorca sprawdza za pomocą klucza publicznego opublikowanego w DNS Twojej domeny. Klucz stary dostawca generował dla swoich serwerów, więc po migracji nie ma żadnej wartości. Nowy dostawca musi wygenerować własny, a Ty musisz opublikować go w DNS.
W Microsoft 365 polega to na dodaniu dwóch rekordów CNAME (selector1 i selector2 w poddomenie _domainkey) i włączeniu podpisywania dla domeny w portalu Microsoft Defender. W Google Workspace generujesz klucz w konsoli administratora, publikujesz go jako rekord TXT i dopiero potem włączasz uwierzytelnianie. W obu przypadkach sam wpis w DNS nie wystarczy, jeśli zapomnisz o przełączniku po stronie dostawcy.
Microsoft 365 domyślnie nie podpisuje poczty z własnej domeny firmy, tylko wiadomości z domeny technicznej onmicrosoft.com. Dopóki nie włączysz DKIM dla swojej domeny, wiadomości nie mają podpisu zgodnego z domeną w polu nadawcy, a SPF zostaje jedynym mechanizmem, na którym opiera się DMARC. To jedna z częstszych przyczyn, dla których po migracji raporty DMARC nagle pokazują błędy.
To samo dotyczy innych systemów wysyłających pocztę z domeny. Platforma newsletterowa czy system do wysyłki faktur zwykle oferuje własny klucz DKIM do opublikowania w DNS. Jeśli przy okazji migracji porządkujesz rekordy, sprawdź, czy każde z tych narzędzi ma swój podpis, i usuń klucze po usługach, z których firma już nie korzysta.
DMARC – polityka, którą wdrażasz stopniowo
DMARC to rekord TXT w poddomenie _dmarc, który mówi odbiorcom, co zrobić z wiadomością, która nie przeszła SPF ani DKIM w zgodzie z domeną nadawcy, i dokąd wysyłać raporty. Jeśli domena nie miała dotąd DMARC, migracja jest dobrym momentem, żeby go dodać, ale nie od razu z najostrzejszą polityką.
Zacznij od p=none z adresem do raportów zbiorczych w parametrze rua. Taka polityka niczego nie blokuje, a raporty pokażą, które serwery wysyłają pocztę z Twojej domeny i czy przechodzą weryfikację. Po kilku tygodniach zwykle wychodzą na jaw źródła, o których nikt nie pamiętał: stara drukarka wysyłająca skany, system rezerwacji, narzędzie do ankiet.
Gdy raporty są czyste, przechodzisz na p=quarantine, a później na p=reject. Ta druga polityka najlepiej chroni przed podszywaniem się pod firmę, np. przy fałszywych fakturach wysyłanych do kontrahentów, ale ustawiona za wcześnie odcięłaby legalną pocztę z systemów, których nie dopisałeś do SPF ani DKIM.
Jeśli domena miała już restrykcyjny DMARC przed migracją, na czas przenosin rozważ tymczasowe złagodzenie polityki. Przy p=reject i jeszcze niewłączonym DKIM u nowego dostawcy pierwsze godziny po przełączeniu MX mogą skończyć się odrzuceniem większości wysyłanej poczty.
Jak sprawdzić, że wysyłka działa poprawnie
Najszybszy test to wysłanie wiadomości z nowej skrzynki na prywatne konto Gmail i Outlook.com, a potem obejrzenie nagłówków. W Gmailu opcja „Pokaż oryginał” wyświetla wynik SPF, DKIM i DMARC wprost: przy każdym powinno być PASS, a przy DKIM domena podpisu powinna być Twoją domeną, a nie domeną dostawcy.
Drugi krok to sprawdzenie rekordów narzędziami online, które weryfikują składnię SPF, liczbę zapytań DNS, obecność kluczy DKIM i poprawność rekordu DMARC. Wyłapią błędy, których nie widać w zwykłej korespondencji, np. drugi rekord SPF albo literówkę w nazwie selektora.
Potem przetestuj wszystkie pozostałe źródła poczty: formularz na stronie, wysyłkę faktury z systemu księgowego, powiadomienia ze sklepu internetowego. Każde z nich powinno przejść ten sam test nagłówków. Przez pierwsze tygodnie zaglądaj też do raportów DMARC, bo to w nich najszybciej zobaczysz, że coś wysyła pocztę z domeny bez autoryzacji.
Jeśli nie chcesz ustawiać rekordów DNS metodą prób i błędów na działającej firmie, warto połączyć przenosiny skrzynek z konfiguracją domeny w jednym projekcie. Dobrze zaplanowana migracja poczty firmowej, taką jaką realizuje NG Solutions, obejmuje nie tylko przeniesienie wiadomości, ale też ustawienie MX, SPF, DKIM i DMARC tak, żeby oferty od pierwszego dnia trafiały do skrzynek klientów, a nie do ich spamu.
