Zgodność prawna

Ten rozdział odpowiada na pytania prawne, na które natykają się deweloperzy i founderzy wysyłający e‑maile: do kogo wolno Ci wysyłać, co musisz odbiorcom powiedzieć, jak musisz umożliwić im rezygnację i które prawo kiedy obowiązuje. Omawia najważniejsze reżimy (CAN‑SPAM, RODO, CASL, ePrivacy i inne), nakładane przez nie zasady wypisu i rejestrowania zgód, wymogi dotyczące identyfikacji i adresu fizycznego oraz techniczne nagłówki, których dostawcy skrzynek wymagają dziś od nadawców masowych.

⚠️ To NIE jest porada prawna. Ten rozdział to praktyczne, inżynierskie streszczenie, a nie zastępstwo profesjonalnej porady. Prawo się zmienia, kary są aktualizowane, a to, jak dana reguła odnosi się do Twojej działalności, zależy od faktów, których ten dokument nie zna. Przed oparciem się na czymkolwiek tutaj skonsultuj się z wykwalifikowanym prawnikiem w swojej konkretnej sytuacji. Kwoty, terminy i kary poniżej pochodzą ze źródeł publicznych aktualnych na początek 2026 roku; nie traktuj ich jako gwarantowanej, aktualnej porady prawnej.

Szybkie odpowiedzi (pytania, na które odpowiada ten rozdział):

• Które prawa dotyczą mojego programu e‑mail?
• Czego wymaga CAN‑SPAM w USA?
• Czego wymaga RODO w UE?
• Czego wymaga CASL w Kanadzie?
• A co z Australią, Wielką Brytanią, Brazylią i innymi krajami?
• Jak szybko muszę przetwarzać wypisy i jak długo musi działać link?
• Czy naprawdę potrzebuję nagłówka List-Unsubscribe?
• Jak poprawnie wdrożyć jednoklikowy wypis RFC 8058?
• Czym są wymogi wobec nadawców masowych z lutego 2024 (i maja 2025)?
• Czy centrum preferencji może zastąpić jednoklikowy wypis?
• Jakie rejestry zgód muszę przechowywać?
• Jak długo mogę przechowywać dane subskrybentów?
• Co musi zawierać moja polityka prywatności?
• Jak zachować zgodność przy wysyłce międzynarodowej?
• Jak obsługiwać żądania osób, których dane dotyczą (dostęp, usunięcie, przenoszenie)?

Jak nakładają się na siebie zgodność, dostarczalność i uwierzytelnianie

Zanim przejdziemy do prawa, jedna uwaga strukturalna: zgodność e‑mailowa jest dziś egzekwowana na dwóch warstwach jednocześnie, a inżynierowie nieustannie je ze sobą mylą.

1. Warstwa ustawowa, to, czego wymagają rządy (CAN‑SPAM, RODO, CASL, ePrivacy/PECR, Spam Act, LGPD…). Naruszenia są egzekwowane przez regulatorów grzywnami i pozwami. Wolno działająca, ograniczona jurysdykcją, oparta na skargach.
2. Warstwa dostawcy skrzynki, to, czego wymagają Gmail, Yahoo i Microsoft, żeby w ogóle przyjąć Twoją pocztę. To nie są prawa. To prywatne polityki akceptacji, ale dla realnego programu wysyłki gryzą znacznie mocniej i znacznie szybciej niż jakikolwiek regulator: niezgodna wysyłka masowa jest odrzucana lub wrzucana do spamu w ciągu minut, a nie sądzona przez lata.

Obie warstwy się rymują, ale nie są identyczne. Jednoklikowy nagłówek List-Unsubscribe to wymóg dostawcy skrzynki (i zabezpieczenie dostarczalności), a nie ustawowy, jednak jego wdrożenie przy okazji spełnia też zasadę „ułatw odejście”, która jest ustawowa pod RODO i CASL. SPF/DKIM/DMARC to czyste wymogi dostawcy skrzynki bez bezpośredniego mandatu ustawowego, ale ich niespełnienie powoduje odrzucenie poczty na długo przed jakimkolwiek pytaniem o zgodność.

Model mentalny, który pozwala je odróżniać:

Ten rozdział omawia obie warstwy. Mechanika uwierzytelniania (same rekordy DNS, podpisywanie, alignment) znajduje się w Dostarczalność; tutaj omawiamy, które z nich są dziś obowiązkowe i dlaczego, oraz nagłówki leżące na pograniczu obu warstw.

Które prawa dotyczą mojego programu e‑mail?

Prawdopodobnie kilka naraz. E‑mail bez trudu przekracza granice, więc pojedyncza kampania może jednocześnie podlegać przepisom USA, UE, Kanady i innych krajów. Obowiązujące prawo zwykle idzie za lokalizacją odbiorcy, a nie Twoją, więc jeśli Twoja lista obejmuje wiele krajów, podlegasz najsurowszej obowiązującej regule w każdym punkcie. RODO wprost mówi o tym eksterytorialnym zasięgu (art. 3): stosuje się do każdej organizacji, gdziekolwiek się znajduje, która oferuje towary lub usługi osobom w UE, niezależnie od tego, gdzie firma jest zarejestrowana lub hostowana.

Trzy, z którymi zetkniesz się najczęściej, w skrócie:

Kilka rzeczy, które warto od razu zauważyć:

• Modele zgody różnią się fundamentalnie. CAN‑SPAM to reżim opt‑out (możesz wysyłać, dopóki ktoś nie każe przestać, z zastrzeżeniami), podczas gdy RODO i CASL to reżimy opt‑in (potrzebujesz zgody zanim wyślesz). W razie wątpliwości stosuj surowszy model opt‑in.
• Kary są dotkliwe. Grzywny RODO skalują się z przychodem firmy (większa z dwóch wartości: 20 mln EUR lub 4% globalnego rocznego przychodu), więc dla dużych firm mogą być zagrożeniem egzystencjalnym. Kary CAN‑SPAM naliczane są za pojedynczy mail, więc jedna zła kampania mnoży się błyskawicznie. (Maksimum za naruszenie w CAN‑SPAM jest okresowo korygowane o inflację przez FTC; wynosiło 53 088 USD według korekty FTC z 2025 roku, w górę od często cytowanego „43 792 USD” i starszego „16 000 USD”.)
• RODO i ePrivacy to dwa prawa, nie jedno. RODO reguluje dane osobowe; dyrektywa ePrivacy (transponowana krajowo, np. PECR w Wielkiej Brytanii) reguluje komunikację elektroniczną i zgodę na marketing w szczególności. Dla e‑mail marketingu w UE/UK musisz spełnić oba, to ePrivacy czyni uprzedni opt‑in obowiązkowym dla maili marketingowych; RODO wyznacza standard tego, jak wygląda ważna zgoda i jej rejestry.

Praktyczny wniosek: jeśli zbudujesz jeden program spełniający zgodę na poziomie RODO plus trwałość wypisu na poziomie CASL plus reguły dostawców skrzynek z lutego 2024, jesteś zgodny niemal wszędzie. Zob. „Jak zachować zgodność przy wysyłce międzynarodowej?” poniżej.

Tabela decyzyjna: czy potrzebuję zgody przed tą wysyłką?

* „Soft opt‑in” z ePrivacy pozwala wysyłać do istniejących klientów informacje o podobnych produktach bez uprzedniego opt‑in, pod warunkiem że dałeś im jasną możliwość odmowy przy zbieraniu danych i w każdej wiadomości. Nie obejmuje zimnych prospektów, a kilka państw członkowskich UE interpretuje go wąsko. Traktuj go jako rezerwę, a nie strategię.

