Informacja reklamowa: serwis zawiera linki afiliacyjne. Możemy otrzymać prowizję po zakupie, ale nie podnosi to ceny dla użytkownika. Ceny, promocje i warunki mogą ulec zmianie.

Jak działa afiliacja?

Parametry hostingu

Dlaczego e-maile trafiają do spamu mimo SPF, DKIM i DMARC?

SPF, DKIM i DMARC mogą przechodzić poprawnie, a wiadomości nadal trafiać do spamu. Sprawdź reputację domeny i IP, PTR, skargi, alignment oraz rzeczywistą ścieżkę wysyłki.

Poprawny SPF, DKIM i DMARC nie gwarantują, że wiadomość trafi do skrzynki odbiorczej. Te mechanizmy odpowiadają przede wszystkim za uwierzytelnienie nadawcy i ochronę domeny przed podszywaniem się. Filtry antyspamowe biorą jednak pod uwagę również reputację domeny i adresu IP, zachowanie odbiorców, sposób wysyłki, infrastrukturę oraz charakter samej wiadomości.

Dlatego wynik spf=pass, dkim=pass i dmarc=pass jest bardzo dobrym punktem wyjścia, ale nie kończy diagnostyki dostarczalności.

SPF, DKIM i DMARC pomagają ustalić, czy wiadomość ma prawidłowe uwierzytelnienie i czy uwierzytelnione domeny są zgodne z domeną widoczną jako nadawca. Filtr spamu odpowiada na szersze pytanie: czy tę konkretną wiadomość od tego nadawcy umieścić w skrzynce odbiorczej?

Co właściwie daje poprawny SPF, DKIM i DMARC?

SPF pozwala sprawdzić, czy adres IP wysyłającego serwera jest uprawniony do wysyłki dla domeny używanej w SPF, zwykle domeny envelope sender. DKIM weryfikuje podpis kryptograficzny wiadomości, a DMARC sprawdza, czy uwierzytelniona domena SPF lub DKIM jest odpowiednio zgodna z domeną widoczną w polu From.

Poprawna konfiguracja ogranicza ryzyko odrzucania poczty z powodu braku uwierzytelniania i utrudnia podszywanie się pod domenę. Nie jest jednak systemem reputacyjnym ani gwarancją dostarczenia do Inbox. Jeżeli nie wiadomo jeszcze, czy WordPress przekazał wiadomość do transportu, najpierw ustal etap, na którym zatrzymała się wysyłka.

Jeśli nie masz jeszcze pewności, czy te mechanizmy są skonfigurowane prawidłowo, zacznij od poradnika SPF, DKIM i DMARC — jak poprawnie skonfigurować pocztę na hostingu.

Dlaczego wiadomość może trafić do spamu mimo poprawnego uwierzytelniania?

Najczęściej trzeba sprawdzić kilka niezależnych obszarów:

  • reputację domeny wysyłającej,
  • reputację adresu IP lub infrastruktury wysyłającej,
  • skargi użytkowników na spam,
  • jakość listy odbiorców,
  • nagłe zmiany wolumenu wysyłki,
  • poprawność reverse DNS i infrastruktury SMTP,
  • format wiadomości i jej nagłówki,
  • rodzaj wysyłanych treści,
  • sposób rozdzielenia poczty transakcyjnej i marketingowej.

To oznacza, że dwie wiadomości z tej samej domeny mogą przechodzić SPF, DKIM i DMARC, a mimo to być klasyfikowane inaczej.

Reputacja domeny ma znaczenie niezależnie od DMARC

Dostawcy poczty analizują historię wysyłki z danej domeny. Jeżeli duża część wcześniejszych wiadomości była zgłaszana jako spam, wysyłano niechcianą pocztę albo następowały gwałtowne zmiany zachowania, reputacja domeny może się pogorszyć.

Google udostępnia w Postmaster Tools osobny wskaźnik reputacji domeny. Oznacza to, że sama poprawność uwierzytelniania i reputacja są traktowane jako odrębne elementy oceny nadawcy.

W praktyce można więc mieć:

  • SPF: PASS,
  • DKIM: PASS,
  • DMARC: PASS,
  • a jednocześnie niską reputację domeny.

