Maile trafiają do spamu: jak to naprawić krok po kroku

W większości przypadków winne są trzy rekordy DNS: SPF, DKIM i DMARC. Ten tekst prowadzi Cię przez nie tak, żebyś naprawił je sam, bez kupowania czegokolwiek. Jest też druga część, o której nie pisze prawie nikt: czasem poczta wpada do spamu dlatego, że Twoja własna strona wysyła spam, a domena albo adres IP wylądowały na czarnej liście. Wtedy najlepiej ustawione rekordy nic nie dadzą. Jak czytać ten tekst: przy każdej liczbie i każdym mocnym twierdzeniu podaję źródło w nawiasie. Tam, gdzie piszę z własnej praktyki, a nie ze źródła, zaznaczam to słowem "ocena". Tam, gdzie czegoś nie udało mi się potwierdzić, piszę o tym wprost, zamiast zmyślać. ---

Od czego zacząć: diagnostyka w 10 minut

Zanim cokolwiek zmienisz, zbierz fakty. Poniższe pięć kroków robi się szybciej niż napisanie zgłoszenia do hostingu.

Krok 1. Przeczytaj nagłówki jednej wiadomości, która wpadła do spamu

W kliencie pocztowym otwórz podgląd źródła wiadomości i znajdź linię Authentication-Results. Zobaczysz w niej trzy wyniki: spf=, dkim= i dmarc=. To jedyne miejsce, w którym widzisz, co naprawdę zobaczył serwer odbiorcy, a nie co Ci się wydaje, że jest ustawione. Jeśli nie masz takiej wiadomości pod ręką, wyślij testową na swoją skrzynkę u dużego dostawcy i otwórz jej źródło.

Co oznaczają wyniki, które tam zobaczysz:

• pass: mechanizm zadziałał,
• none: dla tej domeny nie ma rekordu, nie ma czego sprawdzać,
• fail lub softfail: rekord istnieje, ale ten serwer nie jest w nim uprawniony do wysyłki,
• permerror: rekord jest zepsuty składniowo i nie da się go zinterpretować. Standard opisuje to jako stan, który "definitely requires DNS operator intervention to be resolved" (RFC 7208, sekcja 2.6.7). Czyli: to nie jest drobna usterka, tylko rekord, który nie działa w ogóle.

Jeśli w tej samej linii widzisz dmarc=fail mimo spf=pass, przeskocz od razu do części o wyrównaniu (alignment). To bardzo częsty przypadek.

Krok 2. Sprawdź swoje rekordy z konsoli, bez rejestracji w żadnym serwisie

Windows, PowerShell:

Resolve-DnsName twojadomena.pl -Type TXT
Resolve-DnsName _dmarc.twojadomena.pl -Type TXT

Linux i macOS:

dig TXT twojadomena.pl
dig TXT _dmarc.twojadomena.pl

Wszędzie, także w cmd na Windows:

nslookup -type=TXT twojadomena.pl
nslookup -type=TXT _dmarc.twojadomena.pl

W odpowiedzi dostaniesz wszystkie rekordy TXT domeny. SPF to ten zaczynający się od v=spf1. Jeśli takich wpisów jest dwa, masz od razu błąd numer jeden z listy poniżej.

DKIM sprawdzisz tylko wtedy, gdy znasz selektor: rekord leży pod nazwą selektor._domainkey.twojadomena.pl. Selektor odczytasz z nagłówka DKIM-Signature wysłanej wiadomości, z pola s= (RFC 6376).

To najuczciwsze narzędzie w całym temacie: nic nie kosztuje, nie ma limitów i pokazuje dokładnie to, co widzi serwer odbiorcy.

Krok 3. Sprawdź PTR, czyli rekord odwrotny

Google wymaga od wszystkich nadawców, nie tylko masowych, żeby domeny lub adresy IP miały poprawne rekordy w przód i wstecz: "Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records" (Google, Email sender guidelines, support.google.com/a/answer/81126, wymagania obowiązują od 1 lutego 2024). Na tanim VPS-ie PTR bardzo często nie jest ustawiony w ogóle, a ustawia go dostawca serwera, nie Ty w panelu DNS.

Jeśli wysyłasz przez hosting współdzielony, tego kroku i tak nie naprawisz sam: adres IP nie jest Twój i to hosting odpowiada za jego rekord odwrotny.

Krok 4. Sprawdź, czy nie jesteś na czarnej liście

Sprawdź osobno adres IP i osobno domenę, bo to są różne listy: Spamhaus SBL zawiera wyłącznie adresy IP, a DBL wyłącznie nazwy domen ("It ONLY lists domains. No IP addresses are listed in the DBL", spamhaus.org/blocklists/domain-blocklist/).

Narzędzia: Spamhaus IP & Domain Reputation Checker (check.spamhaus.org) oraz multirbl.valli.org, który sprawdza adres IP w wielu listach naraz i robi test FCrDNS. Nie podaję liczby list, bo źródła podają różne wartości.