O granicy między transakcyjnym a marketingiem, najważniejszej klasyfikacji w tym rozdziale, zob. Typy maili oraz Katalog transakcyjnych.

Czego wymaga CAN‑SPAM w USA?

CAN‑SPAM (Controlling the Assault of Non‑Solicited Pornography And Marketing Act z 2003 roku, egzekwowany przez FTC) to amerykańska ustawa federalna regulująca pocztę komercyjną. To reżim opt‑out: nie potrzebujesz uprzedniej zgody na wysyłkę, ale musisz spełnić ścisłe wymogi uczciwości i wypisu oraz przestać, gdy ktoś o to poprosi.

Wymogi, z których każdy jest twardą bramką przy wysyłce komercyjnej:

• Dokładne informacje w nagłówkach (From, To, Reply‑To oraz domena źródłowa): bez podszywania się, bez ukrywania nadawcy, bez fałszowania trasy.
• Niewprowadzające w błąd tematy: temat musi odzwierciedlać rzeczywistą treść wiadomości.
• Oznaczenie wiadomości jako reklamy tam, gdzie ma to zastosowanie: jasne i widoczne ujawnienie, że wiadomość jest reklamą (prawo dopuszcza elastyczność co do sposobu, ale musi to być oczywiste).
• Fizyczny adres pocztowy w każdym mailu: ważny adres pocztowy. Może to być adres ulicy, zarejestrowana skrytka pocztowa lub zarejestrowana agencja odbioru poczty komercyjnej (CMRA) prowadzona zgodnie z zasadami USPS. Fałszywy lub nieodbiorowy adres nie spełnia wymogu.
• Jasny mechanizm opt‑out: widoczny, działający sposób wypisu w każdej wiadomości komercyjnej.
• Honorowanie opt‑out w ciągu 10 dni roboczych, a metoda wypisu musi pozostać sprawna przez co najmniej 30 dni po wysyłce.
• Monitoruj to, co inni robią w Twoim imieniu. Pozostajesz odpowiedzialny, nawet jeśli pocztę wysyła wykonawca, partner afiliacyjny lub agencja. Nie da się oddelegować odpowiedzialności.

Czy maile transakcyjne wymagają zgody pod CAN‑SPAM? Nie. Wiadomości transakcyjne lub relacyjne można wysyłać bez opt‑in. Ale CAN‑SPAM opiera się na teście „głównego celu” (primary purpose) i właśnie tutaj inżynierowie wpadają:

• Jeśli głównym celem wiadomości jest treść transakcyjna lub relacyjna, pełny zestaw reguł komercyjnych nie ma zastosowania (choć reguła zakazu fałszowania nagłówków obowiązuje zawsze).
• Jeśli głównym celem jest treść komercyjna, to jest to wiadomość komercyjna, niezależnie od tego, jak ją oznaczysz.
• Dla wiadomości mieszanej FTC patrzy na temat oraz na to, jaka treść pojawia się jako pierwsza/najbardziej widoczna. Paragon z drobnym cross‑sellem na dole nadal jest transakcyjny; „paragon”, którego temat i górna połowa pchają sprzedaż, jest komercyjny i wymaga adresu + opt‑out.

Bezpieczna reguła inżynierska: trzymaj treści promocyjne całkowicie poza szablonami transakcyjnymi albo kieruj każdą wiadomość ze znaczącą treścią promocyjną przez ścieżkę marketingową z pełnymi nagłówkami zgodności. Zob. Maile transakcyjne o utrzymywaniu tych szablonów w czystości.

Kara: do ~53 088 USD za jeden mail naruszający przepisy (kwota FTC skorygowana o inflację). Ponieważ kara liczona jest za wiadomość, koszt niezgodnej wysyłki masowej rośnie wraz z wielkością listy. Traktuj powyższe wymogi jako twardą bramkę przy każdej wysyłce komercyjnej.

Częste błędy:

• Pomijanie fizycznego adresu w automatycznych mailach marketingowych (lub umieszczanie go tylko na stronie, nie w mailu).
• Używanie nazwy lub adresu From „no‑reply”, które zniekształcają tożsamość nadawcy.
• Dopuszczenie do zepsucia linków wypisu po zmianie szablonu lub migracji domeny, martwy link to naruszenie, nawet jeśli wczoraj działał.
• Pobieranie opłaty, wymaganie logowania lub wymaganie czegoś więcej niż adres e‑mail do wypisu, wszystko zabronione.
• Wysyłanie przez pełne 10 dni roboczych jako zasada polityki. Dziesięć dni to pułap, nie cel; dostawcy skrzynek i inne reżimy oczekują znacznie szybszego działania.

Czego wymaga RODO w UE?

RODO (unijne ogólne rozporządzenie o ochronie danych) to kompleksowe unijne rozporządzenie o ochronie danych. Dla e‑maila jest to reżim opt‑in oparty na zasadzie, że dane osobowe (w tym adres e‑mail) należą do osoby fizycznej, która musi czynnie wyrazić zgodę na ich wykorzystanie. Dla maili marketingowych w szczególności zasada uprzedniej zgody pochodzi w istocie z dyrektywy ePrivacy (krajowe transpozycje, np. brytyjski PECR); RODO definiuje następnie, jak wygląda ważna zgoda i właściwe rejestry.

Sześć podstaw prawnych (art. 6). Dane osobowe możesz przetwarzać tylko, jeśli masz podstawę prawną. Dla e‑maila znaczenie mają trzy:

• Zgoda, podstawa dla maili marketingowych. Musi być jasnym, potwierdzającym działaniem.
• Umowa, podstawa dla maili transakcyjnych związanych z realizacją zamówienia lub usługi (paragony, wysyłka, powiadomienia o koncie).
• Uzasadniony interes (legitimate interest), możliwa podstawa dla niektórych wiadomości operacyjnych/relacyjnych, ale wymaga udokumentowanego testu równowagi i nie jest bezpieczną podstawą dla zimnego marketingu pod ePrivacy.

Jak wygląda ważna zgoda (art. 4 pkt 11, art. 7):

• Wyraźny opt‑in, nie pola zaznaczone z góry: milczenie, bierność ani wstępnie zaznaczone pole nigdy nie są zgodą (potwierdzone wyrokiem TSUE Planet49).
• Dobrowolna, konkretna, świadoma i jednoznaczna: użytkownik dokładnie rozumie, na co się zgodził, bez przymusu i bez wiązania zgody marketingowej z niepowiązanymi warunkami (nie możesz uzależnić rejestracji od akceptacji marketingu).
• Granularna: osobne zgody dla osobnych celów (np. maile produktowe vs. oferty partnerskie).
• Tak samo łatwa do wycofania jak do udzielenia (art. 7 ust. 3): odejście nie może być trudniejsze niż dołączenie.
• Możliwa do wykazania (art. 5 ust. 2, zasada rozliczalności): musisz potrafić udowodnić zgodę. Brak dowodu = brak zgody w oczach organu nadzorczego.

Prawa osób, których dane dotyczą, które musisz umieć honorować: dostęp (art. 15), sprostowanie (16), usunięcie / „prawo do bycia zapomnianym” (17), ograniczenie (18), przenoszenie danych (20) oraz sprzeciw wobec marketingu bezpośredniego (21, który jest bezwzględny, nie możesz odmówić sprzeciwowi marketingowemu). Zob. „Jak obsługiwać żądania osób, których dane dotyczą?” poniżej.

