Lead: Jeśli Twoje wiadomości nagle zaczęły trafiać do spamu, są odrzucane przez odbiorców albo pojawia się komunikat o błędzie SPF, DKIM lub DMARC, problem zwykle nie leży w samym programie pocztowym. Najczęściej źródłem kłopotów jest konfiguracja domeny, DNS albo sposób, w jaki wysyłasz wiadomości z kilku systemów naraz: poczty firmowej, CRM, sklepu internetowego, newslettera, formularza kontaktowego czy serwera hostingowego. To właśnie wtedy pojawia się klasyczny błąd: domena wygląda poprawnie, a mimo to mechanizmy uwierzytelniania poczty nie przechodzą.
Ten artykuł wyjaśnia, co naprawdę oznacza problem SPF, DKIM i DMARC, jak znaleźć jego przyczynę i jak go naprawić bez psucia innych usług. To ważne, bo jeden źle wpisany rekord DNS potrafi zablokować korespondencję firmową, uszkodzić reputację domeny i sprawić, że nawet poprawnie napisane maile nie dotrą do klienta. W przypadku poczty biznesowej to nie jest drobna usterka techniczna, tylko realny koszt: utracone leady, opóźnione zamówienia, chaos w komunikacji i ryzyko, że część wiadomości zniknie bez śladu.
Jeżeli widzisz błędy typu SPF fail, DKIM invalid, DMARC policy reject, message not accepted albo po prostu obserwujesz, że kampanie e-mailowe „się nie kleją” i nie ma spójności między ustawieniami domeny a wysyłką, ten poradnik pomoże Ci przejść od diagnozy do naprawy krok po kroku.
Szybka odpowiedź
Najczęstszy powód błędu SPF DKIM DMARC jest prosty: źródło wysyłki nie zgadza się z tym, co zadeklarowano w DNS. SPF sprawdza, czy dany serwer może wysyłać maile w imieniu domeny. DKIM potwierdza, że wiadomość nie została zmieniona i rzeczywiście pochodzi z autoryzowanego systemu. DMARC spina oba mechanizmy i mówi odbiorcy, co ma zrobić, gdy SPF lub DKIM nie przejdą.
Jeśli którykolwiek z tych elementów jest źle ustawiony, skutki są podobne: spadek dostarczalności, spam, odrzucanie wiadomości, a czasem całkowita blokada wysyłki. Najszybsza droga do naprawy wygląda tak:
- Sprawdź, z jakich systemów naprawdę wysyłasz maile.
- Porównaj je z rekordem SPF i upewnij się, że wszystkie legalne źródła są uwzględnione.
- Zweryfikuj, czy DKIM jest włączony i czy selektor oraz klucz publiczny w DNS zgadzają się z konfiguracją nadawcy.
- Sprawdź rekord DMARC i na początek ustaw łagodniejszą politykę, jeśli domena dopiero jest porządkowana.
- Przetestuj wysyłkę z jednego źródła, a potem dodawaj kolejne systemy.
Ważne ostrzeżenie: jeśli Twoja domena obsługuje kluczową komunikację biznesową, nie usuwaj rekordów DNS „na próbę” i nie kopiuj cudzych konfiguracji. Zły rekord SPF może wyłączyć wysyłkę z formularza kontaktowego, newslettera albo faktur automatycznych. Zanim cokolwiek zmienisz, zrób kopię aktualnych rekordów DNS.
Diagnoza problemu
Żeby rozwiązać problem skutecznie, trzeba najpierw zrozumieć, co dokładnie nie działa. Błąd SPF, DKIM i DMARC nie zawsze oznacza to samo. Czasem winny jest wyłącznie SPF, czasem DKIM podpisuje maile innym selektorem niż ten opublikowany w DNS, a czasem DMARC odrzuca wiadomości, które przechodzą technicznie, ale nie są zgodne z zasadą zgodności domeny.
Typowe objawy wyglądają tak:
- maile trafiają do spamu mimo poprawnej treści i znanej domeny;
- odbiorca widzi komunikat o odrzuceniu wiadomości z powodu nieudanego SPF, DKIM lub DMARC;
- maile z formularza kontaktowego dochodzą, ale odpowiedzi z systemu transakcyjnego już nie;
- wiadomości z Gmaila, Outlooka lub innego klienta działają, ale newslettery zewnętrznego dostawcy nie;
- status w narzędziach testowych pokazuje fail, softfail, neutral, temperror albo permerror;
- po wprowadzeniu DMARC wzrosła liczba odrzuconych wiadomości;
- podpis DKIM jest obecny, ale nie pasuje do domeny w nagłówku From.
Najważniejsze jest to, że te mechanizmy nie działają niezależnie od siebie. Odbiorca zwykle analizuje:
- czy serwer wysyłający jest dozwolony przez SPF,
- czy wiadomość ma prawidłowy podpis DKIM,
- czy domena w nagłówku From jest zgodna z domeną używaną w SPF lub DKIM zgodnie z DMARC.
W praktyce błąd może wynikać z drobiazgu: brakującego include w SPF, nieprawidłowego selektora DKIM, dwóch rekordów SPF w DNS, błędnej kolejności mechanizmów, przekroczenia limitu 10 zapytań DNS w SPF, złej polityki DMARC albo konfliktu między serwerem pocztowym a zewnętrznym narzędziem do wysyłki maili.
Jeżeli chcesz diagnozować problem profesjonalnie, zacznij od odpowiedzi na cztery pytania:
- Skąd naprawdę wychodzi wiadomość?
- Jaką domenę pokazuje From?
- Czy DNS zawiera aktualne rekordy SPF, DKIM i DMARC?
- Czy wszystkie systemy wysyłające maila są ujęte w konfiguracji?
Bez tej odpowiedzi naprawa jest zgadywaniem. A przy poczcie zgadywanie zwykle kończy się tym, że jeden problem znika, a dwa kolejne się pojawiają.
Możliwe przyczyny
Wbrew pozorom błąd SPF, DKIM i DMARC rzadko wynika z jednego „zepsutego” rekordu. Najczęściej to efekt nakładających się zmian: ktoś dodał nowy system wysyłki, ktoś inny zmienił hosting, a jeszcze ktoś przepisał DNS według niepełnego wzoru. Poniżej są najczęstsze przyczyny, z którymi spotyka się administrator lub właściciel firmy.
1. Rekord SPF nie obejmuje wszystkich nadawców
SPF musi wymieniać wszystkie legalne źródła wysyłki. Jeśli korzystasz z Google Workspace, Microsoft 365, hostingu, systemu fakturowego i platformy newsletterowej, każdy z tych elementów może wymagać dopisania do SPF. Jeśli choć jedno źródło jest pominięte, odbiorca może uznać wiadomość za nieautoryzowaną.
2. W DNS istnieje więcej niż jeden rekord SPF
To bardzo częsty błąd. Dla jednej domeny powinien istnieć jeden rekord typu TXT z polityką SPF. Jeśli w DNS są dwa niezależne rekordy SPF, wiele serwerów uzna to za błąd konfiguracji. Efekt: permerror i brak zaufania do wiadomości.
3. Limit zapytań DNS w SPF został przekroczony
SPF ma ograniczenie liczby odwołań do DNS. Jeśli rekord jest zbyt rozbudowany, zawiera zbyt wiele include, redirect i powiązań pośrednich, może dojść do przekroczenia limitu. Wtedy poprawny z pozoru rekord zaczyna zwracać błąd.
4. DKIM jest włączony, ale podpis nie zgadza się z DNS
DKIM działa poprawnie tylko wtedy, gdy selektor wskazuje właściwy klucz publiczny zapisany w DNS. Jeśli system wysyłający używa innego selektora niż ten opublikowany, odbiorca nie potwierdzi podpisu. To zdarza się po migracji poczty, zmianie dostawcy albo wymianie kluczy bez aktualizacji DNS.
5. Wiadomość jest podpisywana, ale po drodze ktoś ją modyfikuje
Niektóre systemy, bramki antyspamowe, stopki HTML, podpisy prawne lub automatyczne modyfikacje treści mogą naruszyć podpis DKIM. Nawet drobna zmiana w nagłówkach lub treści może sprawić, że podpis przestanie się zgadzać.
6. DMARC wymusza politykę, której domena jeszcze nie spełnia
Jeśli DMARC ustawiono zbyt agresywnie, na przykład na p=reject, zanim wszystkie źródła wysyłki są uporządkowane, część prawidłowych wiadomości zostanie odrzucona. DMARC powinien być zaostrzany etapami, szczególnie w środowiskach z wieloma nadawcami.
7. Brak zgodności domeny między From a podpisem
DMARC wymaga zgodności domeny w nagłówku From z domeną używaną w SPF lub DKIM. Jeśli newsletter idzie przez subdomenę, system CRM używa domeny technicznej, a poczta pokazuje domenę główną, może dojść do niezgodności nawet przy pozornie poprawnych rekordach.
8. Błędna składnia rekordów DNS
Jedna spacja, zły cudzysłów, zduplikowany separator lub nieprawidłowy znak mogą unieważnić rekord. DNS nie wybacza literówek, a błędny rekord TXT potrafi wyglądać „prawie dobrze”, ale nie działać w praktyce.
9. Zmiana hostingu lub migracja domeny bez aktualizacji poczty
Po migracji często przenosi się stronę, ale zapomina o poczcie. Nowy serwer, nowy panel DNS, inne IP lub inny system wysyłkowy oznaczają konieczność aktualizacji SPF, DKIM i czasem DMARC. Brak tej aktualizacji jest jednym z najczęstszych źródeł awarii.
10. Wysyłka z formularza strony przez niewłaściwy serwer
Strony internetowe często wysyłają wiadomości z lokalnej funkcji mailowej hostingu, która nie jest zgodna z polityką domeny. Użytkownik widzi formularz, ale poczta wychodzi przez serwer, którego SPF nie obejmuje, więc wiadomość ląduje w spamu albo jest odrzucana.
Rozwiązanie krok po kroku
Poniższa procedura pozwala uporządkować problem bez chaosu. Warto przejść ją po kolei, zamiast zmieniać kilka rzeczy naraz. Zmiany wykonywane hurtowo utrudniają diagnozę i zwiększają ryzyko przerwy w wysyłce.
Krok 1: Zidentyfikuj wszystkie źródła wysyłki
Wypisz wszystkie systemy, które wysyłają maile z Twojej domeny. Nie ograniczaj się do skrzynki firmowej. Uwzględnij:
- pocztę w Google Workspace, Microsoft 365 lub na hostingu;
- formularze kontaktowe ze strony internetowej;
- system sklepu internetowego;
- CRM lub system automatyzacji marketingu;
- newslettery;
- faktury, powiadomienia i maile transakcyjne;
- narzędzia helpdesk i systemy zgłoszeń;
- subdomeny wysyłkowe.
Jeśli nie wiesz, z czego naprawdę wychodzi mail, sprawdź nagłówki wiadomości testowej albo dokumentację dostawcy usługi.
Krok 2: Pobierz i zapisz aktualne rekordy DNS
Przed zmianami wykonaj kopię obecnej konfiguracji DNS. To proste zabezpieczenie pozwala wrócić do poprzedniego stanu, jeśli coś pójdzie nie tak. Zapisz rekordy SPF, DKIM, DMARC oraz wszystkie wpisy związane z pocztą i subdomenami.
Ostrzeżenie bezpieczeństwa: nie kasuj starych rekordów bez pewności, że nie są wykorzystywane przez inne usługi. Usunięcie starego selektora DKIM albo wpisu SPF może odciąć działający system, którego nie uwzględniłeś w analizie.
Krok 3: Sprawdź rekord SPF
Rekord SPF powinien istnieć jako jeden, spójny wpis TXT dla domeny. Powinien zawierać tylko te źródła, z których naprawdę wysyłasz. Przykładowa logika wygląda tak: mechanizm v=spf1 plus dozwolone adresy IP, rekordy include usług zewnętrznych i na końcu odpowiednia polityka końcowa, zwykle -all albo ~all w fazie testów.
Sprawdź szczególnie:
- czy nie ma dwóch rekordów SPF;
- czy wszystkie usługi są uwzględnione;
- czy nie przekroczono limitu zapytań DNS;
- czy rekord nie zawiera zbędnych lub przestarzałych wpisów;
- czy nie ma literówek w nazwach dostawców.
Krok 4: Zweryfikuj DKIM
Upewnij się, że DKIM jest włączony po stronie systemu wysyłającego oraz że w DNS znajduje się odpowiadający mu klucz publiczny. Klucz w DNS publikowany jest zwykle pod nazwą zawierającą selektor, na przykład s1._domainkey lub podobny wariant, zależnie od dostawcy.
Sprawdź:
- czy selektor jest identyczny po obu stronach;
- czy klucz publiczny nie został uszkodzony podczas wklejania;
- czy wiadomości są podpisywane tym samym kluczem, który opublikowano w DNS;
- czy system po migracji nie wygenerował nowego selektora bez aktualizacji DNS;
- czy podpis nie jest niszczony przez pośredni system modyfikujący wiadomość.
Krok 5: Ustal politykę DMARC
DMARC powinien być dopasowany do dojrzałości konfiguracji. Jeśli dopiero porządkujesz SPF i DKIM, ustaw politykę łagodnie, na przykład raportowanie bez odrzucania, a dopiero później zaostrzaj reguły. W praktyce DMARC to narzędzie do kontroli, a nie pierwszy krok naprawy.
Sprawdź:
- czy rekord DMARC istnieje pod nazwą _dmarc;
- czy polityka nie jest zbyt agresywna na start;
- czy adresy raportowe są poprawne;
- czy domena główna i subdomeny są objęte odpowiednią strategią;
- czy raporty DMARC rzeczywiście do Ciebie docierają i są analizowane.
Krok 6: Przetestuj wysyłkę z każdego źródła osobno
Nie testuj wszystkiego naraz. Wyślij wiadomość z jednego źródła, sprawdź nagłówki, wynik SPF, DKIM i DMARC, a dopiero potem przejdź do następnego systemu. Dzięki temu szybko znajdziesz punkt, w którym konfiguracja się rozjeżdża.
Najlepiej testować:
- z konta firmowego;
- z formularza kontaktowego;
- z systemu newsletterowego;
- z systemu transakcyjnego;
- z CRM lub helpdesku.
Krok 7: Analizuj nagłówki wiadomości
W nagłówkach szukaj wyników Authentication-Results, Received-SPF, DKIM-Signature i informacji o polityce DMARC. To właśnie tam zobaczysz, czy wiadomość przeszła uwierzytelnienie, czy nie. Jeśli nie potrafisz odczytać nagłówków, porównaj je z dokumentacją dostawcy lub skorzystaj z testu diagnostycznego.
Krok 8: Dopiero potem zaostrzaj DMARC
Gdy wszystko działa poprawnie, można przejść z trybu monitorowania do restrykcyjniejszej polityki. Zbyt szybkie ustawienie reject bywa przyczyną masowych odrzuceń. Najpierw trzeba mieć pewność, że każdy legalny nadawca jest zgodny z SPF i DKIM.
Krok 9: Wprowadź monitoring
Po naprawie nie zostawiaj tematu bez nadzoru. DMARC daje raporty, które pokazują, kto wysyła w imieniu domeny i czy próby wysyłki są zgodne z polityką. Monitorowanie pozwala wykryć nowe błędy po kolejnej migracji, aktualizacji systemu lub wdrożeniu nowego narzędzia marketingowego.
Krok 10: Uporządkuj dokumentację
Zapisz, które usługi wysyłają maila, jaki mają selektor DKIM, jakie IP są w SPF i jaka jest polityka DMARC. Bez dokumentacji kolejna zmiana znowu wywoła chaos. Dobra dokumentacja jest szczególnie ważna, gdy domeną zarządza więcej niż jedna osoba.
Najczęstsze błędy
W praktyce naprawa SPF, DKIM i DMARC psuje się najczęściej nie dlatego, że system jest skomplikowany, ale dlatego, że ktoś pominął szczegół albo poprawił „na szybko” tylko jedną część układanki.
- Dodanie wielu rekordów SPF. Dla jednej domeny powinien istnieć jeden spójny rekord SPF.
- Bezrefleksyjne kopiowanie konfiguracji z internetu. Każda domena ma inne źródła wysyłki.
- Ustawienie DMARC na reject za wcześnie. To częsty powód nagłego blokowania wiadomości.
- Ignorowanie subdomen. Część narzędzi wysyła z subdomeny, a nie z domeny głównej.
- Brak aktualizacji po migracji. Nowy hosting albo nowy dostawca poczty wymaga ponownej weryfikacji.
- Pomylenie selektora DKIM. Nawet poprawny klucz nie zadziała, jeśli selektor jest inny.
- Niewłaściwe adresy w raporcie DMARC. Bez raportów trudno wykryć źródło problemu.
- Zmiana DNS bez cierpliwego oczekiwania na propagację. Część serwerów widzi zmiany od razu, część później.
- Testowanie tylko jednej skrzynki. To nie wystarczy, jeśli wysyłasz z kilku systemów.
- Usuwanie starych wpisów bez sprawdzenia, kto z nich korzysta. Czasem działa „coś”, o czym nikt już nie pamięta.
Warto też pamiętać o błędach organizacyjnych. Zdarza się, że marketing uruchamia nowy newsletter bez wiedzy administratora, dział sprzedaży podłącza CRM, a e-commerce używa zewnętrznego systemu transakcyjnego. Potem wszyscy widzą „błąd poczty”, ale nikt nie wie, skąd wyszedł mail. W takim środowisku sama zmiana DNS bez inwentaryzacji jest tylko półśrodkiem.
Kiedy nie robić tego samodzielnie
Są sytuacje, w których samodzielna naprawa może przynieść więcej szkody niż pożytku. Jeśli domena obsługuje sprzedaż, faktury, logowanie dwuskładnikowe, potwierdzenia zamówień i komunikację z klientem, ryzyko błędnej zmiany jest wysokie.
Nie rób tego samodzielnie, jeśli:
- nie masz dostępu do pełnego panelu DNS;
- nie wiesz, ile systemów faktycznie wysyła maile;
- nie potrafisz czytać nagłówków wiadomości;
- masz już kilka nieudanych prób i sytuacja się pogarsza;
- domena obsługuje krytyczne procesy biznesowe;
- pojawiają się błędy po migracji między dostawcami;
- używasz kilku subdomen i wielu zewnętrznych usług;
- pocztę konfigurowała wcześniej inna firma lub były administrator i nie ma dokumentacji.
Ostrzeżenie bezpieczeństwa: nie ustawiaj DMARC na pełne odrzucanie, jeśli nie masz pewności, że wszystkie legalne źródła są już zgodne. W przeciwnym razie zablokujesz własne wiadomości. To szczególnie groźne przy fakturach, resetach haseł i kontaktach handlowych.
Kiedy zgłosić się do specjalisty
Pomoc specjalisty jest wskazana wtedy, gdy problem nie jest już pojedynczym rekordem, ale obejmuje całą architekturę poczty. Jeśli po zmianach nadal masz niespójne wyniki SPF, DKIM i DMARC, potrzebujesz kogoś, kto przeanalizuje DNS, serwer wysyłający, bramki pośrednie i logi pocztowe jako całość.
Zgłoś się do specjalisty, jeśli:
- masz masowe odrzucenia wiadomości po wdrożeniu DMARC;
- newslettery są odrzucane, a skrzynka firmowa działa tylko częściowo;
- po migracji zniknęła zgodność między domeną a podpisem;
- komunikacja pochodzi z kilku platform i nie wiadomo, które są autoryzowane;
- potrzebujesz wdrożyć politykę DMARC z monitoringiem i raportowaniem;
- podejrzewasz, że ktoś podszywa się pod Twoją domenę;
- wyniki testów są sprzeczne w różnych narzędziach;
- masz już dosyć prób i błędów, bo każda zmiana coś psuje.
Specjalista jest szczególnie przydatny wtedy, gdy trzeba uporządkować nie tylko rekordy, ale też procesy: dokumentację, odpowiedzialność za DNS, przepływ wysyłek i procedury przy wdrażaniu nowych narzędzi. To oszczędza czas, a przede wszystkim zmniejsza ryzyko utraty dostarczalności w przyszłości.
Podsumowanie i CTA do kontaktu
Błąd SPF, DKIM i DMARC nie jest zwykle „awarią poczty” w potocznym sensie. To najczęściej sygnał, że domena nie jest spójna z systemami, które wysyłają maile w jej imieniu. Dopóki nie ustalisz wszystkich źródeł wysyłki, nie sprawdzisz rekordów DNS i nie przetestujesz nagłówków wiadomości, problem będzie wracał albo będzie się tylko przemieszczał między kolejnymi usługami.
Najlepsza strategia jest prosta: najpierw diagnoza, potem porządek w SPF i DKIM, dopiero na końcu ostrożne zaostrzenie DMARC. Jeśli działasz bez planu, możesz przypadkowo zablokować własną komunikację. Jeśli działasz metodycznie, da się to naprawić bezpiecznie i trwale.
Jeżeli chcesz uniknąć utraty maili, problemów z dostarczalnością i kolejnych błędów po migracji lub wdrożeniu nowego systemu wysyłkowego, skontaktuj się ze specjalistą, który przeanalizuje Twoją konfigurację i uporządkuje ją bez ryzyka dla biznesu. W przypadku poczty firmowej szybka reakcja często decyduje o tym, czy wiadomości dojdą dziś, czy znikną w spamie na kolejne tygodnie.
