Feedback loop u dużych dostawców: jak czytać zgłoszenia spamu
Czym jest feedback loop i skąd biorą się zgłoszenia spamu
Feedback loop to kanał zwrotny między operatorem skrzynki pocztowej a nadawcą. Odbiorca klika „to jest spam”, a ty dostajesz o tym osobną wiadomość. Zgłoszenie przychodzi zwykle jako raport w formacie ARF, na adres zarejestrowany wcześniej u dostawcy. Ale nie każdy duży operator oddaje dane per wiadomość. Część udostępnia wyłącznie zagregowane wskaźniki reputacji domeny i adresu IP, bez wskazania konkretnego wysłania.
Są dwa sygnały, które ludzie mylą non stop. Kliknięcie „spam” i wypisanie się przez link w stopce to nie to samo. Dla filtra różnica jest zasadnicza: pierwsze obciąża reputację nadawcy, drugie jest neutralne. Zgłoszenia dotyczą wysyłki z twoich domen niezależnie od tego, czy nadajesz z własnych serwerów, czy korzystasz z floty operatora. Domena zbiera skargi, nie maszyna.
Rejestracja w feedback loop: co przygotować przed zgłoszeniem
Warunek wstępny jest twardy: uwierzytelnienie musi działać, zanim złożysz wniosek. Bez tego wnioski odpadają automatycznie.
- SPF obejmujący wszystkie adresy IP, z których faktycznie wychodzi poczta.
- DKIM z twoją domeną w polu d=, nie domeną operatora.
- DMARC z opublikowaną polityką i adresem na raporty zbiorcze.
- Return-Path pod twoją kontrolą - po nim dostawcy dopasowują zgłoszenia do nadawcy.
- PTR dla adresu IP zgodny z nazwą hosta w EHLO, rozwiązywalny w obie strony.
- Osobna skrzynka na raporty, z tej samej domeny co wysyłka, nie ogólny kontakt firmowy.
- Aktualny kontakt abuse w whois domeny i w rejestrze adresów IP.
Do samego zgłoszenia przygotuj: listę domen, adresy IP lub całe zakresy, selektory DKIM, adres odbioru raportów. Konfigurację uwierzytelnienia i osobnych domen wysyłkowych obsługują funkcje platformy wysyłkowej, więc nie musisz składać tego ręcznie na serwerze.
Tip: zgłoś każdy używany selektor DKIM, także te od poddomen transakcyjnych. Pominięty selektor oznacza raporty, które nigdy do ciebie nie dotrą. Sam się na tym przejechałem.
Anatomia raportu ARF: które pola faktycznie coś mówią
Raport składa się z trzech części: krótkiego opisu tekstowego, bloku message/feedback-report z metadanymi i kopii oryginalnej wiadomości. Cała wartość siedzi w środkowym bloku i w nagłówkach kopii. Reszta to opakowanie.
Pola, które czytasz najpierw
Feedback-Type określa rodzaj zgłoszenia: skarga na spam to co innego niż zgłoszenie techniczne czy nadużycie. Original-Mail-From, Reported-Domain i Source-IP wskazują serwer i domenę wysyłkową, która zebrała skargę. Przy flocie kilku adresów IP to jedyny sposób, żeby przypiąć problem do maszyny.
Arrival-Date zestawiony z datą wysyłki daje dystans czasowy. I to jest naprawdę użyteczne. Skarga po dwóch minutach mówi o temacie i nadawcy. Skarga po tygodniu mówi raczej o częstotliwości albo o zapomnianym zapisie.
Czego w raporcie zabraknie
Adres odbiorcy bywa zamaskowany albo całkiem usunięty. Dlatego identyfikator kampanii i subskrybenta wstawiasz sam, we własnym nagłówku X- wysyłanej wiadomości. Bez tego zostajesz z raportem, którego nie da się przypiąć do konkretnego wysłania. Czyli z niczym.
Od raportu do decyzji: automatyczne wypisanie i segregacja
Pierwsza reakcja zawsze identyczna: adres wypada z listy natychmiast, bez pytania i bez maila potwierdzającego. Kolejna wysyłka do kogoś, kto zgłosił spam, kosztuje reputację i jest problemem prawnym, bo zgoda została faktycznie cofnięta.
- Wypisz adres z listy, trwale i bez potwierdzania.
- Oznacz kampanię i szablon, z którego poszła wiadomość.
- Sprawdź źródło pozyskania adresu: formularz, import, integracja.
- Porównaj wynik z sąsiednimi wysyłkami do tego samego segmentu.
- Wstrzymaj kolejną turę do czasu wyjaśnienia przyczyny.
Zgłoszenia agreguj po kampanii, szablonie, źródle adresu i segmencie. Dopiero taki przekrój pokazuje przyczynę. Skok po jednej wysyłce to zwykle treść, temat albo nazwa nadawcy. Stałe tło skarg oznacza problem z bazą. No i tu nie ma co się oszukiwać, bo bazy same się nie naprawią. Jeśli adresy wpadają z zewnętrznego sklepu, CRM-u albo formularza, sprawdź, jakie integracje z systemami zbierającymi adresy masz podłączone - to tam zwykle siedzi źródło skarg.
Tip: trzymaj skargi razem z twardymi odrzuceniami i sygnałami zaangażowania w jednym widoku. Pojedynczy wskaźnik nigdy nie wyjaśnia całości.
Czego feedback loop nie pokaże i jak uzupełnić obraz
Filtr potrafi odłożyć wiadomość do spamu bez udziału odbiorcy. Wtedy żadnego zgłoszenia nie będzie, a wysyłka i tak przepadła. Duzi dostawcy różnie definiują próg akceptowalnej liczby skarg i nie publikują go jako twardej reguły, więc planowanie „pod limit” jest zgadywaniem. Ładnym, ale zgadywaniem.
Raporty ARF uzupełniaj raportami zbiorczymi DMARC oraz panelami reputacji nadawcy tam, gdzie operator taki udostępnia. Skrzynki testowe i monitoring umieszczenia wiadomości pokazują to, czego skargi nie pokażą - tylko pamiętaj, że to próbka, nie pomiar całej listy. Odrzucenia miękkie i twarde czytaj razem ze skargami. Te same kampanie zwykle świecą w obu miejscach naraz.
Uczciwie: część naszej pracy nad rozbudowanym raportowaniem zgłoszeń w panelu jest jeszcze przed nami. Opisuję tu praktykę branżową i to, jak sami prowadzimy wysyłkę, a nie gotowy ekran do kliknięcia.
Wychodzenie z blokady: co robimy, gdy skargi urosną
Z doświadczenia z własną flotą serwerów wysyłkowych: blokada u dużego filtra prawie nigdy nie zaczyna się od całej infrastruktury. Zaczyna się od jednego adresu IP i jednego klienta.
Pierwszy krok to zatrzymanie źródła, nie pisanie do dostawcy. Zgłoszenie o odblokowanie bez naprawy przyczyny nie daje nic poza stratą czasu. Sprawdziłem to wystarczająco wiele razy. Potem rozdzielasz ruch: transakcyjny i marketingowy na osobnych adresach IP i poddomenach, żeby jedna kampania nie topiła powiadomień systemowych. Powrót prowadzisz przez rozgrzewanie - mniejsze wolumeny, najbardziej aktywni odbiorcy, wzrost dopiero po ustabilizowaniu wskaźników.
Reguła, przy której zostajemy: klienci z bazą nieznanego pochodzenia nie wysyłają z naszej infrastruktury. Bo żadne działanie po naszej stronie nie omija filtrów. Zmniejsza tylko liczbę powodów, dla których filtr ma cię zatrzymać.
Zgoda i prawo: skargi jako sygnał problemu z bazą
Wysoka liczba zgłoszeń zwykle znaczy jedno: odbiorca nie pamięta zapisu albo zapisu nigdy nie było. RODO wymaga wykazania zgody, a to konkretne dane - data, treść klauzuli, adres IP zapisu, źródło formularza. Sam eksport adresów niczego nie dowodzi.
Prawo komunikacji elektronicznej, artykuł 398, obejmuje również adresy firmowe. W B2B zgoda jest wymagana tak samo jak w wysyłce do konsumentów. Dla wielu firm z odziedziczonymi bazami to spore zaskoczenie. Widoczne wypisanie w każdej wiadomości realnie obniża liczbę skarg, bo daje odbiorcy wyjście prostsze niż przycisk „spam”.
Najczęstsze źródło zgłoszeń, jakie widzimy: bazy przejęte po poprzednim narzędziu i adresy z zakupu. Jeśli chcesz zestawić to z porządną podstawą techniczną, sprawdź, jak działa wysyłka z własnej infrastruktury zgodna z RODO.
Podsumowanie: rutyna zamiast reagowania po fakcie
Feedback loop działa tylko wtedy, gdy raporty trafiają do procesu, a nie do skrzynki, do której nikt nie zagląda. Minimalna rutyna wygląda tak: odbiór raportów, natychmiastowe wypisanie adresu, przypisanie zgłoszenia do kampanii, przegląd zbiorczy raz w tygodniu. Uwierzytelnienie i porządek w bazie robisz przed rejestracją w feedback loop, nie po pierwszej blokadzie. I na koniec rzecz, którą powtarzam każdemu klientowi: skargi mierzą przede wszystkim to, jak zbierasz adresy, a dopiero potem to, jak piszesz maile.