Przetwarzaj wypis / sprzeciw natychmiast: bez okresu karencji; działaj „bez zbędnej zwłoki”.

Czy maile transakcyjne wymagają zgody marketingowej pod RODO? Nie. Opierają się na podstawie prawnej umowy (nie zrealizujesz zamówienia bez jego potwierdzenia) lub, dla niektórych wiadomości operacyjnych, uzasadnionego interesu. Nie potrzebujesz osobnej zgody marketingowej, by wysłać potwierdzenie zamówienia, reset hasła czy alert bezpieczeństwa. Nadal musisz przestrzegać zasad minimalizacji danych i bezpieczeństwa.

Kara: do 20 mln EUR lub 4% globalnego rocznego przychodu, zależnie od tego, która kwota jest wyższa (wyższy próg, dla naruszeń zgody/podstawy prawnej). Ponieważ skaluje się z przychodem, RODO to reżim, który najczęściej dyktuje strategię „zgodności globalnej”. Wielka Brytania stosuje równoważne reguły poprzez UK GDPR + PECR po brexicie (zob. niżej).

Częste błędy:

• Traktowanie wstępnie zaznaczonego pola lub „zapisując się, zgadzasz się na otrzymywanie marketingu” jako zgody.
• Wiązanie zgody marketingowej z akceptacją regulaminu (zgoda musi być dobrowolna i odseparowana).
• Przechowywanie zgody jako pojedynczej flagi logicznej bez znacznika czasu, źródła i zakresu, co czyni ją niemożliwą do udowodnienia, a zatem bezwartościową.
• Traktowanie „uzasadnionego interesu” jako obejścia zgody przy zimnym kontakcie. ePrivacy wymaga uprzedniej zgody na maile marketingowe niezależnie od podstaw prawnych RODO.
• Zapominanie, że adres IP lub identyfikator urządzenia uchwycony przy rejestracji sam jest danymi osobowymi podlegającymi tym samym regułom.

Czego wymaga CASL w Kanadzie?

CASL (kanadyjska ustawa antyspamowa, obowiązująca od 2014 roku) należy do najsurowszych reżimów na świecie. To reżim opt‑in, a jego cechą definiującą jest ostre rozróżnienie dwóch rodzajów zgody, jednej trwałej, drugiej z zegarem.

Dwa rodzaje zgody:

• Zgoda wyraźna (express consent): jawny, potwierdzający opt‑in. Jest idealna, bo nie wygasa, dopóki nie zostanie wycofana. Musisz przechowywać dowód kiedy, jak i na co wyrażono zgodę.

• Zgoda dorozumiana (implied consent): powstaje automatycznie z określonych relacji, ale jest ograniczona w czasie:

  • Istniejąca relacja biznesowa (np. zakup, umowa lub płatna subskrypcja) daje zgodę dorozumianą na 2 lata od danego zdarzenia.
  • Zapytanie (ktoś zapytał o Twój produkt/usługę) daje zgodę dorozumianą na 6 miesięcy od zapytania.
  • Widocznie opublikowany firmowy adres e‑mail (bez oświadczenia odmawiającego CEM) również może implikować zgodę na wiadomości istotne dla roli tej osoby.

  Gdy okno zgody dorozumianej upłynie, nie możesz już wysyłać do tego kontaktu bez uprzedniego uzyskania zgody wyraźnej.

Wymogi operacyjne (każda komercyjna wiadomość elektroniczna, czyli CEM, musi zawierać):

• Jasną identyfikację nadawcy, kim jesteś i jak się z Tobą skontaktować, ważną przez 60 dni po wysyłce.
• Działający mechanizm wypisu, również sprawny przez co najmniej 60 dni po wysyłce.
• Przetwarzanie wypisu nie później niż w 10 dni roboczych (szybciej jest oczekiwane i bezpieczniejsze).
• Przechowywanie rejestrów zgód jako dowodu; powszechnym standardem operacyjnym są 3 lata po wygaśnięciu lub wycofaniu zgody, by przetrwać okno postępowania.

CASL sięga też poza e‑mail do SMS‑ów i innych wiadomości elektronicznych, a także zawiera przepisy przeciwko instalowaniu oprogramowania i zmienianiu danych transmisji bez zgody, to wykracza poza zakres tego rozdziału, ale warto wiedzieć, że ustawa jest szeroka.

Kara: do 1 mln CAD dla osoby fizycznej i 10 mln CAD dla organizacji za naruszenie. Dyrektorzy i członkowie zarządu mogą zostać pociągnięci do osobistej odpowiedzialności. Połączenie ograniczonej w czasie zgody dorozumianej z długim obowiązkiem przechowywania rejestrów sprawia, że śledzenie zgód (ze znacznikami czasu, źródłem i rodzajem zgody) jest niezbędne dla każdego programu wysyłającego do Kanady.

Częste błędy:

• Dalsze wysyłanie do kontaktu po upływie jego 2‑letniego (lub 6‑miesięcznego) okna zgody dorozumianej, bo nic w systemie nie śledziło zegara.
• Brak zapisu, która relacja lub które zapytanie utworzyło zgodę dorozumianą, przez co nie udowodnisz, kiedy zegar ruszył, ani że w ogóle ruszył.
• Traktowanie pojedynczego zakupu jako trwałego pozwolenia. Zgoda dorozumiana z transakcji jest rodzaju 2‑letniego, nie wyraźna.
• Wysyłanie na adresy ról (info@, sales@) przy założeniu, że są zwolnione, są objęte tylko, jeśli są widocznie opublikowane, a wiadomość jest istotna dla roli.

A co z Australią, Wielką Brytanią, Brazylią i innymi krajami?

Poza wielką trójką własne reguły nakładają też inne jurysdykcje. Wspólnym mianownikiem jest zgoda plus działający wypis plus dokładna identyfikacja nadawcy.

Uwagi:

• Australia ma najkrótsze okno wypisu w zestawie, 5 dni roboczych, więc proces dostrojony wyłącznie do 10‑dniowego pułapu CAN‑SPAM mógłby tam okazać się niewystarczający. Australia uznaje też domniemaną zgodę z istniejącej relacji, w duchu podobną do zgody dorozumianej z CASL.
• Wielka Brytania po brexicie zachowuje ochronę równoważną RODO poprzez UK GDPR oraz PECR (Privacy and Electronic Communications Regulations); regulatorem jest ICO. PECR to brytyjska transpozycja dyrektywy ePrivacy i to ona nakazuje uprzedni opt‑in dla maili marketingowych.
• Brazylijska LGPD ściśle naśladuje RODO, w tym wyraźną zgodę na marketing i pełny zestaw praw osób, których dane dotyczą; ANPD może nakładać grzywny do 2% przychodu w Brazylii (z limitem na naruszenie).
• Kalifornijskie CCPA/CPRA nie reguluje wysyłki e‑maili tak jak CAN‑SPAM, ale daje mieszkańcom Kalifornii prawa do danych osobowych (w tym adresów e‑mail) i może wymagać linku „Do Not Sell or Share” oraz honorowania sygnałów preferencji opt‑out. Kilka innych stanów USA (Wirginia, Kolorado, Connecticut, Teksas i inne) uchwaliło porównywalne prawa.