Krok 5. Zajrzyj do panelu hostingu i do Search Console

W OVH web hosting ma osobny status wysyłki poczty ze skryptów: zielony (Enabled, Force) oznacza, że wysyłka działa, czerwony (Disabled, Bounce, spam) że została zatrzymana (docs.ovhcloud.com, "Monitoring and managing automated emails in your web hosting plan"). W Google Search Console raport Security Issues pokazuje, czy Google wykrył na stronie zhakowaną treść lub malware (support.google.com/webmasters/answer/9044101). Oba sprawdzenia zajmują minutę i dotyczą już drugiej części tego tekstu.

Uczciwie: czego nie sprawdziłem

• Nie podaję limitów darmowych testów w mail-tester.com, MXToolbox ani dmarcian, bo nie zweryfikowałem ich warunków u źródła. Serwisów możesz używać, ale liczb ode mnie nie dostaniesz.
• Krąży informacja, że "od listopada 2025 Gmail zaostrza egzekwowanie wymagań". Sprawdziłem stronę wymagań Google i takiej daty tam nie ma. Nie powtarzam jej.
• Co do Google Postmaster Tools: oficjalna pomoc wymienia osiem paneli, część źródeł wtórnych twierdzi, że panele reputacji IP i domeny zostały usunięte. Bezpiecznie jest patrzeć na dwa, które wymieniają wszyscy: Spam rate i Compliance status.

---

SPF, DKIM i DMARC prostym językiem, i pięć błędów, które je psują

Co robi każdy z nich

SPF mówi: "te serwery mogą wysyłać pocztę w imieniu mojej domeny". Kluczowa rzecz, przez którą ludzie tracą całe dnie: SPF sprawdza adres z koperty SMTP, czyli MAIL FROM, a nie adres w polu From, który widzi człowiek. Standard mówi wprost: "SPF verifiers MUST check the 'MAIL FROM' identity" (RFC 7208, sekcja 2.4). Adres z koperty serwer odbiorcy zwykle zapisuje potem w nagłówku Return-Path, i to tam go zobaczysz. Dlatego można mieć poprawny SPF i dalej mieć problem.

DKIM dokłada do wiadomości podpis kryptograficzny, którym domena potwierdza, że to jej wiadomość i że nie została po drodze zmieniona (RFC 6376).

DMARC spina jedno z drugim: sprawdza, czy domena z widocznego pola From zgadza się z domeną, którą potwierdził SPF albo DKIM, i mówi odbiorcy, co zrobić, gdy się nie zgadza. DMARC został przewydany jako RFC 9989, który zastępuje RFC 7489 i RFC 9091 ("This document obsoletes RFCs 7489 and 9091", rfc-editor.org/rfc/rfc9989.html). Większość poradników w sieci ciągle cytuje starą wersję.

Wyrównanie (alignment), czyli powód numer jeden dla "SPF mam, a i tak spam"

DMARC wymaga zgodności domen. W trybie relaxed wystarczy ta sama domena organizacyjna, w trybie strict domeny muszą się zgadzać dokładnie (RFC 9989). Typowa sytuacja: skrypt wysyła przez serwer hostingu, koperta jest podpisana domeną hostingu, SPF przechodzi bez zarzutu, a w polu From stoi Twoja domena. Wyrównania nie ma, DKIM-u nie ma, DMARC leci na fail.

Pięć błędów w SPF, wszystkie ze wskazaniem w standardzie

1. Dwa rekordy SPF zamiast jednego. Klasyka po podpięciu drugiego systemu mailingowego: zamiast poprawić istniejący rekord, ktoś dodaje kolejny. Standard: "A domain name MUST NOT have multiple records...", a wynikiem jest permerror (RFC 7208, sekcje 3.2 i 4.5). Dwa rekordy to nie "dwa razy lepiej", tylko zero.
2. Przekroczony limit dziesięciu zapytań DNS. "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation" (RFC 7208, sekcja 4.6.4). Liczą się include, a, mx, ptr, exists i redirect. Nie liczą się ip4, ip6, all ani modyfikator exp. Haczyk polega na tym, że cudzy include może zawierać kolejne include i zjada Twój limit po cichu.
3. Martwe wpisy w rekordzie, czyli void lookups. Void lookup to zapytanie, które nie zwróciło żadnego rekordu albo zwróciło NXDOMAIN. Standard zaleca ograniczyć je do dwóch (RFC 7208, sekcja 4.6.4, sformułowanie SHOULD). Limit dziesięciu formalnie nie przekroczony, a SPF i tak może skończyć się błędem, bo w rekordzie został include po usługi, której już nie używasz.
4. Błąd składni. "if there are any syntax errors anywhere in the record, check_host() returns immediately with the result 'permerror'" (RFC 7208, sekcja 4.6). Jedna literówka wyłącza cały rekord, nie jego fragment.
5. Miękkie ~all tam, gdzie domena jest już gotowa na -all. -all to jasne stwierdzenie, że host nie jest uprawniony, ~all to tylko słaba sugestia, że "prawdopodobnie" nie jest (RFC 7208, sekcja 8). ~all jest sensowne na czas wdrożenia. Zostawione na lata jest po prostu niedokończoną robotą.

