Zarządzanie listą

Ten rozdział odpowiada na pytanie, jak utrzymać listy odbiorców w czystości, byś wysyłał wyłącznie do osób, które mogą i powinny otrzymywać Twoją pocztę. To operacyjny odpowiednik Dostarczalności: uwierzytelnianie i reputacja wpuszczają Cię do skrzynki odbiorczej, ale brudna lista po cichu osłabia oba te elementy w czasie. Każdy martwy adres, na który dalej wysyłasz, każda zignorowana skarga, każdy nieaktywny subskrybent, którego się trzymasz, ciągnie Twoją reputację nadawcy w dół.

Zasada podstawowa: zawsze taniej jest nie wysłać złego maila niż go wysłać i radzić sobie z konsekwencjami. Supresja i higiena to sposób, w jaki systematycznie unikasz wysyłania złych maili.

To nie jest opcjonalne udoskonalenie. Od lutego 2024 wymogi dla masowych nadawców Gmaila, Yahoo i Microsoftu czynią z higieny listy twardą bramkę: każda domena wysyłająca z grubsza 5000+ wiadomości dziennie do tych skrzynek musi utrzymać wskaźnik zgłoszeń spamu przez użytkowników poniżej 0,3% (a oczekuje się, że bliżej 0,1%), uwierzytelniać się za pomocą SPF, DKIM i DMARC oraz oferować wypis jednym kliknięciem zgodny z RFC 8058 w poczcie marketingowej. Lista pełna martwych i niezaangażowanych adresów to najszybszy sposób na przekroczenie pułapu 0,3% skarg, bo skargi liczone są względem dostarczonego wolumenu, a martwe adresy zawyżają mianownik tylko do momentu, gdy odbiją, po czym pozostała niezaangażowana reszta podbija wskaźnik w górę. Zarządzanie listą jest zatem warunkiem koniecznym umieszczenia w skrzynce odbiorczej u największych dostawców skrzynek, a nie miłym dodatkiem.

Szybkie odpowiedzi na pytania z tego rozdziału:

• Czym jest lista supresji i po co mi ona?
• Które adresy poddawać supresji, a które mogę kiedykolwiek przywrócić?
• Jak sprawdzać supresję przed każdą wysyłką?
• Czym jest higiena list i jak często uruchamiać każde zadanie czyszczenia?
• Usuwać nieaktywnych subskrybentów czy najpierw próbować ich odzyskać?
• Jak długo przechowywać każdy rodzaj danych e-mail?
• Które metryki mówią mi, że lista się psuje?
• Czy listy transakcyjne i marketingowe powinny być osobne?

Czym jest lista supresji i po co mi ona?

Lista supresji to trwały rejestr „nigdy tu nie wysyłaj”. Zapobiega wysyłaniu na adresy, które nigdy nie powinny otrzymać poczty, na przykład te, które zaliczyły hard bounce lub złożyły skargę na spam.

Pomyśl o niej jak o barierce stojącej przed każdą wysyłką. Zanim jakakolwiek wiadomość wyjdzie, sprawdzasz odbiorcę względem tej listy. Jeśli na niej jest, nie wysyłasz. To pojedyncze sprawdzenie jest najważniejszym zabezpieczeniem dostarczalności, jakie możesz zbudować, bo najszybszym sposobem na zrujnowanie reputacji nadawcy jest dalsze mailowanie na adresy, które odbijają lub się skarżą.

Lista supresji to coś innego niż lista wypisów czy audytorium marketingowe. To niskopoziomowa warstwa bezpieczeństwa obejmująca cały Twój system wysyłki, w tym pocztę transakcyjną dla najbardziej szkodliwych sygnałów (hard bounce i skargi).

Supresja u dostawcy kontra Twoja własna lista supresji

Większość dostawców poczty (Amazon SES, Postmark, SendGrid, Mailgun, Resend, Brevo, SparkPost, Mandrill) utrzymuje własną listę supresji i po cichu odrzuci wysyłki na adresy, które na niej są. To nie zastępuje prowadzenia własnej listy. Są trzy powody, dla których musisz być właścicielem tych danych:

• Przenośność. Supresja dostawcy żyje wewnątrz dostawcy. Jeśli migrujesz między ESP, rutynowe zdarzenie podczas incydentu dostarczalności lub renegocjacji cennika, startujesz u nowego dostawcy z pustą listą supresji i natychmiast ponownie mailujesz na każdy hard bounce i do każdego skarżącego, jakiego kiedykolwiek miałeś. Posiadanie danych oznacza, że migracja to eksport/import, a nie reset reputacji.
• Spójność między dostawcami. Dojrzali nadawcy dzielą ruch między wielu dostawców (na przykład transakcyjne u jednego, marketingowe u drugiego, albo podstawowy i awaryjny). Odbicie zaobserwowane u dostawcy A musi supresować również u dostawcy B. Tylko centralny magazyn, który kontrolujesz, może to wyegzekwować.
• Widoczność i analityka. Pulpity dostawców pokazują ich widok. Twoja własna tabela pozwala łączyć zdarzenia supresji z kampaniami, segmentami i partiami importu, byś mógł odpowiedzieć na pytanie „która wysyłka spowodowała ten skok?”, zobacz source_email_id poniżej.

Traktuj listę supresji dostawcy jako zabezpieczenie awaryjne i źródło prawdy dla zdarzeń odbić/skarg (dostarczanych przez webhooki; zobacz Webhooki i zdarzenia), a swoją własną bazę danych jako miarodajną bramkę, przez którą przechodzi każda wysyłka.

Które adresy poddawać supresji, a które mogę kiedykolwiek przywrócić?

Hard bounce i skargi poddawaj supresji natychmiast i nigdy ich nie przywracaj. Soft bounce poddawaj supresji po 3 niepowodzeniach, a ręczne usunięcia na żądanie, i te dwa można cofnąć w kontrolowanych warunkach.

Dlaczego każda zasada działa tak, jak działa:

• Hard bounce, dodaj natychmiast, nigdy nie cofaj. Adres jest trwale nieprawidłowy. Ponowna wysyłka nigdy się nie powiedzie i tylko sygnalizuje dostawcom słabą higienę listy.
• Skarga, dodaj natychmiast, nigdy nie cofaj. Odbiorca wyraźnie powiedział „to jest spam”. Dalsze mailowanie do niego to zarazem zabójca reputacji i, w wielu jurysdykcjach, naruszenie prawa. Honoruj to na stałe.
• Soft bounce (3x), dodaj po przekroczeniu progu, można cofnąć po 30 do 90 dniach. Pojedynczy soft bounce jest przejściowy (pełna skrzynka, niedziałający serwer). Po 3 niepowodzeniach zachowuje się jak problem trwały, więc poddaj supresji. Ponieważ przyczyna mogła być tymczasowa, adres można ponowić po okresie wystudzenia.
• Ręczne usunięcie, dodaj na żądanie, cofaj tylko jeśli użytkownik poprosi. Użytkownik poprosił o usunięcie. Uszanuj jego wybór. Dodaj go ponownie tylko, jeśli sam się zapisze (opt-in).

Kluczowe rozróżnienie to odwracalność. Hard bounce i skargi są trwałe i nigdy nie mogą być po cichu reaktywowane. Supresje z soft bounce i ręczne można cofnąć, ale tylko w kontrolowanych warunkach.

Co liczy się jako hard bounce, a co jako soft bounce?