W takim przypadku poprawianie kolejny raz rekordów SPF nie musi niczego zmienić. Trzeba ustalić, dlaczego odbiorcy lub systemy antyspamowe źle oceniają wcześniejszą wysyłkę.

Reputacja adresu IP również może być problemem

Poczta jest wysyłana z konkretnej infrastruktury sieciowej. Odbiorca może więc oceniać nie tylko domenę, ale również adres IP serwera SMTP.

Ma to szczególne znaczenie na hostingu współdzielonym lub w usługach korzystających ze współdzielonych pul wysyłkowych. Jeden adres IP może obsługiwać wielu klientów. Operator powinien kontrolować nadużycia i reputację infrastruktury, ale właściciel pojedynczej strony nie zawsze ma wpływ na historię całej puli.

Z drugiej strony własny dedykowany adres IP nie jest automatycznie rozwiązaniem. Nowy adres nie ma jeszcze historii wysyłki, a źle prowadzona wysyłka może szybko zbudować mu słabą reputację.

PTR i reverse DNS — uwierzytelnianie to nie wszystko

Serwer wysyłający powinien mieć poprawnie skonfigurowany reverse DNS. Publiczny adres IP może mieć rekord PTR wskazujący nazwę hosta, a ta nazwa powinna prawidłowo rozwiązywać się z powrotem na adres używany do wysyłki.

Gmail wymienia poprawny forward i reverse DNS wśród wymagań dla nadawców. Oznacza to, że można mieć poprawny SPF i DKIM, a jednocześnie problem infrastrukturalny związany z nazwą serwera wysyłającego.

Na typowym hostingu współdzielonym konfiguracja PTR należy do operatora. Użytkownik domeny zwykle nie zmienia jej samodzielnie.

Wysoki poziom skarg na spam może zniszczyć dobrą konfigurację

Jeżeli odbiorcy regularnie klikają „Zgłoś spam”, poprawne rekordy DNS nie rozwiązują problemu. Taki sygnał oznacza dla dostawcy poczty, że użytkownicy nie chcą otrzymywać wiadomości od danego nadawcy.

Google zaleca utrzymywanie wskaźnika spamu raportowanego w Postmaster Tools poniżej 0,1% i unikanie poziomu 0,3% lub wyższego. Dla większych nadawców przekroczenie wymagań może dodatkowo utrudniać dostarczanie poczty.

Nie należy jednak traktować pojedynczego procentu jako uniwersalnego „wyniku dostarczalności”. Wskaźnik skarg jest jednym z sygnałów, a jego interpretacja zależy również od wolumenu i rodzaju wysyłki.

Lista odbiorców ma znaczenie

Problemy zaczynają się często przed wysłaniem pierwszej wiadomości. Jeżeli lista zawiera:

  • adresy bez świadomej zgody,
  • stare i nieaktywne skrzynki,
  • dużo błędnych adresów,
  • odbiorców, którzy od dawna nie reagują na wiadomości,
  • adresy pozyskane z przypadkowych źródeł,

to ryzyko odbić, skarg i negatywnych sygnałów rośnie.

Dobra konfiguracja DNS nie zmienia faktu, że odbiorca może uznać wiadomość za niechcianą.

Przy newsletterach i większej wysyłce ważniejsze od „mocniejszego SPF” jest więc to, kto naprawdę powinien otrzymywać wiadomość i czy ma łatwy sposób rezygnacji.

Nagły wzrost liczby wysyłanych wiadomości może pogorszyć dostarczalność

Filtry pocztowe analizują również sposób wysyłki w czasie. Domena, która przez miesiące wysyłała po kilkanaście wiadomości dziennie, a następnie zaczyna wysyłać tysiące wiadomości w krótkim czasie, zmienia swój profil zachowania.

Nie oznacza to, że każda większa kampania zostanie uznana za spam. Przy dużych zmianach wolumenu warto jednak kontrolować reputację, odbicia i skargi zamiast patrzeć tylko na poprawność rekordów DNS.

Microsoft również zaleca unikanie gwałtownej lub nadmiernej wysyłki oraz rozkładanie większego ruchu w czasie.

Poczta transakcyjna i marketingowa nie zawsze powinny korzystać z tej samej infrastruktury

Potwierdzenie zamówienia, reset hasła i faktura mają inny charakter niż newsletter lub kampania promocyjna.