DKIM: pułapka przy ręcznym wpisywaniu

Google zaleca klucz 2048-bitowy, a 1024 tylko wtedy, gdy operator DNS nie obsługuje dłuższych (support.google.com/a/answer/174124). Klucz 2048-bitowy nie mieści się w jednym łańcuchu TXT, bo limit pojedynczego łańcucha to 255 znaków. Trzeba go wpisać jako kilka łańcuchów w cudzysłowach, jeden po drugim, w tym samym polu Value. Jeśli DKIM "nie działa bez powodu", zacznij od sprawdzenia, czy panel DNS nie obciął Ci klucza.

DMARC: zacznij od p=none

Tag p= przyjmuje trzy wartości: none (właściciel domeny nie wyraża preferencji), quarantine (uznaje takie wiadomości za podejrzane), reject (uznaje niepowodzenie za wyraźny znak nadużycia) (RFC 9989).

Ważna i uspokajająca informacja: Google i Yahoo dla nadawców masowych wymagają DMARC, ale wystarczy im p=none (support.google.com/a/answer/81126; senders.yahooinc.com/best-practices/). Bariera wejścia jest więc niska. Zacznij od p=none, zbieraj raporty, dopiero potem zaostrzaj.

Czego wymagają duzi dostawcy

• Google, od wszystkich nadawców, od 1 lutego 2024: SPF albo DKIM, połączenie TLS, poprawne rekordy w przód i wstecz (PTR), format zgodny z RFC 5322, jeden adres w polu From i utrzymanie wskaźnika skarg w Postmaster Tools poniżej 0,3 procent. Wiadomości bez uwierzytelnienia mogą zostać odrzucone błędem 5.7.26 (support.google.com/a/answer/81126).
• Google, dla nadawców masowych (blisko 5000 wiadomości na prywatne konta Gmail w ciągu 24 godzin, support.google.com/a/answer/14229414): SPF i DKIM, DMARC co najmniej p=none, wyrównanie oraz wypisanie jednym kliknięciem dla mailingów.
• Uwaga na dwie różne liczby. 0,3 procent to granica naruszenia, natomiast w poradniku "Top 10 Gmail sender issues" Google zaleca trzymać się poniżej 0,1 procent (support.google.com/mail/answer/15256272). To zalecany zapas, nie to samo co próg.
• Yahoo, od lutego 2024: minimum SPF albo DKIM dla wszystkich, dla masowych oba plus DMARC, przy czym "DMARC must pass", wyrównanie z domeną SPF albo DKIM, działający nagłówek wypisania, obsługa wypisań w ciągu 2 dni i wskaźnik skarg poniżej 0,3 procent (senders.yahooinc.com/best-practices/). Yahoo nie podaje progu ilościowego, od którego jesteś nadawcą masowym. Nie przypisuj im liczby 5000, jej tam nie ma.
• Microsoft, od 5 maja 2025: domeny wysyłające ponad 5000 wiadomości dziennie na konsumenckie adresy Outlook muszą mieć SPF, DKIM i DMARC (minimum p=none z wyrównaniem). Najpierw taka poczta trafiała do Junk, potem Microsoft zaczął odrzucać ją komunikatem "550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level" (techcommunity.microsoft.com, "Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders").

Polityki DMARC dużych skrzynek, stan na 1 sierpnia 2026

Sprawdziłem to zapytaniami DNS 1 sierpnia 2026 przez resolver 8.8.8.8. Możesz powtórzyć: nslookup -type=TXT _dmarc.yahoo.com.

| Domena | Polityka |

|---|---|

| gmail.com | p=none, sp=quarantine |

| yahoo.com | p=reject, pct=100 |

| aol.com | p=reject, pct=100 |

| onet.pl | p=quarantine, sp=quarantine |

| wp.pl | p=none |

| o2.pl | p=none |

| interia.pl | p=none |

Polityki się zmieniają, więc traktuj to jako zdjęcie z jednego dnia, a nie stałą. Praktyczny wniosek z tej tabeli jest w części o formularzach.

Najczęstszy przypadek: rekord "jest", więc nikt go nie sprawdza

Typowy rekord, który widuję u klientów, wygląda mniej więcej tak:

v=spf1 ip4:twojadomena.pl ~all

Wygląda sensownie i dlatego nikt go nie rusza latami. A jest niepoprawny składniowo: mechanizm ip4: przyjmuje wyłącznie literał adresu IPv4 w postaci czterech liczb, a nie nazwę hosta (RFC 7208, sekcja 5.6). Skoro jest błąd składni, cały rekord daje permerror (sekcja 4.6), czyli SPF nie działa wcale. Poprawna wersja to albo ip4: z konkretnym adresem, albo a: czy include: z nazwą.