Ta tabela nie jest wyczerpująca. Wiele innych krajów (w Azji, na Bliskim Wschodzie i w Ameryce Łacińskiej, np. japońska APPI, singapurska PDPA, indyjska ustawa DPDP) ma własne reżimy. Wchodząc na nowy rynek, zweryfikuj lokalne przepisy z prawnikiem.

Jak szybko muszę przetwarzać wypisy i jak długo musi działać link?

To zależy od reżimu, ale bezpieczny domyślny wybór inżynierski usuwa zgadywanie. Każdy reżim wymaga działającego wypisu; reguły dotyczące terminów i trwałości się różnią. Ta tabela zbiera kluczowe różnice:

Bezpieczny domyślny wybór inżynierski to przetwarzanie wypisów natychmiast oraz utrzymywanie ważności linków do wypisu przez co najmniej 60 dni. Spełnienie obu warunków zaspokaja najsurowszą kolumnę w każdym wierszu, łącznie z 5‑dniowym oknem Australii i 48‑godzinnym oczekiwaniem dostawców skrzynek.

Dlaczego „natychmiast” jest też opcją tańszą. Suppression powinno być synchronicznym zapisem na listę suppression, którą ścieżka wysyłki sprawdza przed każdą wysyłką, a nie zadaniem wsadowym uruchamianym co noc. Koszt pomyłki jest asymetryczny: wysłanie do kogoś po jego wypisie to zarówno naruszenie zgodności, jak i niemal pewna skarga na spam, która szkodzi reputacji nadawcy. Zob. Zarządzanie listą o projekcie listy suppression i Dostarczalność o wpływie na reputację.

Uniwersalne dobre praktyki wypisu (spełniają wszystkie reżimy naraz):

• Widoczny link: łatwy do znalezienia w każdej wiadomości komercyjnej.
• Jeden klik, gdy to możliwe: minimum tarcia; nigdy wieloetapowo dla podstawowej akcji „wypisz ze wszystkiego”.
• Bez wymogu logowania: nigdy nie blokuj wypisu uwierzytelnianiem.
• Bezpłatny: bez kosztów dla odbiorcy.
• Potwierdzenie działania: pokaż użytkownikowi, że został usunięty (i najlepiej to zaloguj).
• Honoruj go globalnie, nie tylko per lista: twardy opt‑out powinien wstrzymać cały marketing, z osobnymi granularnymi kontrolami dostępnymi w centrum preferencji.

Przykład: idempotentny endpoint wypisu

Solidny wypis musi być idempotentny (dwukrotne kliknięcie lub ponowienie POST przez dostawcę nie może wywołać błędu) i musi działać zarówno dla ludzkiego GET (strona docelowa w przeglądarce), jak i maszynowego POST (jednoklikowy RFC 8058). Szkic niezależny od dostawcy:

// Trasy dla jednego URL wypisu, podpisany token w ścieżce/query.
// `verifyToken` waliduje HMAC, żeby link nie dał się sfałszować ani wyliczyć.
// `suppression` to Twój własny magazyn; `emailClient` to dowolny wrapper dostawcy.

import { verifyToken } from "./unsub-token";
import { suppression } from "./suppression";

// POST = jednoklikowy RFC 8058 (dostawca skrzynki woła to bezpośrednio, bez JS, bez UI)
export async function handleUnsubscribePost(req: Request): Promise<Response> {
  const token = new URL(req.url).searchParams.get("t");
  const claim = token && verifyToken(token);
  if (!claim) {
    // Nigdy nie ujawniaj, czy adres istnieje; po prostu potwierdź przyjęcie.
    return new Response(null, { status: 202 });
  }

  // Idempotentne: suppress() jest no-opem, jeśli już jest w suppression.
  await suppression.suppress({
    email: claim.email,
    scope: claim.listId ?? "all-marketing",
    reason: "one-click-unsubscribe",
    at: new Date().toISOString(),
  });

  // RFC 8058: odpowiedz 200/202 z pustym ciałem. Bez klikania potwierdzenia.
  return new Response(null, { status: 200 });
}

// GET = człowiek trafia tu z widocznego linku w stopce → wyrenderuj prawdziwą stronę
export async function handleUnsubscribeGet(req: Request): Promise<Response> {
  const token = new URL(req.url).searchParams.get("t");
  const claim = token && verifyToken(token);
  if (!claim) {
    return htmlPage("This unsubscribe link is invalid or expired.", 400);
  }
  await suppression.suppress({
    email: claim.email,
    scope: claim.listId ?? "all-marketing",
    reason: "footer-link-unsubscribe",
    at: new Date().toISOString(),
  });
  // Potwierdź + zaoferuj centrum preferencji jako opcję drugorzędną.
  return htmlPage("You've been unsubscribed. Manage preferences instead?", 200);
}

Pomocnik do podpisanego tokenu (generyczne crypto z Node, bez zależności od dostawcy):

import { createHmac, timingSafeEqual } from "node:crypto";

const SECRET = process.env.UNSUB_SECRET!; // 32+ losowych bajtów, nie w kodzie źródłowym

type Claim = { email: string; listId?: string };

export function signToken(claim: Claim): string {
  const payload = Buffer.from(JSON.stringify(claim)).toString("base64url");
  const sig = createHmac("sha256", SECRET).update(payload).digest("base64url");
  return `${payload}.${sig}`;
}

export function verifyToken(token: string): Claim | null {
  const [payload, sig] = token.split(".");
  if (!payload || !sig) return null;
  const expected = createHmac("sha256", SECRET).update(payload).digest("base64url");
  const a = Buffer.from(sig);
  const b = Buffer.from(expected);
  if (a.length !== b.length || !timingSafeEqual(a, b)) return null;
  try {
    return JSON.parse(Buffer.from(payload, "base64url").toString("utf8"));
  } catch {
    return null;
  }
}

Dlaczego podpisywać token. Niepodpisany link ?email= może edytować ktokolwiek, by wypisać inne osoby, a roboty/skanery i tak na niego trafią. Podpisany token czyni link niemożliwym do sfałszowania i pozwala osadzić zakres listy bez ujawniania ID z bazy danych.

Czy naprawdę potrzebuję nagłówka List-Unsubscribe?

Tak, jeśli wysyłasz masowo. Od lutego 2024 Gmail, Yahoo, a (od maja 2025) Microsoft wymagają od nadawców masowych obsługi jednoklikowego wypisu poprzez nagłówki List-Unsubscribe na poczcie marketingowej/promocyjnej. Bez nich masowe maile marketingowe mogą zostać odrzucone, ograniczone (throttling) lub przefiltrowane do spamu.

Istnieją dwa powiązane, ale odrębne nagłówki, oba zestandaryzowane:

• List-Unsubscribe (RFC 2369, 1998), lista URI wypisu (mailto: i/lub https:). Stary; wspierany od dekad.
• List-Unsubscribe-Post (RFC 8058, 2017), włącza wiadomość do jednoklikowego wypisu, gdzie dostawca skrzynki wysyła żądanie HTTP POST na Twój URI HTTPS bez ładowania Twojej strony i bez interakcji użytkownika.

Aby spełnić nowoczesny wymóg wobec nadawców masowych, potrzebujesz obu nagłówków, a nagłówek List-Unsubscribe musi zawierać URI HTTPS (nagłówek wyłącznie z mailto: nie kwalifikuje się do jednego kliknięcia).

