Sprawdzenie czarnej listy e-mail: czego nie mówią narzędzia

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 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.

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, 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.

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 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.

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:

1. Wstrzymaj albo ogranicz wysyłkę z wpisanego IP. Dalszy zły ruch przedłuża wpis i dodaje kolejne.

2. 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.

3. 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.

4. Usuń przyczynę, a dopiero potem skorzystaj z procesu usunięcia u operatora. Niektóre listy wygaszają wpisy automatycznie po okresie ciszy.

5. 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?