Morał jest prosty: obecność rekordu nie znaczy, że on działa. Sprawdź swój komendą z kroku 2, zamiast zakładać.

Poczta wysyłana przez samą stronę: dlaczego mail() to nie to samo co uwierzytelniony SMTP

Do tej pory mówiliśmy o poczcie, którą wysyłasz z programu pocztowego. Wiadomości generowane przez stronę (formularz kontaktowy, rejestracja, status zamówienia w sklepie) to osobna historia i to one najczęściej giną.

Trzy rzeczy, które robi funkcja mail() w PHP

1. Zwraca sukces za przyjęcie, nie za doręczenie. Dokumentacja PHP mówi to wprost: "Returns true if the mail was successfully accepted for delivery... It is important to note that just because the mail was accepted for delivery, it does NOT mean the mail will actually reach the intended destination" (php.net/manual/en/function.mail.php). Stąd bierze się klasyk: formularz pokazuje "Dziękujemy, wiadomość wysłana", a wiadomości nie ma. Strona naprawdę nie wie, czy doszła.
2. Nadawca koperty domyślnie nie jest Twój. Żeby go ustawić, trzeba go podać ręcznie przez parametr dodatkowy i opcję -f sendmaila (php.net, tamże). Bez tego kopertę podpisuje użytkownik systemowy serwera WWW na technicznej nazwie hosta.
3. Nie nadaje się do większych ilości. "the mail() function is not suitable for larger volumes of email in a loop. This function opens and closes an SMTP socket for each email" (php.net, tamże). To dotyczy zwłaszcza sklepów rozsyłających statusy zamówień.

Twórcy PHPMailera, biblioteki używanej przez większość CMS-ów, są jeszcze bardziej bezpośredni: "The PHP mail() function usually sends via a local mail server, typically fronted by a sendmail binary", "The vast majority of code that you'll find online that uses the mail() function directly is just plain wrong, if not unsafe!", "It's both faster and safer to use SMTP to localhost" (github.com/PHPMailer/PHPMailer, README).

Wniosek, nie statystyka

Składając powyższe: wiadomość wysłana przez mail() typowo nie ma jak przejść DMARC. Koperta jest podpisana domeną techniczną serwera, więc SPF sprawdza się dla cudzej domeny i nie wyrównuje z Twoją domeną w polu From. Lokalny sendmail zwykle nie podpisuje wiadomości DKIM-em, więc drugiej drogi do wyrównania też nie ma. Dalej, zgodnie z opublikowanymi zasadami Google, Yahoo i Microsoft, taka wiadomość zgodnie z regułami idzie do spamu albo zostaje odrzucona.

Zaznaczam wyraźnie: to jest wniosek z reguł, nie pomiar. Nie istnieje publiczna statystyka mówiąca, jaki procent wiadomości z formularzy nie dochodzi, i nie zamierzam takiej wymyślać.

Co z tym zrobić

Przełącz wysyłkę na SMTP. W Joomli: Konfiguracja globalna, zakładka Serwer, parametr Mailer, do wyboru PHP Mail, Sendmail i SMTP. Domyślną wartością jest PHP Mail. Po wybraniu SMTP uzupełniasz host, port i szyfrowanie: zwykle 25 przy braku szyfrowania, 465 przy SSL/TLS, 587 przy STARTTLS. Ustawienia zapisują się w pliku configuration.php w katalogu głównym (docs.joomla.org, J4.x Global Configuration). W WordPressie i PrestaShopie odpowiednik siedzi w ustawieniach poczty albo we wtyczce SMTP, ale sens jest ten sam: wysyłaj przez uwierzytelniony serwer, który podpisze wiadomość DKIM-em.

Popraw pole From w formularzu. Najczęstszy błąd: wstawianie w From adresu odwiedzającego, żeby dało się kliknąć Odpowiedz. Wtedy w From stoi gmail.com albo yahoo.com, a Twój serwer nie jest dla tych domen uprawniony, więc wyrównanie jest z definicji niemożliwe. Spójrz na tabelę polityk wyżej: yahoo.com i aol.com stoją na p=reject, więc to nie jest "może trafi do spamu", tylko odrzucenie. Google ostrzega osobno: "Gmail will begin using a DMARC quarantine enforcement policy, and impersonating Gmail From: headers might impact your email delivery" (support.google.com/mail/answer/81126).

Poprawnie: w From własna domena strony, adres odwiedzającego w Reply-To. To zmiana na pięć minut i bardzo często sama załatwia sprawę.

Jeśli wysyłasz newsletter albo powiadomienia marketingowe, dodaj wypisanie jednym kliknięciem zgodnie z RFC 8058: nagłówek List-Unsubscribe musi zawierać adres HTTPS, a List-Unsubscribe-Post dokładnie wartość List-Unsubscribe=One-Click. Szczegół, który prawie wszyscy pomijają: oba te nagłówki muszą być objęte podpisem DKIM i wymienione w tagu h= (RFC 8058). Bez DKIM-u wypisanie jednym kliknięciem po prostu nie działa.