Wymagane nagłówki (niezależne od dostawcy; ustaw je tak, jak Twoja warstwa wysyłki udostępnia nagłówki niestandardowe):

const headers = {
  // RFC 2369: podaj URI HTTPS (i opcjonalnie fallback mailto:).
  "List-Unsubscribe":
    "<https://example.com/u?t=SIGNED_TOKEN>, <mailto:unsubscribe@example.com?subject=unsubscribe>",
  // RFC 8058: ta dokładna wartość włącza wiadomość do jednego kliknięcia.
  "List-Unsubscribe-Post": "List-Unsubscribe=One-Click",
};

// Generyczny wrapper dostawcy, NIE związany z konkretnym ESP.
await emailClient.send({
  from: "news@example.com",
  to: recipient.email,
  subject: "...",
  html: body,
  headers,
});

Dlaczego to teraz ważne: te nagłówki przeszły z kategorii „miło mieć” do obowiązkowych dla nadawców masowych. Umożliwiają natywny przycisk jednoklikowego wypisu, który dostawcy skrzynek renderują na górze wiadomości, dzięki czemu mniej odbiorców sięga po „Zgłoś spam”. Nagłówek jest jednocześnie wymogiem zbliżonym do zgodności i zabezpieczeniem dostarczalności. Zob. Dostarczalność po szerszy obraz wymogów wobec nadawców.

Częste błędy:

• Umieszczenie tylko formy mailto: nagłówka (jeden klik wymaga formy HTTPS POST).
• Pominięcie List-Unsubscribe-Post w całości (dostajesz wtedy stary, wieloklikowy przepływ, a nie przycisk jednego kliknięcia, i możesz nie spełnić wymogu wobec masowych).
• Wymaganie kliknięcia potwierdzenia na stronie docelowej dla przepływu jednego kliknięcia, POST musi przetworzyć wypis bezpośrednio i zwrócić 200/202.
• Przepuszczenie maila transakcyjnego przez ścieżkę masową/marketingową, przez co dziedziczy on niechciany nagłówek wypisu (poczta transakcyjna jest zwolniona z wymogu jednego kliknięcia i nie powinna go nosić).
• Podpisywanie wiadomości w sposób, który psuje DKIM, gdy dostawca dodaje nagłówki, trzymaj List-Unsubscribe/List-Unsubscribe-Post wewnątrz zestawu nagłówków podpisanych DKIM, żeby przetrwały transmisję.

Jak poprawnie wdrożyć jednoklikowy wypis RFC 8058?

RFC 8058 definiuje precyzyjny kontrakt. Pomyl jakąkolwiek część, a albo przycisk jednego kliknięcia się nie pojawi, albo wypis po cichu zawiedzie.

Kontrakt, krok po kroku:

1. Wiadomość niesie oba nagłówki: List-Unsubscribe (z URI https:) oraz List-Unsubscribe-Post: List-Unsubscribe=One-Click.
2. Oba nagłówki muszą być objęte Twoim podpisem DKIM (RFC 6376). Jeśli nagłówek, na którym opiera się dostawca, nie jest podpisany, dostawca może nie ufać afordancji jednego kliknięcia.
3. Gdy użytkownik kliknie natywny przycisk „Wypisz” dostawcy, dostawca wysyła HTTP POST na Twój URI https: z ciałem List-Unsubscribe=One-Click i Content-Type: application/x-www-form-urlencoded. Bez cookies, bez JavaScriptu, bez przekierowania na stronę.
4. Twój endpoint nie może wymagać żadnej dalszej interakcji. Przetwarza wypis i zwraca 200 lub 202.
5. Musisz zadziałać na to w ciągu 48 godzin (oczekiwanie dostawcy skrzynki).

Budowa end‑to‑end z użyciem pomocników powyżej:

// 1) Przy wysyłce każdej wiadomości marketingowej wybij podpisany token per odbiorca.
const token = signToken({ email: recipient.email, listId: "weekly-digest" });
const unsubUrl = `https://example.com/u?t=${token}`;

const headers = {
  "List-Unsubscribe": `<${unsubUrl}>, <mailto:unsubscribe@example.com>`,
  "List-Unsubscribe-Post": "List-Unsubscribe=One-Click",
};

// 2) Endpoint /u obsługuje POST (jeden klik) i GET (link w stopce), jak pokazano
//    w przykładzie idempotentnego endpointu powyżej. Handler POST zwraca 200,
//    zapisuje do magazynu suppression i nigdy nie renderuje UI.

Weryfikacja, że naprawdę działa (niezależnie od dostawcy):

# Potwierdź, że nagłówki są obecne i poprawnie sformułowane na realnie odebranej wiadomości
# (zobacz źródło w skrzynce lub przepuść zapisany plik .eml przez grep):
grep -i '^List-Unsubscribe' message.eml

# Zasymuluj jednoklikowy POST dostawcy przeciwko własnemu endpointowi:
curl -i -X POST 'https://example.com/u?t=SIGNED_TOKEN' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data 'List-Unsubscribe=One-Click'
# Oczekuj: HTTP/1.1 200 (lub 202), puste ciało i nowy rekord suppression.

Tryby awarii i jak je diagnozować:

O zdarzeniach, które Twój endpoint i dostawca emitują przy wypisie lub skardze (i jak je przyjmować), zob. Webhooki i zdarzenia.

Czym są wymogi wobec nadawców masowych z lutego 2024 (i maja 2025)?

To warstwa dostawcy skrzynki i jest dziś najważniejszym operacyjnie zestawem reguł w rozdziale, bo jego niespełnienie powoduje odrzucenie poczty niezależnie od zgodności ustawowej.

Kto jest „nadawcą masowym”? Gmail i Microsoft definiują go jako domenę wysyłającą 5000 lub więcej wiadomości dziennie do ich użytkowników. Yahoo stosuje podobne progi oparte na wolumenie. Liczba 5000/dzień jest per dostawca i może zostać osiągnięta łącznie w subdomenach, więc ruchliwy program przekracza ją wcześniej, niż founderzy się spodziewają. Poniżej progu reguły są mocno zalecane; powyżej, egzekwowane.

Wymogi (obowiązujące od 1 lutego 2024 dla Gmail/Yahoo; od 5 maja 2025 dla Microsoft Outlook/Hotmail/Live):

1. Uwierzytelnij swoją pocztę, wszystkie trzy:
   • SPF (RFC 7208), rekord DNS TXT autoryzujący wysyłające IP.
   • DKIM (RFC 6376), podpis kryptograficzny nad wiadomością.
   • DMARC (RFC 7489), opublikowana polityka, minimum p=none, z alignment: domena w From: musi być zgodna z domeną SPF i/lub DKIM.
2. Utrzymuj zgłaszany przez użytkowników wskaźnik skarg na spam poniżej 0,3% (Google mocno zaleca pozostawanie poniżej 0,1%). Powyżej 0,3% utrzymywanego stale Twoja poczta jest ograniczana lub odrzucana i tracisz uprawnienie do złagodzenia, dopóki nie utrzymasz się poniżej 0,3% przez kilka kolejnych dni.
3. Wspieraj jednoklikowy wypis (RFC 8058) na poczcie marketingowej i przetwarzaj wypisy w ciągu 48 godzin (omówione wyżej).
4. Wysyłaj z ważnego, działającego From/Reply‑To, z prawidłowym forward i reverse DNS (PTR) na wysyłających IP, i używaj TLS do transmisji.
5. Formatuj wiadomości zgodnie ze standardem RFC 5322 i nie podszywaj się pod nagłówki From: Gmaila/Yahoo/Microsoftu.