Jeżeli cały ruch wychodzi z dokładnie tej samej domeny i infrastruktury, problem z wysyłką marketingową może wpływać na reputację poczty transakcyjnej.

Dlatego przy większej skali stosuje się czasem osobne subdomeny lub strumienie wysyłkowe, na przykład osobno dla wiadomości marketingowych i transakcyjnych.

Nie oznacza to jednak, że mała strona firmowa musi od razu budować skomplikowaną architekturę pocztową. Separacja ma największy sens wtedy, gdy rodzaje wysyłki mają wyraźnie różny wolumen, charakter i ryzyko skarg.

Czy treść wiadomości nadal ma znaczenie?

Tak, ale problemu nie da się sprowadzić do listy „zakazanych słów”. Współczesne systemy antyspamowe analizują znacznie więcej niż obecność pojedynczych wyrażeń typu „promocja” czy „gratis”.

Znaczenie mogą mieć między innymi:

  • format wiadomości,
  • spójność nadawcy i treści,
  • podejrzane lub wprowadzające w błąd linki,
  • załączniki,
  • nietypowa struktura HTML,
  • charakter wcześniejszej wysyłki nadawcy,
  • reakcje odbiorców.

Dlatego zmiana kilku słów w temacie wiadomości nie jest dobrym sposobem diagnozowania problemu, jeśli infrastruktura lub reputacja nadawcy są złe.

SPF i DKIM mogą przechodzić, ale DMARC może nadal mieć problem z alignment

W diagnostyce trzeba odróżniać samo pass mechanizmu od zgodności domen wymaganej przez DMARC.

SPF może zakończyć się wynikiem PASS dla domeny używanej w envelope sender, ale ta domena może być inna od domeny widocznej użytkownikowi w nagłówku From.

Podobnie DKIM może poprawnie zweryfikować podpis, lecz podpisująca domena może nie odpowiadać domenie From w sposób wymagany przez DMARC.

Dlatego nie wystarczy sprawdzić trzy osobne napisy „PASS”. Warto zobaczyć, która domena została faktycznie uwierzytelniona i czy DMARC potwierdził alignment.

Możesz wkleić nagłówki rzeczywistej wiadomości do analizatora nagłówków e-mail. Narzędzie interpretuje zapisane w wiadomości wyniki SPF, DKIM i DMARC, ale nie wykonuje ponownie kryptograficznej weryfikacji podpisu ani zapytania DNS z chwili dostarczenia.

Przekazywanie wiadomości może komplikować SPF

Wiadomość może być najpierw poprawnie wysłana do jednego systemu, a następnie automatycznie przekazana dalej. W takim scenariuszu adres IP systemu przekazującego może nie być uprawniony przez SPF domeny oryginalnego nadawcy.

To jeden z powodów, dla których DKIM jest ważnym uzupełnieniem SPF: podpis może przetrwać przekazanie wiadomości, o ile po drodze nie zmodyfikowano podpisanych elementów.

Nie oznacza to jednak, że każde przekazanie zachowa DKIM. Listy mailingowe, bramki bezpieczeństwa albo inne systemy mogą zmieniać treść i nagłówki.

Dlatego pojedynczy przypadek problemu po forwarding'u trzeba analizować na podstawie końcowych nagłówków wiadomości, a nie wyłącznie DNS domeny nadawcy.

Jak sprawdzić, dlaczego konkretna wiadomość trafiła do spamu?

Najlepiej zacząć od rzeczywistej wiadomości, która została sklasyfikowana jako spam.

  1. Pobierz pełne nagłówki wiadomości.
  2. Sprawdź Authentication-Results. Zobacz wyniki SPF, DKIM i DMARC oraz domeny użyte przy uwierzytelnianiu.
  3. Sprawdź Received. Ustal, przez jakie serwery przechodziła wiadomość.
  4. Sprawdź domenę i adres IP nadawcy.
  5. Porównaj wiadomość z inną wysłaną z tego samego systemu.
  6. Sprawdź ewentualny komunikat odbiorcy lub kod SMTP.
  7. Jeżeli wysyłasz istotny wolumen do Gmaila, sprawdź Postmaster Tools.

Nie warto zaczynać od wielokrotnej zmiany rekordu DMARC, jeśli konkretna wiadomość już poprawnie przechodzi DMARC.