Sprawdź limity swojego hostingu. cyber_Folks podaje dla standardowego hostingu 1000 wiadomości na dobę, 300 co 15 minut i 100 odbiorców na jedną wysyłkę, a dla hostingu WooCommerce 5000 na dobę: "Przekroczenie limitu powoduje blokadę możliwości wysłania maili" (cyberfolks.pl/pomoc/jakie-sa-limity-dla-kont-pocztowych/). nazwa.pl podaje 1000 wiadomości na dobę i 100 odbiorców (nazwa.pl/parametry-bezpieczenstwa/). Zapamiętaj tę liczbę, bo za chwilę będzie ważna diagnostycznie.

---

A jeśli wszystko jest ustawione poprawnie, a poczta dalej ląduje w spamie

Zanim przejdziesz dalej: jeśli nie przeszedłeś jeszcze przez rekordy i przez ustawienia wysyłki ze strony, wróć tam. W większości przypadków sprawa kończy się w tamtych dwóch częściach. Ta sekcja jest o scenariuszu rzadszym, ale takim, którego sprawdzanie rekordów nie wykryje nigdy.

Jest jedno zdanie w specyfikacji SPF, które tłumaczy dlaczego:

> "an SPF pass does not mean the message is not spam or otherwise problematic" (RFC 7208, sekcja 11.2, rozdział zatytułowany "SPF-Authorized Email May Contain Other False Identities")

SPF, DKIM i DMARC odpowiadają wyłącznie na pytanie "czy ten serwer ma prawo wysyłać w imieniu tej domeny". Żaden z nich nie ocenia treści. I teraz najważniejsze: rekordy nie zatrzymają wysyłki, która idzie z serwera Twojego hostingu, bo ten serwer sam wpisałeś do swojego SPF. Jeśli skrypt podstawia w kopercie Twoją domenę, SPF przechodzi. Jeśli hosting podpisuje całą wychodzącą pocztę DKIM-em, podpis też się zgadza, i taka wysyłka wygląda dla świata jak Twoja.

A nawet jeśli ten spam niczego nie przechodzi (typowy skrypt na mail() nie przechodzi, patrz poprzednia część), problem zostaje, bo liczy się reputacja adresu IP i domeny. Wysyłka z Twojego konta psuje reputację adresu IP hostingu i może wciągnąć ten adres albo Twoją domenę na czarną listę. Wtedy odbijają się także Twoje normalne wiadomości. Idealne rekordy DNS w tym scenariuszu nie pomagają. To nie jest chwyt na klienta, tylko prosty wniosek ze specyfikacji i z zasad działania list.

Skąd bierze się wysyłka ze strony

• Skrypty mailerów wgrane przez atakującego. Pojedyncze pliki PHP, często o losowych nazwach, których jedynym zadaniem jest masowa wysyłka. Sucuri w raporcie za 2023 rok znalazło malware typu mailer na 5,79 procent skompromitowanych stron, a treści phishingowe na 5,06 procent (sucuri.net/reports/2023-hacked-website-report/). To nie jest najczęstsza infekcja i nie zamierzam udawać, że jest.
• Backdoory, które pozwalają wracać. W tym samym raporcie backdoora miało 49,21 procent skompromitowanych stron. To wyjaśnia, dlaczego usunięcie jednego pliku zwykle nic nie daje.
• Wstrzyknięcie nagłówków przez formularz kontaktowy. Jeśli aplikacja skleja nagłówki wiadomości z nieprzefiltrowanych danych z formularza, wystarczy, że w pole imienia trafi sekwencja CRLF, żeby atakujący dopisał własne nagłówki, na przykład Bcc, a przy dwóch takich sekwencjach także własną treść. Formularz staje się de facto przekaźnikiem spamu (acunetix.com, "What Are Email Injection Attacks"; sonarsource.com, "Why mail() is dangerous in PHP").
• Boty na formularzu bez captchy. To nie jest nawet włamanie, a skutek ten sam. OVH pisze wprost: "The absence of a captcha on an open sending form is one of the most frequent causes of shared hosting being blocked for spam", a boty "exploit it to send thousands of emails within minutes through your hosting, causing the shared IP address to be blocked" (docs.ovhcloud.com, "Web Hosting: Email sending best practices"). Zabezpieczenie to trzy rzeczy, które OVH wymienia w tym samym miejscu: captcha, limit wysyłek na adres IP po stronie serwera i filtrowanie każdego pola formularza.

Uwaga na słownictwo: klasyczny open relay to dziś rzadkość, odsetek nadawców będących otwartymi przekaźnikami spadł z ponad 90 procent do wyraźnie poniżej 1 procent (en.wikipedia.org/wiki/Open_mail_relay). Nikt Ci nie zrobił z serwera open relaya. Skrypt na stronie po prostu wysyła przez lokalny serwer pocztowy hostingu z uprawnieniami zaufanego konta.

Po czym poznać, że to ten scenariusz

Objawy, które w mojej praktyce są mocnym sygnałem (ocena, nie dane):