Gotowe do skopiowania rekordy DNS (podmień przykładowe wartości):

; SPF, RFC 7208. Jeden rekord TXT, jeden "v=spf1", zakończony kwalifikatorem.
; ~all = softfail (monitorowanie), -all = hardfail (egzekwowanie), gdy nabierzesz pewności.
example.com.            IN  TXT  "v=spf1 include:_spf.your-provider.example -all"

; DKIM, RFC 6376. Dostawca daje Ci klucz publiczny; opublikuj go przy
; selektorze, który wskaże. Selektor tutaj to "s1".
s1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...IDAQAB"

; DMARC, RFC 7489. Zacznij od p=none z raportowaniem, potem zaostrz do quarantine/reject.
_dmarc.example.com.     IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

Zweryfikuj przez dig, zanim wyślesz choć jedną masową kampanię:

# SPF
dig +short TXT example.com | grep spf1

# DKIM (użyj swojego prawdziwego selektora zamiast s1)
dig +short TXT s1._domainkey.example.com

# DMARC
dig +short TXT _dmarc.example.com

# Reverse DNS (PTR) na Twoim wysyłającym IP musi rozwiązywać się do hosta w Twojej domenie
dig +short -x 203.0.113.10

Gdzie to jest egzekwowane vs. gdzie czytać o mechanice. Reguły z lutego 2024 / maja 2025 to co jest wymagane. Jak, generowanie kluczy DKIM, dobór SPF includes, czytanie zbiorczych raportów DMARC (rua), droga od p=none do p=reject, ARC (RFC 8617) dla przekazywanej poczty, MTA‑STS (RFC 8461) i TLS‑RPT (RFC 8460) dla wymuszonego szyfrowania transportu oraz BIMI dla zweryfikowanych logo, jest omówione szczegółowo w Dostarczalność. Zadaniem tego rozdziału jest tylko zaznaczyć, że uwierzytelnianie przeszło z opcjonalnego do obowiązkowego dla nadawców masowych, i dać Ci rekordy do opublikowania.

Częste błędy:

• Publikowanie dwóch rekordów SPF (na domenę dozwolony jest tylko jeden TXT v=spf1; drugi psuje SPF całkowicie).
• Przekroczenie limitu 10 odpytań DNS w SPF zbyt wieloma łańcuchami include:, powodujące permerror.
• Polityka DMARC, która przechodzi SPF/DKIM, ale nie przechodzi alignment, bo domena From: różni się od domeny uwierzytelnionej (alignment to część, którą ludzie pomijają).
• Przeskok od razu do p=reject bez wcześniejszego czytania raportów zbiorczych, a potem ciche zatapianie własnej legalnej poczty.
• Założenie, że poniżej 5000/dzień oznacza „zwolniony na zawsze”, dostawcy stosują wiele z tych reguł wobec wszystkich, a Twój wolumen rośnie.

Czy centrum preferencji może zastąpić jednoklikowy wypis?

Nie. Większość przepisów, i reguły dostawców skrzynek, wymaga prawdziwego, jednoczynnościowego wypisu. Centrum preferencji („zarządzanie preferencjami”) to cenny dodatek, który może obniżyć wskaźnik wypisów, ale nie zastępuje samego wypisu. Oferuj jedno i drugie.

W praktyce centrum preferencji (gdzie użytkownicy zmniejszają częstotliwość lub wybierają tematy) świetnie wspiera retencję, ale nigdy nie może zastąpić prawdziwej opcji „wypisz mnie ze wszystkiego”. Jeśli reżim lub dostawca wymaga jednoklikowego wypisu, a Twoim jedynym wyjściem jest wieloetapowy formularz preferencji, nie jesteś zgodny, a jednoklikowy przepływ List-Unsubscribe-Post zepsuje się, bo nie potrafi nawigować po formularzu.

Poprawny wzorzec:

• Przepływ POST jednego kliknięcia wypisuje z odpowiedniej listy (lub całego marketingu) natychmiast, bez UI.
• Strona docelowa GET potwierdza wypis, a następnie oferuje centrum preferencji jako drugorzędną, opcjonalną ścieżkę („Wolisz mniej maili? Zarządzaj preferencjami”).
• Centrum preferencji nigdy nie jest jedynym wyjściem ani warunkiem koniecznym odejścia.

Zob. Maile marketingowe o stronie UX centrów preferencji oraz Zarządzanie listą o modelowaniu suppression zakresowego per lista vs. globalnego.

Jakie rejestry zgód muszę przechowywać?

Szczególnie pod RODO, ePrivacy i CASL musisz umieć udowodnić zgodę. Zasada rozliczalności RODO (art. 5 ust. 2) czyni to wprost: nie wystarczy mieć zgodę, musisz umieć ją wykazać. Oznacza to rejestrowanie zgody jako uporządkowanych, przeszukiwalnych danych z niezmienną historią, a nie jako założenia ani pojedynczej flagi.

Dla każdego zdarzenia zgody rejestruj te pola:

• Adres e‑mail (i każdy inny identyfikator, którego zgoda dotyczy)
• Dokładną datę/godzinę zgody (UTC, najlepiej co do sekundy)
• Metodę (przesłanie formularza, checkbox, kliknięcie potwierdzenia double opt‑in, import z dowodem itd.)
• Na co wyrazili zgodę (zakres: które listy/cele, w formie granularnej)
• Źródło (która strona, formularz lub kampania, i wersję treści zgody, którą widzieli)
• Rodzaj zgody (CASL: wyraźna vs. dorozumiana, a dla dorozumianej zdarzenie wyzwalające i jego data, byś mógł obliczyć wygaśnięcie)
• Dowód potwierdzającego działania (np. token double opt‑in oraz IP/znacznik czasu kliknięcia potwierdzenia)

Jak to przechowywać? Użyj bazy danych ze znacznikami czasu, ścieżką audytu zmian tylko do dopisywania (append‑only) i powiązaniem z kontem użytkownika. Ścieżka audytu ma znaczenie, bo stan zgody zmienia się w czasie (udzielona → zmodyfikowana → wycofana), a organy regulacyjne mogą poprosić o odtworzenie tej historii. Nigdy nie nadpisuj poprzedniego stanu w miejscu; zapisz nowy wiersz.

Przykład: schemat zdarzenia zgody

// Append-only. Nigdy nie rób UPDATE wiersza zgody; zawsze INSERT nowego zdarzenia.
// Aktualny stan zgody to najnowsze zdarzenie dla danej (email, scope).
type ConsentEvent = {
  id: string;                  // uuid
  email: string;               // zmałe litery, podmiot zgody
  userId: string | null;       // powiązanie z kontem, jeśli znane
  scope: string;               // np. "weekly-digest", "product-news", "all-marketing"
  action: "granted" | "withdrawn" | "modified";
  consentType: "express" | "implied"; // istotne dla CASL
  // Dla zgody dorozumianej (CASL): co ją utworzyło + kiedy, by wygaśnięcie było policzalne.
  impliedBasis?: "purchase" | "inquiry" | "published-address";
  impliedSince?: string;       // znacznik czasu ISO zdarzenia wyzwalającego
  method: "double-opt-in" | "single-opt-in" | "import" | "checkout-checkbox";
  source: string;              // id formularza/strony/kampanii
  consentTextVersion: string;  // na którą dokładnie treść użytkownik się zgodził
  ip?: string;                 // uchwycone jako dowód (samo w sobie dane osobowe)
  userAgent?: string;
  occurredAt: string;          // ISO 8601, UTC
};