Hard bounce to trwałe niepowodzenie: skrzynka nie istnieje, domena nie istnieje albo serwer trwale odrzucił wiadomość (kody SMTP 5.x.x). Soft bounce to niepowodzenie tymczasowe: skrzynka jest pełna, serwer nie działa albo wiadomość trafiła na greylisting (często kody SMTP 4.x.x). Hard bounce traktuj jako ostateczny, a soft bounce jako możliwy do ponowienia, dopóki nie przekroczy progu 3 niepowodzeń.

Kod odpowiedzi SMTP i jego rozszerzony kod statusu (RFC 3463, trójka class.subject.detail w stylu 5.1.1) to sposób, w jaki klasyfikujesz odbicie mechanicznie. Pierwsza cyfra to werdykt; rozszerzony kod mówi dlaczego.

Dwa ważne przypadki brzegowe, które prosty podział hard/soft pomija:

• Odbicia blokujące to nie problemy z adresem. Odrzucenie 5.7.1 albo „zablokowano z powodu reputacji / na liście blokującej” to serwer odbiorczy odmawiający Tobie, a nie informacja, że adres jest martwy. Supresja adresu to zła reakcja, odrzucałbyś dobrych odbiorców, by ukryć problem reputacji lub uwierzytelniania. Traktuj odbicia blokujące jako sygnał dostarczalności (zobacz Dostarczalność), a 5.7.26 w szczególności jako niepowodzenie uwierzytelniania do naprawienia (SPF wg RFC 7208, DKIM wg RFC 6376, DMARC wg RFC 7489), a nie jako zdarzenie supresji.
• Odbicia asynchroniczne. Wiele serwerów przyjmuje wiadomość w czasie SMTP (250), a odbija ją później przez Delivery Status Notification (mail „backscatter” lub DSN na Twój return-path). Twój dostawca wystawia je jako webhooki odbić od kilku minut do kilku godzin po wysyłce. Twoja logika klasyfikacji musi działać na zdarzeniu webhooka, a nie tylko na synchronicznej odpowiedzi SMTP, bo inaczej przegapisz większość prawdziwych odbić.

Nie dopasowuj wzorców do tekstu wolnego z komunikatów odbić, jeśli możesz tego uniknąć; są dziko niespójne między dostawcami. Preferuj znormalizowane przez dostawcę bounce_type/bounce_subtype plus rozszerzony kod statusu, a do wolnego tekstu sięgaj tylko w niejednoznacznych przypadkach.

Jak przechowywać wpisy supresji w bazie danych?

Co przechowuje wpis supresji:

Przechowuj jeden wiersz na adres z powodem supresji, czasem jej wystąpienia i informacją, który mail ją wywołał. Zapisanie powodu to właśnie to, co pozwala stosować powyższe zasady odwracalności.

// Suppression list schema
interface SuppressionEntry {
  email: string;
  reason: 'hard_bounce' | 'complaint' | 'unsubscribe' | 'soft_bounce' | 'manual';
  created_at: Date;
  source_email_id?: string; // Który email to wywołał
}

// Sprawdzenie przed każdą wysyłką
async function canSendTo(email: string): Promise<boolean> {
  const suppressed = await db.suppressions.findOne({ email });
  return !suppressed;
}

// Dodanie do listy supresji
async function suppressEmail(email: string, reason: string, sourceId?: string) {
  await db.suppressions.upsert({
    email: email.toLowerCase(),
    reason,
    created_at: new Date(),
    source_email_id: sourceId,
  });
}

Co warto zauważyć w tym schemacie i dlaczego to ważne:

• reason to enum, a nie wolny tekst. Zapisanie, dlaczego adres został poddany supresji, to właśnie to, co pozwala stosować zasady odwracalności. Nigdy nie cofniesz hard_bounce ani complaint, ale możesz wrócić do soft_bounce. Przechowywanie powodu zasila też analitykę (czy lista rośnie przez odbicia, czy skargi?).
• source_email_id zapisuje, co wywołało supresję. Gdy na liście supresji pojawia się skok, to pole pozwala prześledzić go z powrotem do konkretnej kampanii lub wiadomości, która go spowodowała.
• suppressEmail zamienia adres na małe litery (email.toLowerCase()). Części lokalne adresów są w praktyce niewrażliwe na wielkość liter. Normalizacja zapobiega traktowaniu User@x.com i user@x.com jako dwóch różnych osób, co pozwoliłoby supresowanym adresom się prześlizgnąć.
• upsert jest idempotentny. Supresja już supresowanego adresu to operacja bez efektu, a nie błąd, co ma znaczenie, bo to samo zdarzenie odbicia lub skargi może zostać dostarczone więcej niż raz przez webhooki (zobacz Webhooki i zdarzenia).
• canSendTo zwraca wartość logiczną i ma być tani. Uruchamia się przed każdą wysyłką, więc magazyn supresji powinien być zindeksowany po email dla szybkich wyszukiwań.

Poprawna normalizacja adresów (i czego nie normalizować)

Zamiana na małe litery jest konieczna, ale niewystarczająca, a nadmierna normalizacja to osobny błąd. Zasady zgodne ze standardami:

• Domena jest niewrażliwa na wielkość liter i powinna być zapisana małymi literami. Example.COM i example.com to ten sam host.
• Część lokalna jest, zgodnie z RFC 5321, technicznie wrażliwa na wielkość liter, ale w praktyce każdy większy dostawca traktuje ją jako niewrażliwą, a traktowanie jej jako wrażliwej pozwala supresowanemu User@x.com prześlizgnąć się jako user@x.com. Zamiana całego adresu na małe litery to pragmatyczny, bezpieczny wybór dla bramki supresji.
• Nie usuwaj kropek ani +tagów na potrzeby supresji. Gmail ignoruje kropki i traktuje + jako sub-adres, więc j.doe+news@gmail.com trafia do tej samej skrzynki co jdoe@gmail.com. Kusi, by je „kanonizować”. Nie rób tego na ścieżce supresji: zasady dostawców się różnią (to zachowanie specyficzne dla Gmaila), klucz supresji musi dokładnie pasować do tego, co przekażesz do pola to: dostawcy, a agresywna kanonizacja supresuje niewinne osoby trzecie, które prawowicie współdzielą adres bazowy. Kanonizacja należy do deduplikacji przy zapisie (zobacz Pozyskiwanie adresów), a nie do bramki w czasie wysyłki.
• Przed zapisem usuń białe znaki i odrzuć znaki kontrolne, końcowa spacja lub \r\n to klasyczne źródło sytuacji „sprawdzenie supresji przeszło, ale wysyłka i tak poszła”.

function normalizeEmail(raw: string): string {
  const trimmed = raw.trim();
  const at = trimmed.lastIndexOf('@');
  if (at <= 0 || at === trimmed.length - 1) {
    throw new Error(`Invalid email: ${raw}`);
  }
  const local = trimmed.slice(0, at);
  const domain = trimmed.slice(at + 1).toLowerCase();
  // Cały adres na małe litery do dopasowania; NIE usuwaj tu kropek ani +tagów.
  return `${local}@${domain}`.toLowerCase();
}

Schemat, indeksowanie i skala

Dla czegokolwiek powyżej kilkuset tysięcy wierszy tabela relacyjna z właściwym indeksem to najprostszy poprawny wybór:

CREATE TABLE suppressions (
  email           TEXT        NOT NULL,
  reason          TEXT        NOT NULL CHECK (reason IN
                    ('hard_bounce','complaint','unsubscribe','soft_bounce','manual')),
  created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
  source_email_id TEXT,
  PRIMARY KEY (email)
);

-- Szybkie wyszukiwania punktowe na ścieżce wysyłki gwarantuje klucz główny.
-- Indeks reason + czas dla zapytań higieny i analizy skoków.
CREATE INDEX idx_suppressions_reason_created ON suppressions (reason, created_at);

Uwagi o skali i opóźnieniach:

• Wyszukiwanie na ścieżce wysyłki musi być trafieniem w klucz główny / indeks unikalny, nigdy skanem. Przy wysokich tempach wysyłki to zapytanie uruchamia się miliony razy dziennie; niezindeksowane wyszukiwanie zdominuje opóźnienie wysyłki i obciążenie bazy.
• Przy bardzo wysokiej przepustowości postaw przed wyszukiwaniem cache. Zbiór Redis lub filtr Blooma załadowany z tabeli supresji zamienia częsty przypadek „niesupresowany” w sprawdzenie w pamięci. Filtr Blooma jest idealny, bo fałszywe trafienia pozytywne można w miarę bezpiecznie zweryfikować względem źródła prawdy, a fałszywe trafienia negatywne są niemożliwe, więc nigdy nie przegapisz supresji, najwyżej od czasu do czasu sprawdzisz ponownie. Odświeżaj go przy każdym zapisie supresji.
• Supresja jest głównie dopisywana. Usunięcia (cofnięcia supresji) są rzadkie i powinny być audytowane (zobacz niżej). Nie uruchamiaj destrukcyjnego czyszczenia na tej tabeli.

Audytowanie cofania supresji

Ponieważ supresje z soft bounce i ręczne są odwracalne, akt usunięcia wiersza musi zostawiać ślad. Nigdy nie usuwaj supresji twardo i po cichu. Albo zastosuj usunięcie miękkie z removed_at/removed_reason, albo przenieś wiersz do tabeli audytowej suppression_history. Chroni Cię to na dwa sposoby: dowodzi audytorowi, że na skargę nigdy ponownie nie zmailowano, i pozwala odtworzyć, kto zdecydował o cofnięciu supresji adresu i dlaczego, jeśli incydent reputacyjny do tego prowadzi.

Jak sprawdzać supresję przed każdą wysyłką?

Opakuj wywołanie dostawcy w jedną funkcję, która najpierw sprawdza supresję i zwraca wynik wcześnie, jeśli adres jest supresowany. Uczyń tę funkcję jedyną ścieżką do dostawcy.

async function sendEmail(to: string, emailData: EmailData) {
  if (!await canSendTo(to)) {
    console.log(`Skipping suppressed email: ${to}`);
    return { skipped: true, reason: 'suppressed' };
  }

  return await emailClient.send({ to, ...emailData });
}

Dlaczego ten wrapper istnieje: supresja działa tylko wtedy, gdy każda ścieżka do Twojego dostawcy poczty przechodzi przez to sprawdzenie. Wzorzec polega na uczynieniu sendEmail jedynym wąskim gardłem. Żaden kod nie wywołuje SDK dostawcy (emailClient.send) bezpośrednio. Jeśli choć jedna ścieżka kodu ominie sprawdzenie, supresowane adresy się prześlizgną, a Twoja reputacja ucierpi.

Uwagi praktyczne:

• Funkcja zwraca ustrukturyzowany wynik ({ skipped: true, reason: 'suppressed' }) zamiast rzucać wyjątek. Supresowany odbiorca to oczekiwany, normalny wynik, a nie błąd. Wywołujący powinni móc go obsłużyć bez try/catch.
• Logowanie pominiętych wysyłek daje wgląd: rosnąca liczba pominięć może ujawnić, że wielokrotnie próbujesz mailować na adresy, które już poddałeś supresji (na przykład nieaktualny segment).
• To sprawdzenie dotyczy zarówno poczty transakcyjnej, jak i marketingowej w przypadku hard bounce i skarg (zobacz sekcję transakcyjne kontra marketingowe poniżej).

Bramkowanie świadome powodu: supresja nie zawsze działa na zasadzie wszystko albo nic

Naiwny canSendTo traktuje każdą supresję jednakowo. To poprawne dla hard bounce i skarg, które supresują wszystkie strumienie, ale zbyt tępe dla unsubscribe, który dotyczy tylko marketingu. Użytkownik, który wypisał się z Twojego newslettera, musi nadal otrzymać reset hasła. Uczyń bramkę świadomą zarówno powodu supresji, jak i strumienia wysyłanej wiadomości.

type Stream = 'transactional' | 'marketing';

// powody, które blokują każdy strumień, trwale i bezwarunkowo
const HARD_BLOCK_REASONS = new Set(['hard_bounce', 'complaint']);

async function canSendTo(email: string, stream: Stream): Promise<boolean> {
  const entry = await db.suppressions.findOne({ email: normalizeEmail(email) });
  if (!entry) return true;

  // Hard bounce i skargi blokują wszystko, zawsze.
  if (HARD_BLOCK_REASONS.has(entry.reason)) return false;

  // Wypisy i ręczne usunięcia domyślnie dotyczą tylko marketingu.
  if (stream === 'marketing') return false;

  // Transakcyjne mogą wciąż przejść dla unsubscribe / soft_bounce / manual.
  return true;
}

Ta pojedyncza funkcja koduje teraz całą politykę międzystrumieniową: hard bounce i skargi supresują wszystko; wypisy i ręczne usunięcia zatrzymują marketing, ale przepuszczają transakcyjne; supresja z soft bounce (skrzynka niedostarczalna w tej chwili) blokuje marketing, ale możesz wybrać, by wciąż spróbować dostarczyć krytyczną wiadomość transakcyjną, bo alternatywą jest to, że użytkownik nigdy nie dostanie swojego potwierdzenia. Uczyń strumień jawnym, wymaganym argumentem, by żaden wywołujący nie mógł „zapomnieć” zadeklarować, jaki rodzaj poczty wysyła.

Wysyłki masowe: filtruj, nie pętluj

Dla kampanii do 100 000 odbiorców wywoływanie canSendTo raz na adres w pętli jest zarazem wolne i ściga się z równoległymi zapisami supresji. Zamiast tego rozwiąż supresję jako operację na zbiorze w czasie wysyłki, tuż przed przekazaniem partii dostawcy:

async function filterSuppressed(emails: string[], stream: Stream): Promise<string[]> {
  const normalized = emails.map(normalizeEmail);
  const suppressed = await db.suppressions.find({
    email: { $in: normalized },
    ...(stream === 'marketing'
      ? {} // marketing: dowolny powód supresji blokuje
      : { reason: { $in: ['hard_bounce', 'complaint'] } }), // transakcyjne: tylko twarde blokady
  });
  const blocked = new Set(suppressed.map((s) => s.email));
  return normalized.filter((e) => !blocked.has(e));
}

Rozwiązuj to tak późno, jak się da, najlepiej w momencie wysyłki, a nie gdy kampania trafia do kolejki. Kampania zakolejkowana o 9:00 i wysłana o 9:30 musi uszanować każdy wypis i każdą skargę, które przyszły w tej połowie godziny. Ponowne sprawdzenie w czasie nadania to sposób na to, by „ale to było już w kolejce” nigdy nie było prawdziwą wymówką.