1. Hosting sam zmienił Ci hasło do skrzynki. home.pl robi to na podstawie analizy logów SMTP albo otrzymanych skarg na rozsyłanie spamu (pomoc.home.pl, "Dlaczego home.pl zmieniło hasło do mojej skrzynki e-mail"). Jeśli to się stało, coś z Twojego konta wysyłało.
2. Odbijasz się od dobowego limitu wysyłki, choć wysyłasz 20 wiadomości dziennie. Przy limicie 1000 na dobę to znaczy, że wysyła nie człowiek.
3. Panel hostingu pokazuje wysyłkę jako zatrzymaną (w OVH status Disabled, Bounce, spam), a na maila przyszła wiadomość o temacie "Abuse with your domain.tld hosting". OVH wymienia dwie przyczyny wprost: "Robot operation on a contact form" oraz "Malicious file injected into your hosting system" (docs.ovhcloud.com).
4. Kolejka poczty jest zapchana, pełna identycznych wiadomości do adresów, których nie znasz.

Objawy, które nie są dowodem włamania, choć wyglądają groźnie:

• Zalew wiadomości od MAILER-DAEMON o listach, których nie wysyłałeś. To backscatter: ktoś podszył się pod Twój adres, a serwery odbiorców odsyłają raporty o niedoręczeniu na sfałszowany adres (en.wikipedia.org/wiki/Backscatter_(email)). Rozstrzyga to kolejka na serwerze: jeśli odbicia przychodzą, a Twoja kolejka wychodząca jest pusta, to jest podszycie, a nie Twoja wysyłka.
• Spam "od siebie samego". home.pl tłumaczy to tak: "Pamiętaj, że żadna z tych sytuacji nie oznacza, że skrzynka e-mail została przejęta/skradziona", zwykle chodzi o "sfałszowanie adresu nadawcy" (pomoc.home.pl, "Co zrobić, jeśli otrzymuję spam z własnego adresu e-mail").
• Twój domowy adres IP na liście PBL. PBL to zbiór zakresów użytkowników końcowych, z których poczta nie powinna wychodzić bezpośrednio, obejmuje ponad 1,4 miliarda adresów IPv4 (spamhaus.org/blocklists/policy-blocklist/). To polityka, nie kara, i z Twoją stroną nie ma nic wspólnego.

Jak to sprawdzić technicznie

Zajrzyj do kolejki poczty (potrzebny dostęp SSH i zwykle uprawnienia roota, czyli w praktyce VPS albo serwer dedykowany):

exim -bp                 # kolejka w Exim, odpowiednik mailq
exiqgrep -f nadawca      # filtrowanie kolejki po nadawcy
exim -Mvh ID             # nagłówki konkretnej wiadomości
postqueue -p             # kolejka w Postfix
postcat -q ID            # zawartość konkretnej wiadomości

(docs.directadmin.com, "Maintaining email queue"; dokumentacja Postfiksa)

Najlepszy pojedynczy test, jaki znam. Otwórz nagłówki wiadomości z kolejki i poszukaj X-PHP-Originating-Script:

• Nagłówek jest: wiadomość wyszła z funkcji mail() w PHP, czyli wysyła ją skrypt na stronie. W nagłówku znajdziesz UID użytkownika i nazwę skryptu.
• Nagłówka nie ma: to wskazówka, że wiadomość poszła przez SMTP z prawdziwymi danymi logowania, czyli prędzej wyciekło hasło do skrzynki, niż została zhakowana strona (nullalo.com, "Postfix: how to identify a PHP script sending spam").

Zanim wyciągniesz ten drugi wniosek, sprawdź dwie rzeczy, bo brak nagłówka sam w sobie niczego nie dowodzi (ocena): czy w ogóle masz włączoną dyrektywę mail.add_x_header, bo bez niej PHP tego nagłówka nie dodaje, oraz czy złośliwy skrypt nie otwiera własnego połączenia SMTP, na przykład przez PHPMailer, bo wtedy nie przechodzi przez mail() i też nie będzie nagłówka. Traktuj to jako mocną wskazówkę, która rozdziela dwa zupełnie różne problemy, a nie jako dowód.

Włącz dwie dyrektywy PHP i poczekaj godzinę. mail.add_x_header = On dodaje do wychodzących wiadomości nagłówek X-PHP-Originating-Script, a mail.log = /ścieżka/do/pliku zapisuje każde wywołanie mail() razem z pełną ścieżką skryptu, numerem linii, adresem odbiorcy i nagłówkami (php.net/manual/en/mail.configuration.php). Na wielu hostingach współdzielonych ustawisz to przez panel albo plik .user.ini. Po godzinie masz w logu dokładną ścieżkę do pliku, który wysyła. Na cPanel z Eximem dochodzi jeszcze nagłówek X-PHP-Script z adresem URL i adresem IP klienta, który wywołał wysyłkę.

