Masz wrażenie, że SPF, DKIM i DMARC są poprawnie ustawione, a mimo to poczta trafia do spamu, nie dochodzi albo raporty pokazują błędy uwierzytelniania? To jeden z najczęstszych i najbardziej frustrujących problemów w firmowej poczcie e-mail. Z zewnątrz wygląda prosto: dodajesz trzy rekordy DNS, a wiadomości mają być „wiarygodne”. W praktyce wystarczy drobna niezgodność w domenie, literówka w rekordzie, brak aktualizacji po migracji hostingu albo kilka systemów wysyłki naraz, żeby cały mechanizm przestał działać.
Jeśli szukasz odpowiedzi na pytanie „dlaczego SPF, DKIM i DMARC nie działają?”, ten artykuł jest właśnie o realnych przyczynach, a nie o teorii. Pokażę Ci, jak rozpoznać źródło problemu, co sprawdzić po kolei oraz kiedy próba samodzielnej naprawy może tylko pogorszyć sytuację. W wielu przypadkach to nie jest awaria jednego rekordu, lecz łańcuch zależności między DNS, serwerem poczty, systemem wysyłkowym, nagłówkami wiadomości i polityką odbiorców. Dobra wiadomość jest taka, że większość błędów da się naprawić metodycznie.
Ważne ostrzeżenie: zanim zmienisz rekordy DNS, zapisz aktualną konfigurację. Błędna edycja SPF lub DMARC może natychmiast zablokować wysyłkę z ważnych systemów: sklepu internetowego, formularza kontaktowego, faktur, newslettera, CRM-u lub skrzynki pracowników. Jeśli poczta jest krytyczna dla firmy, każdą zmianę wykonuj ostrożnie i najlepiej poza godzinami największego ruchu.
Szybka odpowiedź
Najczęściej SPF, DKIM i DMARC nie działają z powodu jednego z tych problemów:
- rekord SPF nie zawiera wszystkich systemów, które wysyłają pocztę w imieniu domeny,
- DKIM podpisuje wiadomości inną domeną niż domena nadawcy,
- rekord DMARC jest zbyt restrykcyjny jak na aktualny stan konfiguracji,
- w DNS są błędy składniowe, nadmiar rekordów lub duplikaty,
- zmiana hostingu, serwera SMTP lub dostawcy mailingu nie została odzwierciedlona w DNS,
- rejestrator lub panel DNS jeszcze nie rozpowszechnił zmian,
- wiadomość przechodzi przez pośredni system, który zmienia nagłówki albo treść, przez co DKIM się łamie,
- nadawca, domena From i domena podpisu DKIM nie są zgodne z polityką DMARC.
W praktyce: sprawdź nagłówki wiadomości, potwierdź aktualny rekord SPF, zweryfikuj podpis DKIM dla każdej aplikacji wysyłającej e-mail i dopiero na końcu analizuj DMARC. Jeśli chcesz szybko przywrócić poprawne dostarczanie, zacznij od ustalenia, który konkretnie mechanizm nie przechodzi: SPF, DKIM czy DMARC alignment.
Diagnoza problemu
Objawy są różne, ale zwykle sprowadzają się do kilku scenariuszy. Część wiadomości trafia do spamu, część w ogóle nie dochodzi, a testy w narzędziach diagnostycznych pokazują rozbieżne wyniki. Czasem wszystko wygląda dobrze w panelu DNS, ale odbiorca i tak odrzuca wiadomość. To dlatego, że uwierzytelnianie e-mail nie opiera się wyłącznie na samym rekordzie DNS. Liczy się też to, skąd wiadomość faktycznie wyszła, jak została podpisana, czy domeny się zgadzają i czy żaden pośrednik nie uszkodził podpisu.
W praktyce warto diagnozować problem w tej kolejności:
- Sprawdź, co widzi odbiorca — najlepiej w pełnych nagłówkach wiadomości lub w raporcie zwrotnym.
- Ustal, który element nie przechodzi — SPF, DKIM czy DMARC.
- Zweryfikuj DNS — rekordy TXT, mechanizmy include, selektory DKIM, politykę DMARC.
- Sprawdź wszystkie źródła wysyłki — serwer pocztowy, sklep, formularze, newslettery, system faktur, CRM, aplikacje zewnętrzne.
- Porównaj domeny — From, envelope-from, d= w DKIM, domenę subdomeny i ewentualne przekierowania.
Najważniejsze jest zrozumienie, że „nie działa” może znaczyć kilka różnych rzeczy. Dla jednego problemem będzie fail SPF, dla innego brak zgodności DMARC, a jeszcze ktoś zauważy, że DKIM przechodzi, ale dla innej domeny niż główna. Wszystkie te przypadki mają inne przyczyny i wymagają innej naprawy.
Jeżeli widzisz w nagłówku komunikaty typu spf=fail, dkim=fail, dmarc=fail albo none, to nie zakładaj od razu, że rekord nie istnieje. Rekord może być obecny, ale niepoprawny, niekompletny albo niedopasowany do bieżącej ścieżki wysyłki. To szczególnie częste po migracjach hostingu, zmianie dostawcy poczty lub wdrożeniu nowego systemu mailingowego.
Możliwe przyczyny
1. Rekord SPF nie obejmuje wszystkich nadawców
SPF odpowiada za sprawdzenie, czy serwer wysyłający wiadomość ma prawo to robić dla danej domeny. Jeśli używasz tylko jednego serwera, sprawa jest prosta. Problem zaczyna się, gdy z tej samej domeny wysyła:
- hosting poczty,
- sklep internetowy,
- system faktur,
- platforma newsletterowa,
- CRM,
- formularz kontaktowy przez zewnętrzny SMTP.
Wtedy rekord SPF musi zawierać wszystkie autoryzowane źródła. Jeśli choć jedno z nich nie jest uwzględnione, część wiadomości zakończy się błędem SPF.
Klasyczny błąd to też przekroczenie limitu wyszukiwań DNS w SPF. Rekord może wyglądać poprawnie, ale zawiera zbyt wiele mechanizmów include, mx, a lub odwołań do zewnętrznych domen. Efekt: odbiorca odrzuca SPF jako nieprawidłowy, mimo że „na oko” wszystko jest w porządku.
2. DKIM podpisuje inna domena niż ta widoczna dla odbiorcy
DKIM działa przez podpis cyfrowy wiadomości. Jeżeli podpis jest tworzony dla jednej domeny, a wiadomość wygląda jak wysłana z innej, DMARC może tego nie zaakceptować. Często dzieje się tak przy:
- wykorzystaniu zewnętrznej platformy mailingowej,
- subdomenach wysyłkowych,
- źle skonfigurowanym selektorze DKIM,
- migracji między serwerami,
- zmianie domeny From bez aktualizacji podpisu.
DKIM może też „padać” przez modyfikację treści wiadomości po podpisaniu. Niektóre systemy po drodze dodają stopki, zmieniają kodowanie, przepuszczają treść przez filtr antyspamowy lub modyfikują nagłówki. Wtedy podpis nie pasuje do treści, mimo że klucz publiczny w DNS istnieje.
3. DMARC jest zbyt restrykcyjny lub niezgodny z aktualną konfiguracją
DMARC nie naprawia SPF ani DKIM. On sprawdza, czy jeden z tych mechanizmów przechodzi i czy domena jest z nimi zgodna. Jeśli ustawisz politykę p=reject bez poprawnego dopięcia SPF/DKIM, część wiadomości zacznie być odrzucana. To częsty błąd po wdrożeniu DMARC „na ostro”, bez fazy monitoringu.
Typowe problemy z DMARC to:
- brak zgodności domeny From z domeną używaną w SPF lub DKIM,
- zbyt szybkie przejście z
p=nonenap=quarantinelubp=reject, - niepełny rekord DMARC,
- literówki w tagach,
- złe ustawienie subdomen przez tag
sp.
4. Rekord DNS ma błąd składniowy
DNS nie wybacza wielu błędów. Czasem jedna dodatkowa spacja, nieprawidłowy cudzysłów, duplikat rekordu TXT albo błędna kolejność parametrów wystarczy, by mechanizm przestał działać. W panelu dostawcy rekord może wyglądać poprawnie, ale dla resolvera już nie.
Do częstych błędów należą:
- kilka rekordów SPF zamiast jednego,
- podzielenie jednego rekordu TXT w nieprawidłowy sposób,
- zła nazwa hosta, na przykład
_dmarcwpisane z błędem, - użycie złego selektora DKIM,
- wstawienie rekordu dla innej strefy DNS niż ta faktycznie obsługująca domenę.
5. DNS jeszcze się nie rozpropagował
Po zmianie rekordów trzeba uwzględnić czas propagacji. Często panel pokazuje nową wartość, ale część serwerów na świecie nadal odczytuje poprzednią konfigurację z cache. W praktyce oznacza to okres przejściowy, w którym testy dają różne wyniki zależnie od narzędzia i lokalizacji. To nie zawsze błąd — czasem to po prostu opóźnienie, ale jeśli problem trwa długo, trzeba szukać dalej.
6. Wysyłka idzie przez kilka systemów i miesza się źródło nadawcy
To bardzo częsty scenariusz w firmach. Przykładowo formularz kontaktowy wysyła przez hosting, faktury przez zewnętrzny system, newsletter przez inną platformę, a pracownicy używają jeszcze skrzynki na serwerze pocztowym. Jeśli jedna domena jest używana przez wiele źródeł, a nie wszystkie są wpisane do SPF i DKIM, będą problemy.
Co gorsza, część usług wysyła z adresu w rodzaju noreply@twojadomena.pl, ale podpisuje wiadomość własną domeną dostawcy. Wtedy SPF może przejść, ale DMARC już nie, jeśli brak alignmentu. To właśnie dlatego samo „dodanie DMARC” nie gwarantuje sukcesu.
7. Zmieniła się domena, subdomena albo certyfikat systemu poczty
Po migracjach domena może działać inaczej niż wcześniej. Czasami firma zmienia główną domenę, uruchamia nową subdomenę wysyłkową lub przenosi pocztę do innego operatora. Jeśli rekordy nie zostaną uaktualnione w tym samym momencie, uwierzytelnianie przestaje być spójne. W podobny sposób problemy powoduje wymiana platformy SaaS do wysyłki, bo nowy dostawca zwykle wymaga innych rekordów SPF i DKIM.
Rozwiązanie krok po kroku
Krok 1. Zbierz pełne nagłówki problematycznej wiadomości
Zacznij od wiadomości, która została odrzucona, trafiła do spamu albo dostała negatywny wynik w teście. Otwórz pełne nagłówki i znajdź linie związane z:
- SPF,
- DKIM,
- DMARC,
- Return-Path,
- From,
- Authentication-Results.
To najważniejszy punkt diagnostyki. Bez nagłówków działasz po omacku. W nagłówkach zobaczysz, czy problem dotyczy autoryzacji źródła, podpisu, czy zgodności domen.
Krok 2. Ustal, który mechanizm faktycznie zawodzi
Jeśli spf=pass, a dkim=pass, ale DMARC nadal nie przechodzi, to problemem zwykle jest alignment. Jeżeli SPF pada, ale DKIM przechodzi, poczta często nadal może zostać zaakceptowana przez DMARC. Jeśli oba mechanizmy są niepoprawne, sprawa jest pilna, bo wiadomości będą coraz częściej traktowane jako podejrzane.
Warto zapisać prostą matrycę:
- SPF fail — sprawdź nadawcę i źródło wysyłki.
- DKIM fail — sprawdź podpis, selektor i modyfikacje wiadomości.
- DMARC fail — sprawdź zgodność domen i politykę DMARC.
Krok 3. Sprawdź, czy masz jeden rekord SPF i czy nie przekracza limitów
Dla domeny powinien istnieć jeden poprawny rekord SPF. Jeśli masz kilka rekordów TXT zaczynających się od v=spf1, to najczęściej konfiguracja jest błędna. Połącz reguły w jeden rekord i usuń duplikaty. Następnie zweryfikuj, czy uwzględnia on wszystkie systemy wysyłki.
Uwaga: nie dodawaj wszystkiego „na wszelki wypadek”. Nadmiarowy SPF bywa równie groźny jak zbyt wąski. Zbyt długi rekord, nadmiar include lub pętle w DNS mogą spowodować odmowę walidacji.
Krok 4. Zweryfikuj DKIM dla każdego źródła poczty
Każdy system wysyłający z Twojej domeny może wymagać własnego selektora i własnego klucza DKIM. Wejdź do panelu dostawcy poczty, newslettera albo aplikacji SaaS i sprawdź:
- jaką domenę podpisuje,
- jaki selektor DKIM ma być opublikowany w DNS,
- czy klucz publiczny został poprawnie dodany,
- czy wiadomości nie są modyfikowane po podpisaniu.
Jeśli po drodze wiadomość jest przepakowywana przez dodatkowy system, test DKIM może się wywalać mimo poprawnego rekordu. Wtedy trzeba znaleźć miejsce modyfikacji i zminimalizować ingerencję w treść.
Krok 5. Uprość i popraw rekord DMARC
Na początek DMARC powinien służyć do obserwacji, a nie do blokowania wszystkiego. Jeśli konfigurujesz domenę od zera albo naprawiasz problem, bezpieczniej jest zacząć od polityki p=none, dodać adres do raportów i obserwować ruch. Dopiero po potwierdzeniu, że SPF i DKIM działają dla wszystkich źródeł, można przejść do ostrzejszych reguł.
Sprawdź też, czy DMARC obejmuje subdomeny zgodnie z Twoim planem. Niewłaściwie ustawiony tag sp może powodować, że wiadomości z subdomeny są traktowane inaczej niż się spodziewasz.
Krok 6. Przejdź przez wszystkie systemy wysyłki
Spisz każde miejsce, z którego wychodzą wiadomości:
- serwer poczty firmowej,
- poczta z hostingu,
- formularz kontaktowy,
- sklep internetowy,
- systemy CRM i ERP,
- platformy mailingowe,
- powiadomienia aplikacyjne,
- faktury i automaty księgowe.
Każdy z nich sprawdź osobno. Często okazuje się, że problem nie leży w poczcie jako takiej, tylko w jednym zapomnianym narzędziu, które wysyła co najwyżej kilkadziesiąt wiadomości dziennie, ale robi duże szkody w reputacji domeny.
Krok 7. Poczekaj na propagację i przetestuj ponownie
Po zmianach odczekaj odpowiedni czas i sprawdź wynik ponownie z kilku źródeł. Jeśli wynik nadal jest niespójny, to znak, że problem nie wynika wyłącznie z propagacji. Wtedy wróć do nagłówków i porównaj, co dokładnie zmieniło się w odpowiedzi różnych serwerów.
Krok 8. Zabezpiecz domenę po naprawie
Gdy mechanizmy już działają, nie zostawiaj konfiguracji bez nadzoru. Ustal stały monitoring raportów DMARC, kontrolę zmian DNS i procedurę aktualizacji przy każdej migracji lub wdrożeniu nowego narzędzia. To ważne, bo SPF/DKIM/DMARC często psują się nie z powodu jednego wielkiego błędu, tylko drobnych zmian wprowadzanych później przez różne osoby i systemy.
Najczęstsze błędy
- Dodanie wielu rekordów SPF zamiast jednego.
- Brak uwzględnienia zewnętrznej platformy do wysyłki newslettera.
- Ustawienie DMARC na
rejectbez wcześniejszego monitoringu. - Skopiowanie przykładowego rekordu DNS bez dostosowania do własnej infrastruktury.
- Zmiana hostingu lub serwera SMTP bez aktualizacji DNS.
- Wysyłanie poczty przez formularz lub aplikację, która używa innej domeny podpisu niż domena From.
- Mylenie domeny głównej z subdomeną wysyłkową.
- Nieczytanie pełnych nagłówków i poleganie wyłącznie na panelu dostawcy.
- Zakładanie, że „rekord jest, więc musi działać”.
- Ignorowanie wpływu pośredników, którzy modyfikują wiadomość po podpisaniu DKIM.
Ostrzeżenie bezpieczeństwa: nie wyłączaj SPF, DKIM ani DMARC „na chwilę”, jeśli domena służy do obsługi klientów, płatności lub logowania. Taka decyzja może obniżyć dostarczalność i ułatwić podszywanie się pod Twoją firmę. Jeśli trzeba testowo obniżyć politykę DMARC, rób to kontrolowanie i tylko na czas diagnostyki.
Kiedy nie robić tego samodzielnie
Samodzielna naprawa ma sens, gdy masz dostęp do DNS, rozumiesz podstawy poczty i potrafisz czytać nagłówki wiadomości. Ale są sytuacje, w których lepiej nie eksperymentować:
- gdy z jednej domeny wysyła wiele systemów i nie wiadomo, który generuje błędy,
- gdy firma ma bardzo dużą liczbę wiadomości i każda minuta przestoju jest kosztowna,
- gdy po zmianach poczta zaczęła znikać lub odbijać się masowo,
- gdy nie masz pewności, czy DNS jest zarządzany w tym samym miejscu, w którym faktycznie działa domena,
- gdy w grę wchodzą integracje z CRM, ERP, sklepem lub zewnętrznym newsletterem,
- gdy nie możesz odtworzyć, skąd dokładnie wychodzi wiadomość i kto ją podpisuje,
- gdy używasz kilku subdomen, regionalnych adresów lub wielu dostawców SMTP.
W takich przypadkach nietrafiona zmiana może pogorszyć sytuację bardziej niż sam problem początkowy. Najgorszy scenariusz to „naprawa” jednego błędu kosztem całkowitego rozbicia wysyłki z pozostałych systemów.
Kiedy zgłosić się do specjalisty
Do specjalisty warto zgłosić się wtedy, gdy problem wraca po każdej zmianie, gdy nie da się jednoznacznie określić źródła błędu albo gdy konfiguracja obejmuje wiele usług i domen. Pomoc eksperta jest szczególnie uzasadniona, gdy:
- potrzebujesz szybkiej naprawy bez długiego testowania,
- masz migrację poczty lub hostingu w toku,
- zarządzasz sklepem internetowym i poczta transakcyjna musi działać bez przerw,
- DMARC generuje sprzeczne raporty, których nie umiesz zinterpretować,
- nie masz pewności, czy problem dotyczy DNS, konfiguracji serwera, czy konkretnej aplikacji,
- chcesz uporządkować całą architekturę wysyłki, a nie tylko „odkręcić” jeden błąd.
Specjalista zwykle szybciej znajdzie przyczynę, bo patrzy na cały łańcuch: DNS, SMTP, aplikacje wysyłające, nagłówki, zgodność domen i polityki bezpieczeństwa. To oszczędza czas i ogranicza ryzyko dodatkowych przestojów.
Podsumowanie
Jeżeli SPF, DKIM i DMARC nie działają, problem rzadko polega na jednym prostym błędzie. Najczęściej chodzi o niedopasowanie między rekordami DNS, rzeczywistym źródłem wysyłki i domeną widoczną dla odbiorcy. Zanim zaczniesz cokolwiek poprawiać, zbierz pełne nagłówki wiadomości, ustal, który mechanizm zawodzi i sprawdź wszystkie systemy korzystające z tej domeny. Dopiero potem popraw SPF, zweryfikuj DKIM i dopasuj politykę DMARC do rzeczywistej infrastruktury.
Najważniejsza zasada brzmi: nie zgaduj, tylko diagnozuj. W przypadku poczty elektronicznej mały błąd w konfiguracji potrafi zablokować komunikację z klientami, obniżyć dostarczalność i osłabić reputację domeny. Jeśli konfiguracja jest złożona albo problem powraca, lepiej skorzystać z pomocy specjalisty niż ryzykować kolejne awarie.
CTA do kontaktu
Jeśli chcesz szybko ustalić, dlaczego SPF, DKIM lub DMARC nie działają w Twojej domenie, i potrzebujesz bezpiecznej naprawy bez ryzyka utraty poczty, skontaktuj się z R99.PL. Pomożemy zdiagnozować problem, uporządkować konfigurację DNS i przywrócić poprawne działanie wysyłki e-mail w Twojej firmie.