Co można sprawdzić w Google Postmaster Tools?

Przy odpowiednim wolumenie danych Postmaster Tools może pokazywać między innymi:

  • współczynnik zgłoszeń spamu,
  • reputację domeny,
  • reputację adresów IP,
  • wyniki uwierzytelniania,
  • szyfrowanie transportu,
  • błędy dostarczania.

Dane nie są prezentowane dla każdego nadawcy w takim samym zakresie. Przy małym wolumenie część paneli może nie mieć wystarczającej ilości informacji do wyświetlenia.

Brak danych w Postmaster Tools nie powinien być więc interpretowany jako potwierdzenie dobrej reputacji.

Co oznacza niski spam rate, ale słaba reputacja?

Te dwie wartości nie muszą być sprzeczne.

Google zwraca uwagę, że wskaźnik spamu w Postmaster Tools pokazuje wiadomości dostarczone do skrzynki odbiorczej, które użytkownicy następnie oznaczyli jako spam. Jeśli duża część ruchu jest już automatycznie kierowana do folderu Spam, mniej takich wiadomości trafia do Inbox i może zostać ręcznie zgłoszonych.

Dlatego bardzo niski widoczny spam rate nie zawsze oznacza, że filtr traktuje nadawcę dobrze.

Czy problem może wynikać z hostingu współdzielonego?

Może, ale nie należy zakładać tego bez sprawdzenia.

Na współdzielonej infrastrukturze wysyłkowej kilku lub wielu klientów może korzystać z tej samej puli IP. Jeżeli operator źle kontroluje nadużycia, reputacja infrastruktury może ucierpieć.

Z drugiej strony profesjonalny dostawca może aktywnie izolować podejrzany ruch, monitorować reputację i przenosić problematyczne wiadomości do osobnych pul. Sam fakt współdzielenia IP nie jest więc dowodem złej dostarczalności.

Przed zmianą hostingu warto ustalić, czy problem dotyczy rzeczywiście infrastruktury operatora, czy raczej domeny, listy odbiorców albo sposobu wysyłki.

Wysyłka z formularza WordPress — częsty osobny problem

Formularz kontaktowy może wysyłać wiadomości w inny sposób niż zwykła skrzynka pocztowa użytkownika. Jeśli strona korzysta z lokalnej funkcji PHP, lokalnego MTA albo nieprawidłowo skonfigurowanego SMTP, ścieżka wysyłki może mieć inne uwierzytelnianie i reputację.

Dlatego fakt, że wiadomość wysłana ręcznie z Webmaila dociera do Inbox, nie dowodzi jeszcze, że wiadomości z formularza WordPressa korzystają z identycznej infrastruktury.

Warto wysłać osobne wiadomości testowe:

  • z Webmaila lub klienta pocztowego,
  • z formularza WordPressa,
  • z WooCommerce lub innego systemu transakcyjnego.

Następnie porównaj ich nagłówki. Różnice w DKIM, Return-Path, serwerze wysyłającym lub domenie uwierzytelniającej często od razu pokazują, że ruch nie wychodzi tą samą drogą.

Nie testuj dostarczalności tylko jednym adresem

Jedna wiadomość do jednej skrzynki nie opisuje całej dostarczalności domeny.

Ta sama wiadomość może zostać inaczej sklasyfikowana przez Gmaila, Outlooka i innego operatora pocztowego. Różnić może się również zachowanie dla dwóch użytkowników tej samej usługi, ponieważ filtry mogą uwzględniać indywidualne interakcje odbiorcy z nadawcą.

Przy diagnozie warto więc ustalić, czy problem:

  • występuje u jednego odbiorcy,
  • dotyczy jednej usługi pocztowej,
  • pojawia się dla większości odbiorców,
  • dotyczy tylko wiadomości marketingowych,
  • dotyczy również poczty transakcyjnej.

To znacznie zawęża listę możliwych przyczyn.