Bez włączania logu: porównaj czas wysyłki z logu poczty z czasem żądań POST w logu serwera WWW (access.log). Trafienie w tę samą sekundę wskazuje konkretny adres URL (thehost.ua, wiki, "How to detect the source of spam").

Szukanie plików: typowe ślady to eval(base64_decode(...)) i eval(gzinflate(...)), pliki PHP o losowych nazwach, świeża data modyfikacji. I od razu zastrzeżenie, o którym mówi samo źródło: te same funkcje bywają legalnie używane przez rozszerzenia, więc kasowanie wszystkiego, co wypluje grep, potrafi położyć stronę (mysites.guru; sucuri.net/guides/how-to-clean-joomla/). Popularne twierdzenie, że jeden grep znajduje 99,9 procent zainfekowanych plików, to marketing i nie będę go powtarzał.

Na hostingu współdzielonym nie masz SSH ani tych komend. Wtedy zostaje panel, statystyki wysyłki i zgłoszenie do hostingu. Warto wiedzieć, że cyber_Folks pisze wprost, że sprzątanie nie należy do nich: "obowiązek zabezpieczenia strony i innych treści na koncie przed infekcjami wirusów spoczywa na Tobie jako użytkowniku konta, ponieważ Cyberfolks nie ingeruje w treści użytkowników" (cyberfolks.pl/pomoc/infekcje-na-koncie-hostingowym/).

Dlaczego tego scenariusza nie ma w poradnikach

Nie jest to teoria spiskowa, tylko obserwacja: w artykule home.pl "Ktoś wysyła spam z mojego adresu e-mail" jako przyczyny wymienione są tylko dwie, zbyt słabe hasło do skrzynki i złośliwe oprogramowanie na komputerze użytkownika. Zhakowana strona i jej skrypty nie pojawiają się tam wcale. Bazy wiedzy prowadzą Cię do hasła i antywirusa, a nie do katalogu ze stroną.

I uczciwie do końca: nie istnieje publiczna statystyka, jaka część przypadków "maile trafiają do spamu" wynika z włamania, a jaka z błędów w rekordach. Nie znalazłem żadnego wiarygodnego źródła z takim podziałem. Dlatego piszę jakościowo: w większości przypadków winne są rekordy i ustawienia wysyłki, ale istnieje scenariusz, którego sprawdzanie rekordów nie wykryje nigdy.

---

Domena albo IP już są na czarnej liście: co robić i w jakiej kolejności

Najpierw zrozum, na której liście jesteś

Listy Spamhaus to nie jest jedna lista:

• SBL: baza adresów IP źródeł spamu. "The Spamhaus Block List (SBL) is a realtime database of IP addresses of spam sources", zawiera wyłącznie adresy i zakresy IP, średnio 30 do 40 tysięcy wpisów.
• CSS: zbiór tworzony automatycznie, "an automatically produced dataset of IP addresses that are involved in sending low-reputation email", obejmuje też hosty skompromitowane. Spamhaus dodaje: "If an IP is listed, the problem is recent!" (spamhaus.org/faqs/combined-spam-sources-css/).
• XBL: adresy ze śladami kompromitacji, około 2 milionów wpisów i rzędu 650 tysięcy nowych wykryć zainfekowanych adresów IP na dobę. Wpisy wygasają automatycznie, gdy złośliwa aktywność przestaje być obserwowana.
• PBL: zakresy użytkowników końcowych, opisane wyżej.
• DBL: wyłącznie nazwy domen, a w środku jest osobna kategoria abused-legit, opisana jako "hostnames on domains that are legitimate, but are being abused for malicious purposes", z przyczynami takimi jak "outdated software, substandard security, or fraudulent access" (spamhaus.org/blocklists/domain-blocklist/).

Ta ostatnia kategoria jest o Tobie, jeśli trafiłeś tu z poprzedniej części tekstu. Branża zna ten scenariusz na tyle dobrze, że ma dla niego osobną szufladę.

Kolejność działań

1. Zatrzymaj wysyłkę. Spamhaus w instrukcji dla DBL radzi zdjąć stronę lub serwer do trybu offline na czas naprawy.
2. Znajdź i zamknij dziurę, a nie tylko usuń pliki. To nie jest moja opinia, tylko wymóg dwóch niezależnych stron. Spamhaus o CSS, wytłuszczone u nich w oryginale: "Whatever caused the problem MUST be identified and corrected before removing an IP from CSS", a dalej "CSS will allow the removal of an IP, but it will also re-list it immediately if a problem continues to be detected". Do tego "Self-removals are limited", więc kolejne próby bez naprawy odbierają Ci możliwość samodzielnego usuwania. home.pl formułuje to samo po swojemu: samo usunięcie złośliwego kodu bez usunięcia podatności grozi ponowną infekcją i ponowną blokadą (pomoc.home.pl, "Blokada administracyjna konta").
3. Zaktualizuj CMS i wszystkie rozszerzenia, usuń zainfekowane pliki, przeanalizuj logi serwera, żeby ustalić, którędy pliki trafiły na konto. To lista wprost z wymagań home.pl do odblokowania konta, w praktycznie identycznym brzmieniu powtarza ją Spamhaus w FAQ do DBL.
4. Zmień wszystkie hasła na mocne i włącz uwierzytelnianie dwuskładnikowe (Spamhaus, FAQ DBL). Panel hostingu, FTP, baza, konta administratorów CMS, skrzynki.
5. Uporządkuj DNS wysyłającego serwera. Spamhaus przy CSS sprawdza cztery rzeczy: domena HELO musi rozwiązywać się na adres wysyłający, adres wysyłający musi mieć poprawny rekord odwrotny, rekord odwrotny musi zgadzać się z domeną HELO i musi rozwiązywać się z powrotem na ten adres.
6. Dopiero teraz złóż wniosek o usunięcie z listy, przez Spamhaus IP & Domain Reputation Checker.