Jakie są typowe błędy przy sprawdzaniu supresji?

• Omijanie wrappera. Nowa funkcja wywołuje SDK dostawcy bezpośrednio „tylko ten jeden raz”, i supresowane adresy się prześlizgują. Skanuj kod (lint lub grep) w poszukiwaniu bezpośrednich wywołań dostawcy, by to wyłapać.
• Wrażliwość na wielkość liter. Przechowywanie adresów z mieszaną wielkością liter, ale sprawdzanie ich surowym wejściem. Zawsze normalizuj do małych liter zarówno przy zapisie, jak i odczycie.
• Sprawdzanie po wysłaniu. Sprawdzenie musi działać przed wywołaniem dostawcy, a nie w webhooku, gdy dostarczenie już zostało podjęte.
• Brak indeksu na email. Pełne skanowanie tabeli przy każdej wysyłce dodaje opóźnienie. Zindeksuj kolumnę wyszukiwania.
• Sprawdzanie tylko w czasie kolejkowania. Sprawdzaj ponownie w czasie nadania, by uszanować supresje dodane między zakolejkowaniem a wysyłką.
• Traktowanie odbić blokujących jako supresji. Blokada 5.7.1/reputacyjna to nie martwy adres. Jej supresja odrzuca dobrych odbiorców i ukrywa prawdziwy problem.
• Ufanie liście dostawcy jako jedynej kopii. Gdy migrujesz dostawców, ta lista nie idzie z Tobą. Prowadź własną.

Czym jest higiena list i czym różni się od supresji?

Higiena list to ciągły program szybkiego usuwania problematycznych adresów i przycinania subskrybentów, którzy ostygli. Supresja obsługuje trwałe przypadki „nigdy więcej tu nie wysyłaj”. Higiena to szersza, ciągła konserwacja wokół niej.

Celem jest lista mała, zaangażowana i czysta, co jest o wiele zdrowsze dla dostarczalności niż duża lista pełna martwego balastu. Lista 10 000 adresów, gdzie otwiera 9 000 osób, jest warta więcej niż lista 100 000 adresów, gdzie otwiera 5 000.

Rozróżnienie w jednej linii: supresja jest binarna i trwała (czy kiedykolwiek tu wyślę?); higiena jest stopniowalna i ciągła (czy powinienem dalej tu wysyłać?). Supresja chroni Cię przed sygnałami katastrofalnymi, odbiciami i skargami. Higiena chroni przed powolnym gniciem niezaangażowania, które faktycznie przepycha domenę powyżej progu 0,3% skarg i do folderu spamu.

Walidacja przy zapisie to najtańsza higiena, jaka istnieje

Najczystsza lista to taka, która nigdy nie wpuściła złego adresu. Przesunięcie walidacji na sam moment zapisu usuwa większość przyszłych hard bounce, zanim w ogóle kosztują Cię reputację:

• Sprawdzenie składni + MX. Odrzucaj adresy niespełniające składni RFC 5321 albo takie, których domena nie ma rekordu MX (lub A). Domena bez serwera pocztowego nie może odbierać poczty.
• Blokowanie domen jednorazowych. Utrzymuj lub subskrybuj listę domen jednorazowych/tymczasowych, jeśli Twój produkt tego wymaga.
• Potwierdzony opt-in (double opt-in) dla marketingu. Wymaganie od subskrybenta kliknięcia linku potwierdzającego dowodzi w jednym kroku, że adres jest prawdziwy, osiągalny i wyrażający zgodę. To pojedynczo najskuteczniejszy środek higieny dla listy marketingowej.
• Korekta literówek. Sugeruj gmail.com, gdy użytkownik wpisuje gmial.com. To odzyskuje prawdziwych subskrybentów, którzy inaczej zaliczyliby hard bounce.

Mechanika robienia tego na formularzu jest w Pozyskiwaniu adresów; chodzi tu o to, że walidacja przy zapisie i higiena w czasie działania to dwa końce tego samego programu.

Jak często uruchamiać każde zadanie czyszczenia?

Najbardziej szkodliwe czyszczenia uruchamiaj w czasie rzeczywistym, soft bounce codziennie, a przycinanie nieaktywnych miesięcznie.