Co zrobić krok po kroku, gdy wiadomości trafiają do spamu?

  1. Sprawdź konkretną wiadomość, nie tylko DNS. Pobierz pełne nagłówki.
  2. Potwierdź SPF, DKIM i DMARC oraz alignment.
  3. Sprawdź ścieżkę wysyłki. Ustal serwer i adres IP.
  4. Sprawdź reverse DNS/PTR infrastruktury wysyłającej.
  5. Porównaj różne źródła poczty. Webmail, WordPress, WooCommerce, newsletter.
  6. Sprawdź odbicia i kody SMTP.
  7. Zweryfikuj reputację i skargi. Przy Gmailu wykorzystaj Postmaster Tools, jeśli masz dostępne dane.
  8. Sprawdź jakość listy odbiorców.
  9. Oceń, czy nie nastąpił gwałtowny wzrost wysyłki.
  10. Dopiero potem zmieniaj konfigurację.

Jeżeli chcesz równolegle sprawdzić publiczne rekordy domeny, możesz użyć diagnostyki domeny. To jednak inny rodzaj kontroli niż analiza nagłówków konkretnej dostarczonej wiadomości.

Czego nie robić?

  • Nie zmieniaj ciągle SPF, jeśli wiadomość już przechodzi SPF.
  • Nie ustawiaj od razu ostrzejszego DMARC w nadziei, że poprawi to reputację.
  • Nie kupuj przypadkowej „dedykowanej reputacji IP” bez ustalenia przyczyny problemu.
  • Nie wysyłaj kolejnych dużych partii wiadomości tylko po to, aby „rozgrzać domenę”.
  • Nie zakładaj, że problemem jest hosting, jeśli nie sprawdziłeś rzeczywistego IP i ścieżki wysyłki.
  • Nie oceniaj całej domeny na podstawie jednego testowego e-maila.

Najważniejsze wnioski

  • SPF, DKIM i DMARC są bardzo ważne, ale nie gwarantują dostarczenia do Inbox;
  • wiadomość może przechodzić wszystkie trzy mechanizmy i nadal mieć problem z reputacją domeny lub IP;
  • skargi użytkowników, lista odbiorców i sposób wysyłki wpływają na klasyfikację wiadomości;
  • poprawny PTR i infrastruktura SMTP są osobnym elementem od SPF/DKIM/DMARC;
  • wysyłka z WordPressa może korzystać z innej ścieżki niż zwykła skrzynka pocztowa;
  • przy diagnozie najwięcej informacji daje konkretna wiadomość wraz z pełnymi nagłówkami;
  • niski spam rate nie zawsze oznacza dobrą reputację;
  • zanim zmienisz hosting lub usługę pocztową, warto ustalić, czy problem rzeczywiście leży po stronie infrastruktury.

Źródła

  1. Google — Wskazówki dla nadawców e-maili — uwierzytelnianie, DNS/PTR i wymagania dotyczące wskaźnika spamu.
  2. Google — Panele Postmaster Tools — reputacja domeny i IP, spam rate, uwierzytelnianie oraz interpretacja niskiego spam rate przy słabej reputacji.
  3. Google — Konfigurowanie Postmaster Tools — zakres danych dostępnych w narzędziu.
  4. Microsoft Learn — Anti-spam protection FAQ — reputacja, PTR i dobre praktyki wysyłki.
  5. Microsoft Learn — Outbound spam protection — ochrona reputacji infrastruktury i separacja ruchu wysokiego ryzyka.
  6. Microsoft Learn — Outbound delivery pools — osobne pule IP dla ruchu klasyfikowanego jako wysokiego ryzyka.
  7. RFC 7208 — Sender Policy Framework (SPF).
  8. RFC 6376 — DomainKeys Identified Mail (DKIM).
  9. RFC 9989 — Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — aktualna specyfikacja DMARC zastępująca RFC 7489 i RFC 9091.

Źródła

  1. Google — Wskazówki dla nadawców e-maili — dostęp: 30.09.2026
  2. Google — Panele Postmaster Tools — dostęp: 30.09.2026
  3. Google — Konfigurowanie Postmaster Tools — dostęp: 30.09.2026
  4. Microsoft Learn — Anti-spam protection FAQ — dostęp: 30.09.2026
  5. Microsoft Learn — Outbound spam protection — dostęp: 30.09.2026
  6. Microsoft Learn — Outbound delivery pools — dostęp: 30.09.2026
  7. RFC 7208 — Sender Policy Framework (SPF) — dostęp: 30.09.2026
  8. RFC 6376 — DomainKeys Identified Mail (DKIM) — dostęp: 30.09.2026
  9. RFC 9989 — Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — dostęp: 30.09.2026