// Obliczanie wygaśnięcia zgody dorozumianej CASL:
function impliedConsentExpiry(e: ConsentEvent): Date | null {
  if (e.consentType !== "implied" || !e.impliedSince) return null;
  const since = new Date(e.impliedSince);
  const months = e.impliedBasis === "inquiry" ? 6 : 24; // 6 mies. zapytanie, 2 lata relacja
  // Nie mutuj `since`; zbuduj nową Date dla wygaśnięcia.
  const expiry = new Date(since);
  expiry.setMonth(expiry.getMonth() + months);
  return expiry;
}

Checklista rejestru zgody

• Zapisany adres e‑mail (znormalizowany/małe litery)
• Uchwycony dokładny znacznik czasu zgody w UTC
• Zapisana metoda zgody (który formularz / checkbox / double opt‑in)
• Zapisany zakres (granularnie: na co dokładnie się zgodzili)
• Zapisane źródło (strona/kampania + wersja treści zgody)
• Zapisany rodzaj zgody (wyraźna vs. dorozumiana; dla dorozumianej podstawa + data startu)
• Zachowany dowód potwierdzającego działania (token double opt‑in / kliknięcie potwierdzenia)
• Utrzymywana ścieżka audytu kolejnych zmian tylko do dopisywania
• Rejestry powiązane z kontem użytkownika tam, gdzie istnieje

O uchwyceniu tych pól przy zapisie (i mechanice double opt‑in) zob. Pozyskiwanie adresów.

Jak długo mogę przechowywać dane subskrybentów?

Tylko tak długo, jak masz ku temu powód. Trzymanie danych w nieskończoność samo w sobie jest ryzykiem zgodności pod zasadą ograniczenia przechowywania RODO (art. 5 ust. 1 lit. e). Dwa reżimy wyznaczają jawne, pozornie przeciwstawne oczekiwania:

Nie są one sprzeczne, dotyczą różnych danych:

• Przechowuj rejestr zgody (dowód pozwolenia, znacznik czasu, metoda, zakres) tak długo, jak możesz potrzebować go bronić, zgodnie z CASL i zasadą rozliczalności RODO.
• Nie gromadź szerszych danych osobowych (historia zachowań, atrybuty profilu, logi wiadomości), których nie masz aktualnego, zgodnego z prawem zastosowania. Minimalizuj je i usuwaj.

Praktyczne rozstrzygnięcie: gdy usuwasz profil subskrybenta w ramach żądania usunięcia z RODO, możesz nadal zachować minimalny rekord suppression (zahaszowany lub jawny e‑mail plus flaga „nie kontaktować” i znacznik czasu), bo utrzymywanie kogoś poza listą jest samo w sobie uzasadnionym, często prawnie wymaganym powodem zatrzymania tego jednego faktu. Udokumentuj to w swojej polityce retencji, by zatrzymany wpis suppression był do obrony.

Dobra praktyka:

• Miej jasną, spisaną politykę retencji, która określa, jak długo i dlaczego przechowywany jest każdy typ danych.
• Honoruj żądania usunięcia bez zwłoki (RODO, „prawo do bycia zapomnianym”, art. 17), zob. następną sekcję.
• Regularnie przeglądaj i czyść: przycinaj nieaktywnych subskrybentów i przeterminowane dane profilowe według harmonogramu, zamiast pozwalać im się gromadzić. (Próba ponownego zaangażowania przed przycięciem chroni dostarczalność; zob. Zarządzanie listą).
• Zachowaj rekord wyłącznie suppression po usunięciu, byś przypadkiem nie dodał ponownie i nie wysłał maila osobie, która odeszła.

Jak obsługiwać żądania osób, których dane dotyczą (dostęp, usunięcie, przenoszenie)?

Pod RODO, LGPD, UK GDPR i amerykańskimi stanowymi prawami o prywatności osoby fizyczne mogą zażądać działania na swoich danych, a Ty masz zwykle ustawowy termin (RODO: jeden miesiąc, z możliwością wydłużenia; CCPA/CPRA: 45 dni). Buduj to jako operacje pierwszej klasy, a nie doraźne zgłoszenia do supportu.

Żądania, które musisz obsłużyć dla danych e‑mailowych:

• Dostęp (art. 15), wytwórz dane osobowe, które o nich posiadasz, w tym ich historię zgód i to, jakie wiadomości wysłałeś. Twój log zdarzeń zgody czyni to prostym.
• Usunięcie (art. 17), usuń ich dane osobowe, z wyjątkiem minimalnego rekordu suppression potrzebnego, by trzymać ich poza listą.
• Przenoszenie (art. 20), wyeksportuj ich dane w ustrukturyzowanym, czytelnym maszynowo formacie (JSON/CSV).
• Sprzeciw wobec marketingu bezpośredniego (art. 21), bezwzględny: musisz zaprzestać marketingu do nich, natychmiast i bez wyjątku. Funkcjonalnie identyczny z wypisem, ale wyzwalany dowolnym kanałem (odpowiedź mailem, zgłoszenie do supportu, formularz na stronie), więc kieruj je wszystkie do tej samej akcji suppression.

Zweryfikuj tożsamość przed działaniem, ale proporcjonalnie. Nie żądaj skanu paszportu, by uhonorować wypis; samo żądanie, przychodzące z danego adresu, zwykle wystarcza przy sprzeciwach marketingowych. Przy pełnych eksportach danych uzasadniona jest mocniejsza weryfikacja.

Szkic obsługi żądań niezależny od dostawcy:

// Jeden punkt wejścia dla wszystkich żądań osób, by terminy i audyt były jednolite.
async function handleDataSubjectRequest(req: {
  email: string;
  type: "access" | "erasure" | "portability" | "marketing-objection";
}) {
  switch (req.type) {
    case "marketing-objection":
      // Bezwzględne + natychmiastowe. Ta sama ścieżka co wypis.
      await suppression.suppress({ email: req.email, scope: "all-marketing", reason: "art21-objection", at: now() });
      return ack("Marketing stopped.");

    case "access":
    case "portability":
      // Zbierz z własnych magazynów; logi wiadomości po stronie dostawcy mogą wymagać API/eksportu.
      const profile = await store.exportProfile(req.email);   // Twoja baza danych
      const consents = await store.exportConsents(req.email); // log zdarzeń zgody
      return exportBundle({ profile, consents }, req.type === "portability" ? "json" : "html");

    case "erasure":
      await store.deleteProfile(req.email);
      // Zachowaj WYŁĄCZNIE minimalny rekord suppression, by nigdy nie dodano ich ponownie.
      await suppression.suppress({ email: req.email, scope: "all", reason: "erasure-retain-suppression", at: now() });
      // Poproś też o usunięcie z przechowywanych kontaktów/logów Twojego dostawcy wysyłki
      // przez dowolne API, które udostępnia (generyczne wywołanie, nie ESP-specyficzne).
      await emailClient.deleteContact?.(req.email);
      return ack("Data erased; retained suppression only.");
  }
}

Częste błędy:

• Traktowanie sprzeciwu marketingowego lub wypisu przychodzącego odpowiedzią lub zgłoszeniem do supportu jako nieformalnego i nielogowanie go, niesie tę samą wagę prawną co link w stopce.
• Usunięcie kogoś tak dokładnie, że tracisz rekord suppression i później ponownie importujesz i wysyłasz do niego mail.
• Przekroczenie ustawowego terminu odpowiedzi, bo żądania żyją w kolejce supportu bez SLA.
• Zapominanie, że dane przechowywane przez Twojego dostawcę wysyłki (listy kontaktów, logi zdarzeń) też są w zakresie, usunięcie musi się tam propagować.

Co musi zawierać moja polityka prywatności?

Zgodny program potrzebuje opublikowanej polityki prywatności, która co najmniej obejmuje:

• Jakie dane zbierasz (w tym adres e‑mail, IP przy rejestracji, dane o zaangażowaniu/otwarciach‑kliknięciach i wszelkie wywnioskowane atrybuty)
• Podstawę prawną dla każdego celu przetwarzania (zgoda na marketing, umowa na transakcyjne)
• Jak wykorzystujesz dane
• Z kim dzielisz się danymi, wprost wskazując swojego dostawcę wysyłki jako podmiot przetwarzający/podprzetwarzający (Amazon SES, Postmark, SendGrid, Mailgun, Resend, Brevo, SparkPost, Mandrill lub ten, którego używasz), plus analitykę i CRM
• Jak długo to przechowujesz (Twoja polityka retencji, w streszczeniu)
• Prawa użytkownika (dostęp, usunięcie, przenoszenie, sprzeciw) i jak z nich korzystać
• Jak skontaktować się z Tobą w sprawie prywatności (realny adres/kanał)
• Transfery międzynarodowe, jeśli dane opuszczają UE/EOG (i mechanizm zabezpieczający, na którym się opierasz, np. SCC)

To zarazem wymóg prawny w reżimach typu RODO/LGPD oraz sygnał zaufania dla subskrybentów. Dwa obowiązki na styku z inżynierią, o których ludzie zapominają:

• Wymień swoich podprzetwarzających. Twój ESP przetwarza dane osobowe w Twoim imieniu; RODO wymaga umowy powierzenia przetwarzania danych (DPA) z nim oraz ujawnienia podprzetwarzających. Większość dostawców publikuje standardową DPA, podpisz ją.
• Trzymaj ją aktualną i zalinkowaną. Linkuj politykę z formularzy zapisu (by zgoda była „świadoma”) i ze stopek maili. Jeśli Twoje praktyki dotyczące danych zmieniają się istotnie, zaktualizuj politykę; dla nowych celów możesz potrzebować świeżej zgody.

Jak zachować zgodność przy wysyłce międzynarodowej?

Zbuduj jeden program pod najsurowszą regułę. Ponieważ e‑mail ignoruje granice, pojedyncza kampania może jednocześnie podlegać CAN‑SPAM, RODO, ePrivacy, CASL i innym, plus regułom akceptacji Gmaila/Yahoo/Microsoftu na wierzchu.

Dobra praktyka: stosuj najbardziej restrykcyjny wymóg na każdym wymiarze (zwykle RODO/ePrivacy dla zgody, CASL dla trwałości). Zamiast utrzymywać osobną postawę zgodności dla każdego kraju, zaprojektuj jeden program, który spełnia najsurowszą obowiązującą regułę na każdej osi:

• Zgoda: stosuj wyraźny opt‑in (RODO/CASL) wszędzie, z double opt‑in tam, gdzie dostarczalność i dowód mają największe znaczenie.
• Identyfikacja: w każdej wiadomości komercyjnej dołącz realny adres fizyczny oraz dokładne, działające From/Reply‑To (CAN‑SPAM + CASL + Spam Act).
• Termin wypisu: przetwarzaj natychmiast (RODO) wszędzie; nigdy nie wyczekuj 10‑dniowego pułapu.
• Trwałość wypisu: utrzymuj ważność linków co najmniej 60 dni (CASL) wszędzie.
• 5‑dniowe okno Australii: spełnione automatycznie, jeśli przetwarzasz natychmiast.
• Uwierzytelnianie: SPF + DKIM + DMARC z alignment na każdej domenie wysyłającej (reguły wobec masowych z lutego 2024 / maja 2025), wymagane, by w ogóle zostać dostarczonym.
• Rejestry: loguj zgodę ze znacznikiem czasu, metodą, zakresem, źródłem i rodzajem; utrzymuj ścieżkę audytu tylko do dopisywania.

Ta strategia „spełniaj najsurowsze” jest prostsza w obsłudze i audycie niż żonglowanie regułami per jurysdykcja, i chroni Cię w miarę wchodzenia na nowe rynki.

Checklista zgodności międzynarodowej

• Wyraźny opt‑in stosowany wobec wszystkich odbiorców marketingowych (double opt‑in tam, gdzie praktyczne)
• Rejestry zgód zapisane ze znacznikiem czasu, metodą, zakresem, źródłem i rodzajem (wyraźna/dorozumiana)
• Fizyczny adres pocztowy + dokładne From/Reply‑To w każdej wiadomości komercyjnej
• Wypis przetwarzany natychmiast (suppression sprawdzane przed każdą wysyłką)
• Link do wypisu ważny co najmniej 60 dni
• List-Unsubscribe + List-Unsubscribe-Post (jednoklikowy RFC 8058) na masowych wysyłkach marketingowych
• SPF (RFC 7208) + DKIM (RFC 6376) + DMARC (RFC 7489) opublikowane i z alignment
• Wskaźnik skarg na spam monitorowany i utrzymywany poniżej 0,3% (cel < 0,1%)
• Żądania osób, których dane dotyczą (dostęp/usunięcie/przenoszenie/sprzeciw), obsługiwane z SLA
• Opublikowana, aktualna polityka prywatności wymieniająca podprzetwarzającego ESP; podpisana DPA
• Wdrożona polityka retencji; honorowane żądania usunięcia; rekord wyłącznie suppression zachowany po usunięciu

Częste błędy międzynarodowe

• Stosowanie permisywnego modelu opt‑out z CAN‑SPAM wobec odbiorców z UE lub Kanady, bo „tak to robimy w USA”.
• Kupowanie lub scrapowanie list, nielegalne jako podstawa marketingu pod RODO/CASL i szybka droga do wskaźnika skarg na spam powyżej 0,3%.
• Geo‑segmentacja reguł zgody, ale używanie jednej ścieżki wysyłki, która ignoruje segment w czasie wysyłki.
• Traktowanie reguł dostawców skrzynek z lutego 2024 jako wyłącznie amerykańskich, Gmail/Yahoo/Microsoft egzekwują je globalnie, według domeny odbiorcy.

Co przeczytać dalej?

• Pozyskiwanie adresów: wdrożenie formularzy zgody i double opt‑in oraz uchwycenie powyższych pól zgody
• Maile marketingowe: wymogi zgody i wypisu w praktyce plus UX centrum preferencji
• Zarządzanie listą: listy suppression, obsługa wypisów i żądań usunięcia
• Dostarczalność: pełna mechanika uwierzytelniania (SPF/DKIM/DMARC/ARC/MTA‑STS/TLS‑RPT/BIMI) i nagłówek List-Unsubscribe w kontekście
• Typy maili: transakcyjne vs marketingowe: które reguły dotyczą których wiadomości
• Katalog transakcyjnych: utrzymywanie szablonów transakcyjnych wolnymi od treści promocyjnych
• Webhooki i zdarzenia: przyjmowanie zdarzeń wypisu i skarg
• Spis treści