Więcej: dobre praktyki nadawców M3AAWG (https://www.m3aawg.org/published-documents) oraz wskazówki Twojego dostawcy dotyczące higieny listy.

Dlaczego rytm różni się dla każdego zadania:

• Hard bounce i skargi, czas rzeczywisty. To najbardziej szkodliwe sygnały, więc reakcja musi być natychmiastowa. Podpięcie ich do webhooków (zobacz Webhooki i zdarzenia) oznacza, że w momencie, gdy dostawca zgłosi odbicie lub skargę, adres zostaje poddany supresji, zanim zdążysz na niego ponownie wysłać.
• Wypisy, czas rzeczywisty. Prawnie i etycznie wypis musi zadziałać natychmiast. Nie możesz wysłać jeszcze jednej kampanii „bo była już w kolejce”. Przetwarzaj je w chwili nadejścia.
• Soft bounce, codziennie. Pojedynczy soft bounce nie wymaga działania, więc przegląda się je w codziennej paczce, poddając supresji tylko adresy, które przekroczyły próg 3 niepowodzeń.
• Nieaktywni subskrybenci, miesięcznie. Spadek zaangażowania jest stopniowy, więc miesięcznie jest wystarczająco często. Nie usuwaj nieaktywnych od razu. Przeprowadź ich najpierw przez reaktywację.

Reagowanie na skargi: Feedback Loop (FBL)

Powyższa supresja skarg w czasie rzeczywistym zależy od faktycznego otrzymywania skarg. Są dwa kanały i powinieneś podpiąć oba:

• Webhooki skarg od dostawcy. Twój ESP przekazuje skargi na spam, które otrzymuje w Twoim imieniu, jako zdarzenia complaint/spam. To kanał podstawowy i ten, na którym wisi Twoje wywołanie suppressEmail(..., 'complaint').
• Feedback Loops dostawców skrzynek. Kilku dostawców udostępnia FBL: gdy użytkownik klika „zgłoś spam”, dostawca skrzynki odsyła nadawcy raport ARF (Abuse Reporting Format). SNDS/JMRP Microsoftu i CFL Yahoo to przykłady. Jeśli prowadzisz własną infrastrukturę wysyłki, a nie polegasz całkowicie na ESP, zapisz się do tych FBL; jeśli używasz ESP, potwierdź, że jest do nich zapisany w Twoim imieniu i przekazuje Ci raporty.

Gmail jest godnym uwagi wyjątkiem: nie oferuje FBL na poziomie wiadomości. Zamiast tego udostępnia zagregowane dane o skargach i reputacji przez Google Postmaster Tools, dlatego monitorowanie wykresu wskaźnika skarg w Postmaster to jedyny sposób, by zobaczyć swój wskaźnik skarg Gmaila względem progu 0,3%. Skonfiguruj Postmaster Tools dla każdej domeny wysyłkowej.

Wypis jednym kliknięciem to część higieny, nie tylko zgodności

Od lutego 2024 poczta marketingowa do Gmaila/Yahoo/Microsoftu musi wdrażać wypis jednym kliknięciem zgodny z RFC 8058. To mechanizm higieny w równym stopniu co prawny: bezproblemowy wypis to coś, co powstrzymuje zirytowanego odbiorcę od kliknięcia „zgłoś spam” zamiast tego, a skarga jest o wiele bardziej szkodliwa niż wypis. Musisz dołączyć oba nagłówki (URL/mailto List-Unsubscribe z RFC 2369 oraz List-Unsubscribe-Post z RFC 8058), bo to token POST mówi dostawcy skrzynki, że na link można zadziałać bez strony potwierdzenia:

List-Unsubscribe: <https://mail.example.com/u/8f2a...>, <mailto:unsubscribe@example.com?subject=unsub-8f2a>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Dostawca skrzynki wysyła POST z treścią List-Unsubscribe=One-Click na Twój URL. Twój endpoint musi go przetworzyć w ciągu (wymogi mówią) dwóch dni i nie może wymagać od użytkownika logowania ani potwierdzenia. Podepnij endpoint wprost do suppressEmail(address, 'unsubscribe') dla strumienia marketingowego. Pełna mechanika, w tym fallback mailto i podpisywanie tokena, jest w Mailach marketingowych i Zgodności prawnej.

Usuwać nieaktywnych subskrybentów czy najpierw próbować ich odzyskać?

Najpierw próbuj ich odzyskać. Przeprowadź nieaktywnych subskrybentów przez kampanię reaktywacyjną przed usunięciem, byś nie wyrzucał osób możliwych do odzyskania.

Wykonaj te cztery kroki, zanim usuniesz nieaktywnych subskrybentów:

1. Zidentyfikuj nieaktywnych: Brak otwarć lub kliknięć przez 45 do 90 dni.
2. Wyślij reaktywację: „Tęsknimy za Tobą” lub „Wciąż zainteresowany?”
3. Poczekaj 14 do 30 dni na odpowiedź.
4. Usuń nieodpowiadających z list aktywnych.

async function runReengagement() {
  const inactive = await getInactiveSubscribers(90); // 90 dni

  for (const subscriber of inactive) {
    if (!subscriber.reengagement_sent) {
      await sendReengagementEmail(subscriber);
      await markReengagementSent(subscriber.email);
    } else if (daysSince(subscriber.reengagement_sent) > 30) {
      await removeFromMarketingLists(subscriber.email);
    }
  }
}

Dlaczego reaktywować zamiast po prostu usuwać: nieaktywni subskrybenci szkodzą dostarczalności. Obniżają Twój wskaźnik zaangażowania, a długo uśpione adresy mogą zamienić się w pułapki spamowe. Ale niektórzy „nieaktywni” są po prostu zajęci, a nie straceni. Kampania reaktywacyjna to ostatnia, kontrolowana próba odzyskania ich, zanim ich usuniesz, byś nie wyrzucał subskrybentów możliwych do odzyskania.

Jak kod realizuje cztery kroki:

• getInactiveSubscribers(90) wybiera wszystkich bez otwarć lub kliknięć w ciągu ostatnich 90 dni (krok 1).
• Dla każdego, kto jeszcze nie otrzymał maila reaktywacyjnego, wysyła go i zapisuje ten fakt przez markReengagementSent (krok 2). Zapisanie znacznika czasu jest kluczowe. Zapobiega ponownej wysyłce i uruchamia zegar odpowiedzi.
• Dla każdego, kto otrzymał maila reaktywacyjnego ponad 30 dni temu i wciąż nie odpowiedział, removeFromMarketingLists go przycina (kroki 3 i 4).

Uwagi praktyczne:

• Flaga lub znacznik czasu reengagement_sent to maszyna stanów: rozróżnia „jeszcze nie zapytano”, „zapytano, czekamy” i „zapytano, czas minął”.
• Usunięcie dotyczy list marketingowych w szczególności. Niepowodzenie reaktywacji nie poddaje supresji poczty transakcyjnej (zobacz niżej).
• Trzymaj tematy maili reaktywacyjnych szczere i proste („Wciąż zainteresowany?”). To nie miejsce na agresywne taktyki.

Ostrożność z zaangażowaniem opartym na otwarciach po Apple MPP

Od czasu Apple Mail Privacy Protection (2021) Apple wstępnie pobiera piksele śledzące dla użytkowników, którzy je włączyli, rejestrując „otwarcie” niezależnie od tego, czy człowiek przeczytał wiadomość. Oznacza to, że sam wskaźnik otwarć nie jest już wiarygodnym sygnałem zaangażowania, znacząca część Twoich „otwarć” jest generowana maszynowo. Konsekwencje dla powyższej logiki:

• Preferuj kliknięcia nad otwarciami jako podstawowy sygnał zaangażowania. Kliknięcie to prawdziwa ludzka akcja, której MPP nie podrabia.
• Używaj otwarć jako słabego sygnału negatywnego, nie pozytywnego. „Nigdy nie zarejestrował nawet otwarcia przez 90 dni” wciąż coś znaczy (MPP zwykle by jakieś wygenerowało), więc całkowity brak otwarć jest silniejszym sygnałem nieaktywności niż obecność otwarć jest sygnałem aktywności.
• Wmieszaj sygnały spoza poczty tam, gdzie je masz: ostatnie logowanie, ostatni zakup, ostatnia sesja w aplikacji. Subskrybent, który loguje się co tydzień, ale nigdy nie „otwiera” Twoich maili, jest zaangażowany z Twoim produktem, tylko nie z pocztą, traktuj go inaczej niż kogoś, kto całkiem zamilkł.

Polityki wygaszania: automatyczne ograniczanie spadku zaangażowania

Kampania reaktywacyjna to jednorazowy ratunek. Polityka wygaszania (sunset policy) to stała reguła, która automatycznie przestaje mailować na adresy poza zdefiniowanym horyzontem nieaktywności, by spadek zaangażowania nigdy nie narastał bez ograniczeń. Typowa polityka warstwowa:

Dostrój okna do swojego naturalnego rytmu wysyłki, nadawca codziennych ofert wygasza znacznie szybciej niż nadawca kwartalnego newslettera. Zasada jest stała: im dłużej ktoś Cię ignoruje, tym bardziej prawdopodobne, że Twoja poczta do niego trafia do spamu, co ciągnie w dół umieszczenie dla wszystkich pozostałych na liście. Wygaszanie to sposób, w jaki chronisz zaangażowaną większość przed martwym balastem mniejszości.

Czym jest pułapka spamowa i dlaczego martwe adresy się nią stają?

Pułapka spamowa to adres, którego dostawcy i operatorzy list blokujących używają do wyłapywania nadawców o słabej higienie listy. Pułapka pristine nigdy nie była prawdziwym użytkownikiem. Pułapka recyklingowa to prawdziwy adres, który został porzucony, a potem reaktywowany przez dostawcę wyłącznie po to, by flagować nadawców dalej na niego mailujących. Długo uśpione adresy na Twojej liście mogą po cichu stać się pułapkami recyklingowymi, i właśnie dlatego przycinasz nieaktywnych zamiast mailować na nich w nieskończoność.

Taksonomia pułapek i jak każda trafia na Twoją listę:

• Pułapki pristine nigdy nie były ważne i nigdy nie wyraziły zgody (opt-in). Trafienie w taką oznacza, że pozyskałeś adres, którego nigdy Ci nie dano, kupione listy, scrapowane adresy lub publiczny formularz bez walidacji. Trafienia pristine są najbardziej szkodliwe, bo dowodzą pozyskania bez zgody. Obroną jest nigdy nie kupować ani nie scrapować i stosować potwierdzony opt-in.
• Pułapki recyklingowe były prawdziwymi użytkownikami, którzy porzucili skrzynkę; po długim uśpieniu (często ~6–12 miesięcy bez logowań) dostawca przerabia teraz nieczynny adres na pułapkę. Pojawiają się na listach zbudowanych legalnie, to Twoi byli subskrybenci, którzy zamilkli. Obroną jest dokładnie powyższa polityka wygaszania: przestań mailować długo uśpionych zanim dostawca ich zrecyklinguje.
• Pułapki literówkowe to błędne pisownie popularnych domen (gmial.com, hotnail.com), które operatorzy rejestrują. Obroną jest korekta literówek przy zapisie (zobacz Pozyskiwanie adresów).

Pułapek nie da się zidentyfikować wprost, z założenia zmailowanie jednej nie daje ani odbicia, ani skargi, tylko cichą szkodę reputacyjną. Dlatego unikanie pułapek jest strukturalne: czyste pozyskiwanie, potwierdzony opt-in i agresywne wygaszanie to jedyne mechanizmy kontroli, i nie ma kroku naprawczego, który usuwa pułapkę z Twojej listy, bo nie wiesz, który to adres.

Jak długo przechowywać każdy rodzaj danych e-mail?

Dane operacyjne trzymaj wystarczająco długo, by debugować i raportować, dane wymagane prawnie przechowuj przez nakazane okresy, a dane objętościowe lub wrażliwe usuwaj, gdy tylko przestają na siebie zarabiać.

Dlaczego każdy okres retencji:

• Próby wysyłki i status dostarczenia, 90 dni. Wystarczająco długo, by debugować problemy z dostarczaniem i tworzyć sensowną analitykę, ale nie tak długo, by logi puchły. Większość pytań operacyjnych („czy ten użytkownik dostał maila w zeszłym tygodniu?”) mieści się spokojnie w 90 dniach.
• Zdarzenia odbicia i skargi, 3 lata. To ślad audytowy dowodzący, dlaczego adres znajduje się na Twojej liście supresji, i wspierają raportowanie dostarczalności, które możesz potrzebować pokazać dostawcy skrzynki lub audytorowi. (Zauważ, że prawny obowiązek prowadzenia rejestrów wg ustaw takich jak CASL dotyczy zachowania dowodu zgody, zobacz wiersz rejestrów zgód, a nie konkretnie zdarzeń odbić/skarg.)
• Lista supresji, bezterminowo, nigdy nie usuwaj. To jeden magazyn, który trzymasz na zawsze. Jego usunięcie pozwoliłoby trwale złym adresom (hard bounce, skargi) wrócić do Twojej wysyłki i ponownie nadszarpnąć reputację.
• Treść e-maila, 30 dni. Pełne treści wiadomości są objętościowe i to najbardziej wrażliwe dane, jakie posiadasz, więc trzymaj je tylko krótko. Wystarczająco długo, by zbadać niedawny incydent, a potem usuń, by kontrolować koszty przechowywania i ograniczać ekspozycję.
• Rejestry zgód, 3 lata po wygaśnięciu. Dowód zgody to wymóg prawny (zobacz Zgodność prawna). Trzymaj go długo po momencie, w którym sama zgoda wygasa, byś mógł wykazać, że miałeś pozwolenie.

To rozsądne wartości domyślne, a nie porada prawna, Twoje obowiązki retencyjne różnią się w zależności od jurysdykcji i podstawy prawnej, na której się opierasz. Tabela retencji równoważy trzy konkurujące presje: potrzebę operacyjną (musisz móc debugować i raportować), obowiązek prawny (niektóre rejestry musisz trzymać, a inne masz obowiązek nie trzymać dłużej niż to konieczne) oraz minimalizację ryzyka (każdy bajt danych odbiorcy, który posiadasz, to bajt, który może wyciec). Treść e-maila siedzi na końcu wysokiego ryzyka, może zawierać dane osobowe, linki resetujące hasło lub szczegóły faktury, dlatego ma najkrótszą retencję. Supresja i zgoda siedzą na końcu „musisz zachować”. Wszystko inne jest dostrojone pomiędzy.

Jak wdrożyć politykę retencji w kodzie?

Uruchamiaj codzienne zadanie czyszczenia, które usuwa każdą kategorię danych względem własnego progu odcięcia i nigdy nie rusza supresji ani rejestrów zgód.

// Codzienne zadanie czyszczenia
async function cleanupOldData() {
  const now = new Date();

  // Usuń stare logi maili (zachowaj 90 dni)
  await db.emailLogs.deleteMany({
    created_at: { $lt: subDays(now, 90) }
  });

  // Usuń starą treść maili (zachowaj 30 dni)
  await db.emailContent.deleteMany({
    created_at: { $lt: subDays(now, 30) }
  });

  // Nigdy nie usuwaj: supresji, rejestrów zgód
}

Co warto zauważyć i dlaczego to ważne:

• To zadanie codzienne. Retencja jest egzekwowana w sposób ciągły, a nie w sporadycznych ręcznych przeglądach. Codzienny rytm utrzymuje ograniczony rozmiar magazynu i zapewnia, że wrażliwa treść nigdy nie zalega daleko poza swoim 30-dniowym oknem.
• Każda kategoria jest usuwana względem własnego progu odcięcia. Logi używają odcięcia 90-dniowego (subDays(now, 90)); treść używa 30 dni. Progi pochodzą wprost z powyższej tabeli retencji.
• Komentarz // Never delete: suppressions, consent records jest nośny. To celowe przypomnienie, że dwa magazyny są świadomie wyłączone z czyszczenia. Przypadkowe dodanie ich tutaj byłoby poważnym błędem: straciłbyś trwałą ochronę supresji i prawny dowód zgody.
• Uruchamiaj poza szczytem. Masowe usuwanie mocno obciąża I/O. Zaplanuj zadanie na okno o niskim ruchu.

Jak uczynić zadanie retencji bezpiecznym i obserwowalnym

Zadanie masowego usuwania, które uruchamia się codziennie i „nigdy nie ma ruszać” dwóch tabel, to broń wymierzona we własną stopę. Utwardź je:

• Dziel usuwanie na partie. Pojedynczy deleteMany na zgromadzonych przez miesiące wierszach może zablokować tabelę lub rozdąć opóźnienie replikacji. Usuwaj w ograniczonych kawałkach (np. 10 000 wierszy na zapytanie) w pętli, aż nie zostanie żaden.
• Loguj liczby i alertuj na anomalie. Zapisuj, ile wierszy usunęła każda kategoria. Dzienna liczba usunięć, która nagle skacze o rząd wielkości, zwykle oznacza błąd w matematyce odcięcia albo problem z zegarem, powiadom o tym, zanim po cichu zniszczy dane.
• Preferuj listę dozwolonych usuwalnych tabel zamiast listy zabronionych. Zamiast polegać na komentarzu, by pamiętać, czego nie usuwać, zbuduj zadanie wokół jawnej listy { table, retentionDays }, których wolno mu dotykać. Supresja i zgoda są po prostu nieobecne na tej liście i przez to nieosiągalne dla zadania.
• Stosuj usuwanie miękkie lub partycjonowanie tam, gdzie się da. Tabele partycjonowane po czasie pozwalają usunąć całą partycję zamiast wydawać usunięcia wierszy, znacznie taniej i trudniej pomylić.

const RETENTION: Array<{ table: 'emailLogs' | 'emailContent'; days: number }> = [
  { table: 'emailLogs',    days: 90 },
  { table: 'emailContent', days: 30 },
  // supresja i zgoda są celowo NIEOBECNE na tej liście i nie da się ich osiągnąć.
];

async function cleanupOldData() {
  const now = new Date();
  for (const { table, days } of RETENTION) {
    const cutoff = subDays(now, days);
    let deleted = 0, batch = 0;
    do {
      batch = await db[table].deleteMany({ created_at: { $lt: cutoff } }, { limit: 10_000 });
      deleted += batch;
    } while (batch > 0);
    console.log(`retention: deleted ${deleted} rows from ${table} older than ${days}d`);
    // wyemituj metrykę; alertuj, jeśli `deleted` dziko odbiega od historycznego zakresu
  }
}

Jak to współgra z żądaniami usunięcia z RODO?

Retencja wyznacza maksimum, jak długo domyślnie trzymasz dane. Żądanie prawa do bycia zapomnianym może wymagać usunięcia wcześniej. Wyjątkiem są Twoje rejestry podstawy prawnej: zgody i wpisy supresji zwykle trzymasz nawet po żądaniu usunięcia, bo dowodzą, że miałeś pozwolenie, i chronią użytkownika przed ponownym mailowaniem. Udokumentuj ten wyjątek w swojej polityce prywatności. Szczegół prawny jest w Zgodności prawnej.

Jest tu subtelność, którą warto dobrze rozegrać: wpis supresji sam jest danymi osobowymi (adresem e-mail), więc „trzymaj go na zawsze” pozornie kłóci się z usunięciem. Standardowe rozwiązanie to przechowywanie jednokierunkowego hasza adresu na liście supresji zamiast tekstu jawnego, gdy lokalne prawo i Twoja postawa wobec ryzyka tego wymagają. Sprawdzasz sha256(normalizeEmail(to)) względem zbioru supresji, co wciąż bramkuje każdą wysyłkę, ale wiersz nie zawiera już bezpośrednio czytelnych danych osobowych, co zaspokaja usunięcie identyfikowalnych danych użytkownika, zachowując ochronę, która powstrzymuje Cię od ponownego mailowania do niego. Jeśli wybierzesz tę drogę, haszuj spójnie (ta sama normalizacja, ten sam algorytm) zarówno przy zapisie, jak i odczycie, i bądź świadom, że haszowanie czyni listę nieprzejrzystą dla wsparcia i debugowania, więc rozważ ten kompromis.

Które metryki mówią mi, że lista się psuje?

Obserwuj trzy metryki: wskaźnik odbić, wskaźnik skarg i wzrost listy supresji. To Twój system wczesnego ostrzegania.

Kolumna cel to miejsce, w którym znajduje się zdrowy program. Kolumna próg alertu to miejsce, w którym powinieneś dostać powiadomienie.

• Wskaźnik odbić (<2%, alert >2%). Rosnący wskaźnik odbić oznacza, że złe adresy wchodzą na Twoją listę: zepsuty krok walidacji, nieaktualny import lub kupiona lista. Złap to wcześnie, zanim naruszy reputację (zobacz surowsze cele dostarczalności w Dostarczalności).
• Wskaźnik skarg (<0,05%, alert >0,05%). Nawet maleńkie wskaźniki skarg są niebezpieczne. Przekroczenie 0,05% powinno uruchomić natychmiastowe śledztwo, co i do kogo wysłałeś.
• Wzrost listy supresji (stabilny, alert na nagły skok). Stały, powolny wzrost jest normalny. Liczy się nagły skok. Zwykle oznacza, że pojedyncza wysyłka trafiła do złego segmentu, generując naraz serię odbić lub skarg. Pole source_email_id ze schematu supresji pozwala prześledzić skok do jego przyczyny.

Kalibrowanie wskaźnika skarg względem reguły 0,3%

Wewnętrzny próg alertu powyżej (0,05%) jest celowo surowszy niż pułap 0,3%, który egzekwują Gmail/Yahoo/Microsoft, i ta różnica jest zamierzona. Dwie rzeczy, które trzeba mieć poukładane:

• Reguła 0,3% jest mierzona przez dostawcę skrzynki, na jego wolumenie, tak jak on ją liczy. Google Postmaster Tools raportuje Twój wskaźnik skarg Gmaila wyłącznie względem odbiorców Gmaila. Twój własny wewnętrzny wskaźnik skarg (skargi / dostarczone, w poprzek wszystkich dostawców) to inna, mieszana liczba. Obserwuj obie, ale traktuj liczbę per-dostawca z Postmaster jako tę, która decyduje o umieszczeniu w Gmailu.
• 0,3% to klif „nie przekraczać”, a nie cel. Wytyczne samego Google'a mówią, by pozostawać poniżej 0,1%. Zanim dobijesz do 0,3%, Twoja dostarczalność jest już zdegradowana. Dlatego wewnętrzne powiadomienie odpala przy 0,05%, kupuje Ci czas na reakcję, zanim mierzona przez dostawcę liczba wespnie się w kłopoty.

Licz wskaźnik skarg na kroczącym oknie dostarczonych wiadomości, a nie na sumach od początku istnienia, by niedawna zła kampania faktycznie ruszyła tę liczbę. Wskaźnik skarg liczony na wolumenie od zawsze zamaskuje bieżący problem za latami dobrej historii.

Przykład w praktyce: śledzenie skoku

Załóżmy, że Twoja lista supresji rośnie o swoje zwykłe ~50 wierszy w poniedziałek, a potem o 4200 wierszy we wtorek. Procedura:

1. Pogrupuj nowe wiersze z wtorku po reason. Powiedzmy, że 3900 to hard_bounce, a 300 to complaint. Dominacja hard bounce wskazuje na problem z jakością adresów (zły import lub lista), a nie problem z treścią.
2. Pogrupuj po source_email_id. Jeśli 3800 odbić dzieli jeden source_email_id, znalazłeś winną wysyłkę.
3. Zbadaj segment tej wysyłki. Odkrywasz, że celowała w listę zaimportowaną w zeszłym tygodniu ze starego eksportu CRM, której nigdy nie zwalidowano.
4. Napraw: zatrzymaj wszelkie dalsze wysyłki do tego segmentu, przepuść pozostałe adresy przez walidację przy zapisie (MX + składnia) przed ponownym mailowaniem i sprawdź, jak niezwalidowany import dotarł na produkcję.

Całe śledztwo opiera się na tym, że zapisano reason i source_email_id w czasie supresji. Bez nich skok to zagadka, której nie da się rozwiązać.

Co robić, gdy metryka przekroczy próg alertu?

• Skok odbić: zatrzymaj dotkniętą wysyłkę, znajdź źródłową listę lub import i uruchom walidację adresów przed wznowieniem (zobacz Pozyskiwanie adresów).
• Skok skarg: natychmiast wstrzymaj kampanię, przejrzyj treść i segment oraz potwierdź, że wszyscy na nim faktycznie wyrazili zgodę (opt-in).
• Skok supresji: użyj source_email_id, by znaleźć wywołującą wysyłkę, a potem zbadaj, jak ten segment został zbudowany.

Czy listy transakcyjne i marketingowe powinny być osobne?

Tak. Trzymaj je jako osobne listy, bo rządzą się różnymi zasadami.

• Transakcyjne: można wysyłać do każdego z relacją konta.
• Marketingowe: tylko subskrybenci z opt-in.

Poczta transakcyjna (resety haseł, potwierdzenia, alerty bezpieczeństwa) jest wysyłana z powodu istniejącej relacji konta i konkretnej akcji wykonanej przez użytkownika. Zgoda marketingowa nie jest wymagana. Poczta marketingowa (newslettery, promocje) może trafiać tylko do osób, które wyraźnie wyraziły zgodę (opt-in).

Rozdziel strumienie na poziomie infrastruktury, nie tylko listy

Rozdzielenie na poziomie listy powyżej to polityka. Ruchem chroniącym reputację jest rozdzielenie strumieni fizycznie, by problem w jednym nie mógł skazić drugiego:

• Osobne domeny lub subdomeny wysyłkowe. Wysyłaj transakcyjne z jednej tożsamości (np. notify.example.com), a marketingowe z drugiej (np. news.example.com), każda z własnym SPF/DKIM/DMARC. Dostawcy skrzynek budują reputację w dużej mierze per-domena. Jeśli kampania marketingowa zatopi news.example.com, Twoje resety haseł na notify.example.com dalej będą lądować. To pojedynczo najważniejsza strukturalna ochrona dla dostarczalności transakcyjnej.
• Osobne pule IP. Jeśli Twój wolumen uzasadnia dedykowane IP, trzymaj transakcyjne i marketingowe na różnych pulach z tego samego powodu, reputacja IP nie przenika.
• Często osobni dostawcy w całości. Wiele zespołów prowadzi transakcyjne na jednym ESP zoptymalizowanym pod pojedyncze wysyłki o niskim opóźnieniu i wysokiej niezawodności, a marketingowe na drugim zbudowanym pod kampanie i segmentację. To powszechna i sensowna architektura, i dokładnie ten scenariusz, w którym posiadanie własnej listy supresji (zamiast polegania na liście każdego dostawcy) staje się niezbędne, by odbicie w jednym strumieniu supresowało w drugim.

Rozumowanie stojące za rozdzieleniem domen/IP oraz rekordy DNS, które je wspierają, są w Dostarczalności i Niezawodności wysyłki; sednem dla zarządzania listą jest to, że „osobne listy” powinny oznaczać „osobne reputacje”.

Czy supresja dotyczy zarówno transakcyjnych, jak i marketingowych?

Hard bounce i skargi poddają supresji we wszystkich typach maili. Hard bounce oznacza, że adres jest fizycznie niedostarczalny, a to prawda niezależnie od tego, czy wiadomość to potwierdzenie, czy newsletter, więc supresuje wszędzie. Skarga oznacza, że odbiorca oznaczył Cię jako spamera u swojego dostawcy. Dalsze mailowanie do niego czegokolwiek pogłębia szkodę reputacyjną, więc skargi również supresują w obu strumieniach.

To dokładnie to, co koduje świadomy powodu canSendTo(email, stream) powyżej: hard_bounce i complaint są w zbiorze HARD_BLOCK_REASONS, więc zwierają obwód zanim strumień zostanie w ogóle skonsultowany. unsubscribe i manual są sprawdzane tylko względem strumienia marketingowego.

Czy wypisanie się zatrzymuje też maile transakcyjne?

Nie. Wypis dotyczy tylko marketingu. Użytkownik, który wypisuje się z marketingu, wciąż może otrzymywać maile transakcyjne (resety haseł, potwierdzenia zamówień).

Wypisanie to wycofanie zgody marketingowej, a nie stwierdzenie, że adres jest zepsuty, ani że użytkownik zgłasza nadużycie. Ktoś, kto wypisuje się z Twojego newslettera, wciąż potrzebuje, by działał jego mail resetujący hasło i potwierdzenia zamówień, bo są one niezbędne dla usługi, z której korzysta. Więc wypis usuwa go tylko z list marketingowych; poczta transakcyjna trwa nadal. W przeciwieństwie do skargi, która supresuje wszystko. Niuans prawny stojący za tym rozróżnieniem omówiono w Zgodności prawnej.

Częstym trybem awarii jest tu „wiadomość marketingowa przebrana za transakcyjną”, wstawienie promocji do potwierdzenia zamówienia albo cross-sell do resetu hasła. Łamie to rozdzielenie w obu kierunkach: może ściągnąć skargę na Twój strumień transakcyjny (użytkownik zgłasza potwierdzenie jako spam z powodu promocji) i wysyła treść marketingową do osób, które nigdy nie wyraziły zgody lub się wypisały. Trzymaj szablony transakcyjne ściśle transakcyjnymi. Reguły klasyfikacji, co liczy się jako co, są w Typach maili i katalogu w Katalogu transakcyjnych; wzorce implementacyjne są w Mailach transakcyjnych.

Jak wygląda kompletna lista kontrolna zarządzania listą?

• Sprawdzenie supresji opakowuje każdą wysyłkę; żaden kod nie wywołuje dostawcy bezpośrednio
• Bramka w czasie wysyłki jest świadoma powodu i świadoma strumienia (canSendTo(email, stream))
• Twoja własna lista supresji jest źródłem prawdy, a nie lista dostawcy
• Hard bounce i skargi supresują w czasie rzeczywistym i nigdy nie są automatycznie cofane
• Odbicia blokujące (5.7.x) są traktowane jako sygnały reputacji/uwierzytelniania, a nie supresje
• Soft bounce supresują po 3 niepowodzeniach; wypisy przetwarzane natychmiast
• Wypis jednym kliknięciem zgodny z RFC 8058 (List-Unsubscribe + List-Unsubscribe-Post) jest podpięty do supresji dla marketingu
• Adresy są normalizowane (małe litery, przycięte) zarówno przy zapisie, jak i odczycie; wyszukiwanie supresji jest wsparte indeksem
• Supresja jest sprawdzana ponownie w czasie nadania, a nie tylko w czasie kolejkowania
• Nieaktywni subskrybenci przechodzą przez reaktywację, z stałą polityką wygaszania za nią
• Zaangażowanie oceniane jest po kliknięciach (i aktywności w produkcie), a nie po samych otwarciach, po Apple MPP
• Walidacja przy zapisie (składnia + MX, potwierdzony opt-in) trzyma złe adresy z dala
• Zadanie retencji uruchamia się codziennie, w partiach i obserwowalnie; supresje i rejestry zgód wyłączone przez listę dozwolonych
• Metryki odbić, skarg (względem pułapu 0,3% dla masowych nadawców) i wzrostu supresji monitorowane z alertami
• Google Postmaster Tools oraz kanały skarg dostawcy/FBL są podłączone dla każdej domeny wysyłkowej
• Transakcyjne i marketingowe trzymane jako osobne listy oraz osobne domeny/IP wysyłkowe z poprawnymi zasadami międzystrumieniowymi

Co przeczytać dalej?

• Webhooki i zdarzenia: odbieranie powiadomień o odbiciach i skargach
• Dostarczalność: jak higiena list wpływa na reputację nadawcy
• Zgodność prawna: wymogi prawne dotyczące retencji danych
• Pozyskiwanie adresów: walidacja adresów, zanim wejdą na listę
• Maile marketingowe: wypis jednym kliknięciem i higiena kampanii
• Typy maili: rozróżnienie transakcyjne kontra marketingowe w całości
• Spis treści: powrót do przeglądu poradnika