Rozróżnienie ważne przy punkcie 6. Wniosku o zdjęcie adresu IP na hostingu współdzielonym zwykle nie złożysz sam: "It is the network owner's responsibility to notify Spamhaus of any changes that affect a SBL listing, and to request removal" (spamhaus.org/blocklists/spamhaus-blocklist/). To rola hostingu, Twoja kończy się na wyczyszczeniu strony i napisaniu do nich. Inaczej jest z listą domenową DBL: tam wpisana jest Twoja domena, więc wniosek składasz Ty, po naprawie. To też tłumaczy, dlaczego hostingi reagują tak szybko i tak twardo: z jednego adresu IP wysyła wielu klientów, więc listing uderza we wszystkich naraz.

Kilka rzeczy, które oszczędzą Ci pieniędzy i czasu

• Usunięcie z list Spamhaus jest zawsze darmowe. Ich własne słowa: "There is NEVER any charge or fee associated with removing any Spamhaus listing. Any offer from anyone to remove any Spamhaus listing for a fee is a scam". Jeśli ktoś proponuje Ci płatne zdjęcie z listy Spamhaus, to jest oszustwo.
• UCEPROTECT to inna bajka. Poziom 2 obejmuje podsieci, a poziom 3 całe systemy autonomiczne operatora, więc trafiają tam klienci, którzy nic nie zrobili. Ten operator oferuje płatne przyspieszone usunięcie, bez gwarancji, że nie zostaniesz wpisany ponownie, i jest za to w branży szeroko krytykowany. Kwot nie podaję, bo źródła wtórne podają różne. Listing na poziomie 3 zwykle nie jest Twoją winą i zwykle nie warto za niego płacić (to ocena, oparta na krytyce z wielu niezależnych źródeł).
• SpamCop zdejmuje automatycznie. Nie ma tam do kogo pisać: adres schodzi z listy około 24 godzin po ostatnim zgłoszeniu, plus do 4 godzin na rozejście się po serwerach lustrzanych (SpamCop FAQ). Wystarczy przestać wysyłać.
• SORBS już nie istnieje. Właściciel, firma Proofpoint, zamknął go w czerwcu 2024 i wyczyścił wszystkie 18 stref (theregister.com, 7 czerwca 2024). Jeśli poradnik każe Ci "sprawdzić się w SORBS", jest przestarzały.
• Microsoft ma własny obieg. Portal delistingu sender.office.com obsługuje adresy IP zablokowane z kodami NDR od 5.7.606 do 5.7.649, natomiast przy kodzie 5.7.511 portal nie działa i trzeba napisać na [email protected] (learn.microsoft.com, "Use the delist portal"). Czystość u Spamhausa nie oznacza automatycznie, że docierasz do Outlooka.
• Terminy: Spamhaus nie publikuje żadnych gwarantowanych czasów rozpatrzenia dla SBL, CSS ani DBL, a przy XBL mówi tylko o wygasaniu wpisów "after a period of time", bez podania okresu. Sprawdziłem to i nie znalazłem. Jeśli ktoś obiecuje Ci wyjście ze spamu w 24 godziny, obiecuje coś, czego nie kontroluje.

Monitoring po naprawie

• Google Postmaster Tools: patrz na Compliance status i Spam rate. Podpięcie wymaga potwierdzenia własności domeny rekordem TXT.
• Microsoft SNDS: dane o reputacji Twoich adresów IP plus program JMRP, który przysyła zgłoszenia, gdy użytkownicy oznaczają Twoją pocztę jako junk. Ważne ograniczenie: SNDS jest przypisany do adresu IP, więc na hostingu współdzielonym nie jest dla Ciebie. Adres usługi się zmienia, 1 sierpnia 2026 stary link przekierowywał na substrate.office.com, więc szukaj po nazwie, nie po zapamiętanym URL-u.
• Yahoo Complaint Feedback Loop: działa na poziomie domeny, nie adresu IP, więc jest dostępny także na cudzym hostingu, ale wymaga podpisywania poczty DKIM-em: usługa "only supports DKIM-signed email and is a domain based service" (senders.yahooinc.com/complaint-feedback-loop/).

---