Wskaźnik odrzuceń e-maili: jak go mierzyć i co naprawić
Summary
Wskaźnik odrzuceń e-maili to odsetek wysłanych wiadomości, które serwer odbiorcy odrzucił. W zdrowej bazie twarde odrzucenia trzymaj poniżej 1%, badaj przy 2%, a 5% traktuj jak incydent, bo Amazon SES obejmuje konta na tym poziomie przeglądem. Dziel wskaźnik według strumienia, źródła i typu odrzucenia, a kod SMTP zapisuj przy każdym zdarzeniu, aby odróżnić brudną listę od problemu z reputacją.
Wskaźnik odrzuceń e-maili to odsetek wysłanych wiadomości, których serwer odbiorcy nie przyjął. Sama liczba niewiele mówi, bo zmieniają ją mianownik, typ odrzucenia i okno czasowe. W zdrowej bazie twarde odrzucenia trzymamy poniżej 1%, przy 2% zaczynamy badanie, a przy 5% traktujemy sytuację jak incydent. Większość zespołów czyta jedną uśrednioną wartość z dashboardu i nie widzi, że każdy z tych trzech elementów może zmienić wynik.
Ten tekst zajmuje się najpierw poprawnym policzeniem tej liczby, a dopiero potem decyzją, co z nią zrobić.
Wzór jest prosty. Spór dotyczy mianownika.
Wskaźnik odrzuceń to liczba odrzuconych wiadomości podzielona przez liczbę wysłanych, pomnożona przez 100. Część dostawców ESP dzieli przez liczbę dostarczonych wiadomości, co daje wyższy wynik, ponieważ dostarczone już wykluczają odrzucone. Zanim porównasz wynik z benchmarkiem, sprawdź, której definicji używa Twój dostawca.
Amazon SES liczy swój wskaźnik wyłącznie z twardych odrzuceń, w odniesieniu do liczby wiadomości wysłanych przez konto. Ten szczegół ma znaczenie: raport, który miesza miękkie i twarde odrzucenia, pokaże wyższą liczbę niż ta, na podstawie której dostawca ocenia konto.
Wybierz jedną definicję i zapisz ją obok metryki, w tytule wykresu, jeśli trzeba. My liczymy twarde odrzucenia w stosunku do wysłanych, osobno dla każdej domeny nadawcy, w oknie 24 godzin i 7 dni. Jeśli dwie osoby w zespole podają różne liczby za ten sam tydzień, pierwsze, co trzeba porównać, to mianownik.
Twarde, miękkie i blokady to trzy różne sygnały
Twarde odrzucenie to błąd trwały. Adres nie istnieje, domena się nie rozwiązuje albo skrzynka została zamknięta. SMTP zgłasza go kodem 5.x.x, zdefiniowanym w RFC 3463.
Miękkie odrzucenie to błąd tymczasowy: pełna skrzynka, chwilowo niedostępny serwer albo zbyt duża wiadomość. Te odpowiedzi mają kody 4.x.x, a dobrze skonfigurowany nadawca ponawia wysyłkę. Różnicę między jednym a drugim typem opisujemy w osobnym tekście, tutaj wystarczy zapamiętać, że to dwa różne problemy.
Trzecia kategoria to ta, którą pulpity z raportami ukrywają. Blokada to odrzucenie 5.x.x, które nic nie mówi o adresie, a wszystko o nadawcy: zablokowany IP, nieudana weryfikacja uwierzytelnienia albo filtr treści lub reputacji. Zliczenie blokady jako twardego odrzucenia sprawia, że lista wygląda na brudną, choć problem leży w konfiguracji wysyłki.
Pomijaj raporty z jedną pozycją „odrzucenia”. Rozbij ją na trzy serie, inaczej będziesz czyścić listę, która nigdy nie była problemem.
Jaki wskaźnik odrzuceń jest dobry w 2026 roku?
Nie ma jednej opublikowanej liczby i warto to wiedzieć, zanim jakąś podasz. Gmail i Yahoo publikują progi dla skarg na spam, a nie dla odrzuceń. Google prosi masowych nadawców, by wskaźnik spamu w Postmaster Tools utrzymywali poniżej 0.10% i nigdy nie dochodzili do 0.30%, zgodnie z FAQ wytycznych dla nadawców.
W przypadku odrzuceń liczby robocze pochodzą od dostawców i z praktyki. Poniższe progi to nasze poziomy alarmowe, a nie gwarancje żadnego dostawcy poczty. Twarde odrzucenia w ujęciu dziennym dla domeny:
Poniżej 0.5%: normalnie dla zaangażowanej, zweryfikowanej bazy.
Od 0.5% do 1%: obserwuj i sprawdzaj źródła nowych adresów.
Od 1% do 2%: zbadaj sprawę i wstrzymaj segment o najwyższym wskaźniku.
Od 2% do 5%: zatrzymaj masowe wysyłki z tego strumienia i znajdź import lub formularz, który za tym stoi.
Powyżej 5%: incydent. Amazon SES obejmuje konta na tym poziomie przeglądem.
Ostatni wiersz opiera się na udokumentowanym progu. W dokumentacji dashboardu reputacji Amazon SES podaje, że konto ze wskaźnikiem 5% lub wyższym zostaje objęte przeglądem, a wysyłka może zostać wstrzymana, jeśli wskaźnik utrzymuje się powyżej 10%. Inni dostawcy stosują inne liczby i inne sformułowania, więc warunki własnego kontraktu trzeba przeczytać osobno.
Najpierw segmentuj: uśredniony wskaźnik ukrywa strumień, który się psuje
Konto z ogólnym wskaźnikiem 0.8% może zawierać strumień transakcyjny na poziomie 0.1% i import do ponownego zaangażowania na poziomie 6%. Średnia wygląda akceptowalnie, a drugi strumień po cichu szkodzi domenie nadawcy.
Licz wskaźnik osobno dla strumienia, źródła i domeny odbiorcy. Cztery przekroje wychwytują większość problemów:
Według strumienia. Transakcyjne, lifecycle i kampanie masowe nigdy nie powinny dzielić jednej liczby.
Według źródła zapisu. Formularze, zapisy przez API, importy CSV i listy partnerów mają bardzo różną jakość adresów.
Według domeny odbiorcy. Skok u jednego dostawcy zwykle oznacza politykę odrzucania, a nie brudną listę.
Według wieku adresu. Adresy zebrane ponad 12 miesięcy temu odbijają się częściej niż świeże.
To nie jest kwestia wygody raportowania. To różnica między naprawieniem błędu walidacji formularza w godzinę a panicznym czyszczeniem zdrowej listy.
Piąty przekrój, wart dodania, gdy reszta już działa: według IP lub domeny wysyłającej. Jeśli masz dedykowany IP dla poczty transakcyjnej, a wspólną pulę dla kampanii, skok na jednej z nich pokazuje, gdzie szukać, zanim otworzysz jeden log.
Odczytuj zdarzenia odrzuceń od dostawcy i nie gub ich
Każdy poważny dostawca ESP udostępnia odrzucenia jako zdarzenia: webhook, temat powiadomień albo API zdarzeń. Traktuj ten strumień jako źródło prawdy i zapisuj go we własnym magazynie, bo pulpity agregują dane i gubią szczegóły, których potrzebujesz później.
Dla każdego zdarzenia zapisz: identyfikator wiadomości, odbiorcę, typ odrzucenia, rozszerzony kod statusu, tekst diagnostyczny i znacznik czasu. Z tymi sześcioma polami odpowiesz na większość pytań, które pojawiają się podczas analizy poincydentowej.
{
"event": "bounce",
"message_id": "msg_01H9",
"recipient": "user@example.com",
"bounce_type": "permanent",
"status": "5.1.1",
"diagnostic": "550 5.1.1 user unknown",
"stream": "lifecycle",
"ts": "2026-11-02T09:14:03Z"
}Handler musi być idempotentny, z kluczem złożonym z identyfikatora zdarzenia u dostawcy i identyfikatora wiadomości. Dostawcy ponawiają webhooki, a zdublowane zdarzenie twardego odrzucenia, które podbija licznik dwa razy, zniekształci wskaźnik i może wykluczyć adres, który jest w porządku.
Postmark i Resend rozdzielają typy odrzuceń w swoich zdarzeniach i pozwalają pobierać je osobno dla strumienia wiadomości, co sprawia, że podział opisany wyżej jest tani do zbudowania.
Reguła wykluczania, która robi najwięcej pracy
Najskuteczniejsza kontrola to automatyczne wykluczanie. Po jednym twardym odrzuceniu przestań wysyłać na ten adres na stałe, na poziomie aplikacji, a nie tylko polegając na liście dostawcy.
Większość ESP wyklucza twarde odrzucenia za Ciebie. Luka pojawia się wtedy, gdy zmieniasz dostawcę, uruchamiasz dwóch równolegle albo wysyłasz z systemu, który nigdy nie czyta listy wykluczeń. Własna tabela kluczowana znormalizowanym adresem zamyka tę lukę.
W przypadku miękkich odrzuceń używaj licznika zamiast pojedynczego zdarzenia. Nasz domyślny próg to wykluczenie po trzech kolejnych miękkich odrzuceniach w okresie co najmniej siedmiu dni. Skrzynka pełna przez tydzień jest, z punktu widzenia lifecycle, po prostu martwa.
Ta reguła działa też przy przenoszeniu wysyłki między dostawcami. Zanim włączysz nowego dostawcę, zaimportuj do niego listę wykluczeń z własnej tabeli, a nie tylko z eksportu starego ESP. Bez tego adres, który odbił się u poprzednika, może trafić do nowego systemu jako świeży kontakt i zacząć podbijać wskaźnik od pierwszego dnia.
Nie usuwaj adresów, które się odbiły, z tabeli użytkowników. Oznacz je kodem statusu i datą. Usunięty wiersz nie powie Ci, że ten sam adres odbił się dwa razy w zeszłym kwartale. Ten zapis jest potrzebny, by nie zaimportować tego samego adresu z następnego CSV, a to najczęstszy sposób, w jaki „oczyszczona” lista znów brudnieje.
Dlaczego wskaźnik nagle skacze: najczęstsze przyczyny w kolejności
Gdy wskaźnik się rusza, szukaj przyczyny w tej kolejności. Pierwsze trzy wyjaśniają większość skoków.
Nowy import. Plik CSV z wydarzenia, od partnera albo ze starego eksportu CRM. Sprawdź wskaźnik według źródła przed wszystkim innym.
Formularz zapisu bez walidacji. Literówki w rodzaju gmial.com i jednorazowe domeny. Sprawdzenie składni i rekordu MX w chwili wysyłki formularza usuwa większość z nich, a e-mail potwierdzający usuwa resztę, zanim w przepływie lifecycle zostanie policzona jako wysyłka.
Zmiana konfiguracji wysyłki. Nowy IP, nowa domena albo rozgrzewka, która ruszyła zbyt szybko i zamiast twardych odrzuceń przerodziła się w blokady.
Zerwane uwierzytelnienie. Wyrównanie SPF, DKIM lub DMARC przestaje działać po zmianie DNS.
Polityka odrzucania po stronie dostawcy. Jedna domena odbiorcy zaostrzyła filtry. Wskaźnik rośnie tylko tam.
Diagnozą jest rozkład kodów statusu, pogrupowany według strumienia i domeny odbiorcy w tym samym oknie czasowym co skok. Wzrost liczby kodów 5.1.1 (nieznany użytkownik) wskazuje na listę. Wzrost kodów 5.7.x wskazuje na politykę, uwierzytelnienie lub reputację. Wymagają one przeciwnych napraw, dlatego kod trzeba zapisywać.
Weźmy typowy przypadek. Wskaźnik twardych odrzuceń rośnie z 0.4% do 3% w ciągu jednego dnia, ale tylko w strumieniu przypomnień o płatnościach. Rozkład kodów pokazuje niemal same 5.1.1, czyli nieistniejące skrzynki. Źródło jest łatwe do wskazania: nocny eksport z dawnego CRM dopisał adresy, które nigdy nie były potwierdzone. Naprawa to wyłączenie tego importu i wykluczenie zaimportowanych adresów, a nie zmiana ustawień wysyłki. Gdyby ten sam skok miał kody 5.7.1 rozłożone po wielu domenach odbiorców, szukalibyśmy w uwierzytelnieniu i reputacji IP, a lista byłaby ostatnim podejrzanym.
Na co ustawiamy alert
Alert na średnią dzienną reaguje za wolno. Zły import potrafi wysłać 40 000 wiadomości w godzinę. Ustaw alert na przesuwającym się oknie:
Twarde odrzucenia powyżej 1% w ostatnich 1000 wysyłkach w dowolnym strumieniu.
Dowolna domena odbiorcy powyżej 5% przy co najmniej 200 wysyłkach w ciągu godziny.
Liczba blokad 5.7.x wyraźnie przekraczająca typowy poziom bazowy.
Dwa pierwsze alerty powinny wstrzymywać wysyłkę z winnego strumienia, a nie wysyłać stronę do człowieka. Człowiek może zbadać sprawę później. Wstrzymanie chroni reputację w ciągu kolejnych dziesięciu minut.
Eksportuj wskaźnik do monitoringu, który już prowadzisz, czy to Grafana, Datadog, czy własne narzędzie, i zachowuj etykietę strumienia przy serii, aby podział przetrwał eksport.
Do raportowania w górę używaj twardego wskaźnika odrzuceń według strumienia w oknie 7 dni oraz liczby blokad. Miękkie odrzucenia zostaw w widoku inżynierskim, gdzie są użyteczne, i pomiń je w raporcie zarządczym, gdzie wprowadzają zamieszanie. Nigdy nie podawaj samego uśrednionego wskaźnika konta, bo zmienia się z powodów, których nikt w sali nie potrafi wyjaśnić.
Jeśli ktoś prosi o jedną liczbę, podaj twardy wskaźnik strumienia transakcyjnego. To tam awaria kosztuje reset hasła albo fakturę i to najczystszy odczyt tego, czy infrastruktura działa zdrowo.
Następny konkretny krok jest mały: pobierz zdarzenia odrzuceń z ostatnich 30 dni, pogrupuj je według strumienia i kodu statusu, a potem zobacz, który wiersz Cię zaskoczył.