# Sprawdzenie czarnej listy e-mail: czego nie mówią narzędzia URL: https://notificationharbor.com/pl/journal/sprawdzenie-czarnej-listy-email Type: blog Locale: pl Published: 2026-11-10 Updated: 2026-11-11 --- > Sprawdzenie listy to zapytanie DNS z trzema możliwymi wynikami, a jedno z nich narzędzia zwykle ukrywają. Pokazujemy, jak je uruchomić, zaplanować i poprawnie czytać kody odbić. Sprawdzenie czarnej listy e-mail sprowadza się do jednego zapytania DNS: czy adres IP lub domena nadawcy figuruje w tej chwili na publicznej liście DNSBL. Zielony lub czerwony wiersz w narzędziu nie mówi jednak, czy Gmail, Outlook albo firmowa bramka przyjmą następną wiadomość. Mylenie tych dwóch pytań sprawia, że większość osi czasu incydentów idzie w złym kierunku. Ten tekst pokazuje, co dokładnie odpytuje takie sprawdzenie, jak uruchomić je ręcznie poleceniem `dig`, które kody oznaczają czysty wynik, a które odmowę zapytania, i jak spiąć całość z monitoringiem, żeby nie robić tego ręcznie o drugiej w nocy. ## Sprawdzenie listy to zapytanie DNS i nic więcej Każda lista DNSBL działa tak samo. Odwracasz oktety adresu IPv4, dopisujesz strefę listy i pytasz o rekord A. [RFC 5782](https://datatracker.ietf.org/doc/html/rfc5782) opisuje tę konwencję: dla adresu 192.0.2.99 sprawdzanego w strefie `bad.example.com` zapytaniem jest `99.2.0.192.bad.example.com`. Jeśli adres jest na liście, dostajesz odpowiedź z zakresu 127.0.0.0/8. Jeśli nie, rekordu nie ma. To jest cały mechanizm. Narzędzia webowe, do których wkleja się IP, wykonują dziesiątki takich zapytań równolegle i formatują odpowiedzi. `# Czy 203.0.113.25 jest na liście Spamhaus ZEN? dig +short 25.113.0.203.zen.spamhaus.org A # Sprawdzenie domeny na liście opartej na domenach działa tak samo, bez odwracania: dig +short example.com.dbl.spamhaus.org A`Pusta odpowiedź oznacza brak wpisu. Odpowiedź 127.x.x.x oznacza wpis, a ostatnie oktety wskazują, który podlist zadziałał. Uruchomione z maszyny, którą kontrolujesz, przez własny resolver, takie sprawdzenie da się zapisać w skrypcie, zalogować i podpiąć pod alert. ![Laptop z ciemnym oknem terminala obok notatnika ze szkicem schematu sieci](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/0692d5-inline1.webp) ## Sprawdzaj adres, z którego wychodzi poczta, a nie ten, z którego działa strona Pierwszym błędem jest sprawdzanie złego IP. Serwer strony, API i relay wysyłkowy to zwykle trzy różne adresy. Liczy się ten, który widnieje w nagłówku `Received` wiadomości faktycznie dostarczonej do skrzynki. Jeśli wysyłasz przez dostawcę na infrastrukturze współdzielonej, ten adres nie jest twój, a wpis na liście też nie jest twój. Jeśli wysyłasz z dedykowanego IP, odpowiadasz za cały zakres, łącznie z tym, co robił poprzedni najemca. Adres pobierz z dostarczonej wiadomości, a nie z ustawień w panelu. Potem sprawdź trzy rzeczy osobno: adres IP, domeny w kopercie i w polu From oraz każdą domenę w linkach, łącznie z hostami śledzącymi i hostami do rezygnacji z subskrypcji. Listy oparte na URI, takie jak URIBL i SURBL, oceniają linki w treści wiadomości, więc czyste IP nie chroni wiadomości, która wskazuje na zablokowaną domenę. Ta kontrola zajmuje kilka minut i wyłapuje problemy, których samo sprawdzenie IP nigdy nie pokaże. ## Czysty wynik z publicznego resolvera może być odmową To tryb awarii, o którym generatory sprawdzeń prawie nigdy nie piszą. Spamhaus nie odpowiada na zapytania przychodzące przez publiczne lub otwarte resolvery i sygnalizuje to kodem zwrotnym, a nie wpisem. [Spamhaus dokumentuje kod 127.255.255.254 jako kod błędu](https://www.spamhaus.org/resource-hub/dnsbl/using-our-public-mirrors-check-your-return-codes-now/), a nie wynik reputacji, i wyraźnie zaznacza, że na jego podstawie nie wolno odrzucać poczty. Z tego wynikają dwie konsekwencje. Jeśli skrypt traktuje każdą odpowiedź 127.x jako wpis, odmowa z chmurowego resolvera wywoła alarm o wpisie, którego nie ma. Jeśli traktuje brak użytecznej odpowiedzi jako czysty wynik, przegapisz prawdziwe wpisy, bo odmowa może też wyglądać jak pusta odpowiedź albo NXDOMAIN. Rozwiązaniem jest uruchamianie zapytań z hosta z własnym rekurencyjnym resolverem i poprawnym rDNS albo z bezpłatnej usługi zapytań, na którą Spamhaus kieruje użytkowników publicznych lustrzanych serwerów. Zanim zaufasz strefie, sprawdź ją. RFC 5782 wymaga, by listy IPv4 miały wpis dla 127.0.0.2 i nie miały wpisu dla 127.0.0.1, więc test wygląda tak: `dig +short 2.0.0.127.zen.spamhaus.org A # musi zwrócić odpowiedź 127.x dig +short 1.0.0.127.zen.spamhaus.org A # musi nic nie zwrócić`Jeśli oba zwracają pusto, ścieżka do resolvera jest zepsuta albo odmawia zapytań. Napraw ją, zanim przeczytasz z niej jakikolwiek wynik. ![Patch panel z niebieskimi kablami ethernet, z jednym czerwonym wyróżniającym się kablem](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/2357cf-inline2.webp) ## Większość incydentów dostarczalności nie dotyczy czarnych list Przy przeglądzie odbić, który robimy przed jakimkolwiek sprawdzeniem, pierwsze pytanie brzmi: co serwer odbiorcy faktycznie odpowiedział. Wpis na liście daje konkretne odrzucenie. Problemy z reputacją u dostawcy skrzynek dają inne odrzucenia, których żadna publiczna lista nie pokaże. Dokumentacja Google dla nadawców jest tu jednoznaczna. Odpowiedź `550 5.7.1` może oznaczać, że IP nadawcy jest na liście zawieszonych, często przez słabą reputację współdzielonego IP. Kod `5.7.26` wskazuje na nieudaną autoryzację. Nadawcy masowi muszą mieć SPF, DKIM i DMARC, poprawne rekordy DNS w obu kierunkach dla IP nadawcy, szyfrowanie TLS oraz wskaźnik spamu poniżej 0,30% w Postmaster Tools. [Wymagania Google dla nadawców](https://support.google.com/a/answer/81126) podają 0,10% jako zalecany cel. Z tego wynika kolejność działań. Jeśli tekst odbicia wskazuje strefę DNSBL, masz problem z wpisem. Jeśli mówi o reputacji, autoryzacji albo limicie, sprawdzenie listy wróci czyste, a ty stracisz godzinę na potwierdzanie czegoś, czego i tak nie widać. - Nazwa strefy DNSBL lub adres URL w tekście: jesteś wpisany na tę konkretną listę. Sprawdź wpis, a potem skorzystaj z formularza usunięcia u operatora listy. - `550 5.7.1` z opisem reputacji IP: reputacja po stronie dostawcy, często na współdzielonym IP. Sprawdź Postmaster Tools oraz trend wolumenu i skarg. - `5.7.26`: autoryzacja nie powiodła się. Sprawdź wyrównanie SPF, DKIM i DMARC. - `4.7.28` albo opis limitu: wysyłka jest za szybka jak na obecną reputację. Zwolnij, a potem stopniowo podnoś tempo. ## Jednorazowy sprawdzacz w sieci nie nadaje się do monitoringu Jednorazowe sprawdzenie mówi, jaki był stan w chwili kliknięcia. Wpisy są często chwilowe, a wiele z nich pojawia się po skoku, który sam wywołałeś: zimnym imporcie, akcji ponownego zbierania zgód albo przejętym formularzu, z którego ktoś rozsyłał spam. Narzędzia, które pobierają opłatę za „usunięcie z 100 list”, sprzedają usługę na problem, którego większość z tych list nie dotyczy. Wiele list w typowym zbiorczym sprawdzeniu ma pomijalny wpływ na główne serwisy pocztowe, a usunięcie zwykle jest bezpłatne i samoobsługowe na stronie operatora. Ściganie każdego czerwonego wiersza marnuje czas, który należy się dwóm lub trzem listom, z których korzystają twoi odbiorcy. ![Trzy karteczki połączone strzałkami na tablicy, szkic przepływu monitoringu](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/55886e-inline3.webp) Listy uszereguj według ruchu, który wysyłasz. Sprawdź, którzy odbiorcy pojawiają się w odbiciach, ustal, z jakich list ci odbiorcy publicznie korzystają, i obserwuj właśnie je. Resztę przeglądaj raz w miesiącu. ## Zamień sprawdzenie w zaplanowane zadanie z progiem alarmu Poniżej minimalna wersja, która się sprawdza. Działa z hosta z prawdziwym resolverem, najpierw waliduje strefę i rozróżnia trzy wyniki: wpis, brak wpisu oraz odmowę zapytania. `import socket def dnsbl(ip: str, zone: str) -> str: rev = ".".join(reversed(ip.split("."))) try: answer = socket.gethostbyname(f"{rev}.{zone}") except socket.gaierror: return "not_listed" if answer.startswith("127.255.255."): return "refused" # kod błędu, a nie wynik reputacji return f"listed:{answer}" # Sprawdź strefę, zanim zaufasz wynikom (wpisy testowe z RFC 5782) assert dnsbl("127.0.0.2", "zen.spamhaus.org").startswith("listed") assert dnsbl("127.0.0.1", "zen.spamhaus.org") == "not_listed"`Uruchamiaj ją co 15 do 60 minut dla każdego IP nadawcy i każdej domeny nadawcy, zapisuj każdy wynik z sygnaturą czasu i alarmuj tylko przy przejściu ze stanu `not_listed` do `listed`. Odmowę zgłaszaj osobno, bo oznacza ona, że monitoring jest ślepy, a nie że zmieniła się reputacja. Połącz to z sygnałami, które wyprzedzają wpisy na listach: wskaźnik skarg z pulpitów Postmaster, odsetek odbić według domeny odbiorcy oraz liczbę odroczeń na godzinę. Zmieniają się one, zanim pojawi się wpis, i to one mówią, czy wstrzymać wysyłkę. Jeśli logi i metryki już trafiają do stosu monitoringu, wynik sprawdzenia jest po prostu kolejną serią czasową. W tym przepływie przydają się cztery narzędzia, zależnie od tego, gdzie najbardziej boli. Postmark to usługa wyłącznie transakcyjna, więc resetowanie hasła nie dzieli ścieżki wysyłki z cudzym newsletterem. Jeśli wpisy wracają przez sąsiada na współdzielonej infrastrukturze, rozdzielenie wysyłki transakcyjnej i marketingowej jest strukturalnym rozwiązaniem. Resend to opcja dla deweloperów, z czystym API i niewielką powierzchnią do instrumentowania. Ma sens, jeśli zespół i tak będzie pisał własne sprawdzenia dostarczalności. SendGrid ma najdłuższy staż przy dużym wolumenie i oferuje dedykowane IP, więc reputacja i ekspozycja na listy są wyłącznie twoje. Pomiń go, jeśli nie masz ludzi do rozgrzewania IP i monitoringu, którego dedykowane adresy wymagają. Better Stack to element strony z zadaniami zaplanowanymi: sprawdzenia typu uptime, alerty i routing dyżurów dla skryptu z góry, tak aby nowy wpis trafiał do człowieka, a nie do pliku logu. ## Gdy jesteś na liście, najpierw usuń przyczynę, potem proś o usunięcie Usunięcie bez znalezienia przyczyny kupuje kilka dni. Operator listy, który widzi ten sam adres z tym samym zachowaniem, dopisze go ponownie, a niektórzy operatorzy eskalują powtarzające się wpisy. Pracuj w tej kolejności: - Wstrzymaj albo ogranicz wysyłkę z wpisanego IP. Dalszy zły ruch przedłuża wpis i dodaje kolejne. - Przeczytaj rekord wpisu u operatora listy. Wiele z nich podaje dowody: trafienie w pułapkę spamową, skok ruchu albo zgłoszenie nadużycia przekaźnika. - Znajdź źródło. Sprawdź endpointy formularzy pod kątem wykorzystania jako otwarty przekaźnik, przejrzyj ostatnie importy list i każdą nową integrację, która zaczęła wysyłać w ciągu ostatniego tygodnia. - Usuń przyczynę, a dopiero potem skorzystaj z procesu usunięcia u operatora. Niektóre listy wygaszają wpisy automatycznie po okresie ciszy. - Wznów wysyłkę z ograniczonym wolumenem, zaczynając od najbardziej zaangażowanych odbiorców, i przez tydzień obserwuj wskaźnik skarg oraz odroczenia. Brak rDNS to powtarzająca się przyczyna. Google wymienia poprawne rekordy PTR wśród wymagań dla nadawców, a IP bez nich wielu odbiorców traktuje jako mało wiarygodne, zanim w ogóle oceni treść. ## Traktuj przepływ lifecycle jako zależny od sygnału Jeśli produkt wysyła e-maile aktywacyjne, rozliczeniowe albo bezpieczeństwa, wpis na liście jest incydentem dostępności dla tych przepływów. Traktuj go w ten sposób: kieruj wiadomości transakcyjne ścieżką odizolowaną od wolumenu marketingowego i spraw, by warstwa wyzwalaczy znała stan dostarczenia. Wtedy zawieszony e-mail aktywacyjny może przejść na podpowiedź w aplikacji. Rozdzielenie warstwy zdarzeń od warstwy dostarczenia jest częścią wartą skopiowania, nawet przy innych dostawcach. Zdarzenie z listy blokad ma zmieniać to, dokąd trafia wiadomość, a nie to, czy logika lifecycle działa. Koszt jest taki, że masz jeden system więcej do obserwowania. ## Co wdrożyć w tym tygodniu Trzy rzeczy, w kolejności zysku. Po pierwsze zaplanowane sprawdzenie z walidacją strefy i osobnym stanem odmowy, uruchamiane z hosta z własnym resolverem. Po drugie podział odbić według domeny odbiorcy, żeby wiedzieć, które listy mają znaczenie dla twojego ruchu. Po trzecie pisany runbook, który zaczyna się od tekstu odbicia, a kończy na kroku usunięcia, tak aby osoba na dyżurze nie improwizowała. Którą z domen wysyłkowych zauważyłbyś dopiero po jednym dniu bez dostarczania? ## FAQ ### Jak wykonać sprawdzenie czarnej listy e-mail dla mojego IP? Odwróć oktety adresu, dopisz strefę DNSBL i zapytaj o rekord A. Dla 203.0.113.25 w Spamhaus ZEN: dig +short 25.113.0.203.zen.spamhaus.org A. Pusta odpowiedź oznacza brak wpisu, odpowiedź 127.x oznacza wpis. ### Dlaczego IP wygląda na czyste, a e-mail mimo to wraca? Sprawdzenie obejmuje tylko listy, które odpytałeś. Odrzucenia często wynikają z reputacji u dostawcy skrzynek, nieudanego SPF, DKIM lub DMARC albo limitów wysyłki, a tego na publicznej liście nie widać. Zacznij od tekstu odbicia. ### Co oznacza kod 127.255.255.254 w Spamhaus? To kod błędu, nie wynik reputacji. Spamhaus używa go, gdy zapytanie przychodzi przez publiczny lub otwarty resolver. Nic nie mówi o twoim IP i nie należy go traktować jako wpisu. ### Czy sprawdzać także domenę, a nie tylko IP nadawcy? Tak. Reputacja IP i domeny to osobne sygnały. Sprawdź też domeny w linkach, łącznie z hostami śledzącymi i do rezygnacji z subskrypcji, bo listy URI oceniają linki w treści wiadomości. ### Jak często monitorować czarne listy? Co 15 do 60 minut dla każdego IP i domeny nadawcy zwykle wystarcza. Alarmuj przy zmianie ze stanu niewpisany na wpisany, a odmowy zgłaszaj osobno, bo oznaczają ślepy monitoring. ### Czy warto płacić za usunięcie z czarnych list? Zwykle nie. Usunięcie jest zazwyczaj bezpłatne na stronie operatora listy, a wiele list w szerokim sprawdzeniu ma niewielkie znaczenie dla głównych dostawców poczty. Najpierw usuń przyczynę, potem poproś o usunięcie.