Katalog maili transakcyjnych

Ten rozdział odpowiada na jedno praktyczne pytanie: jakich maili transakcyjnych potrzebuje Twoja aplikacja i co musi zawierać każdy z nich? To praktyczny przewodnik. Skorzystaj z niego, by zdecydować, które maile zbudować, kiedy wysyłać każdy z nich i jaką treść muszą zawierać.

Ten poradnik zawiera ogólne informacje, a nie poradę prawną. Tam, gdzie treść maila dotyka zgodności (na przykład co liczy się jako „promocyjne”), potwierdź aktualne zasady dla swoich rynków u wykwalifikowanego specjalisty.

Szybkie odpowiedzi:

• Które trzy maile potrzebuje niemal każda aplikacja? Weryfikacja, reset hasła i niepromocyjne powitanie.
• Jak szybko zakreślić zakres systemu mailowego? Znajdź typ aplikacji poniżej i skopiuj jego listę „Niezbędne” do backlogu.
• Czego potrzebuje każdy mail? Sprawdź w pełnym katalogu: kiedy wysłać, cel, wymaganą treść, dobre praktyki.
• Kiedy „zapowiedź funkcji” jest transakcyjna? Tylko gdy zmiana zmusza użytkownika do działania. W przeciwnym razie to marketing.
• Gdzie reputacyjnie trafiają te wiadomości? Niemal cała poczta transakcyjna powinna wychodzić z dedykowanej subdomeny transakcyjnej, która nigdy nie niesie marketingu, zobacz Niezawodność wysyłki, gdzie opisano podział na subdomeny i warm-up.

Jak korzystać z tego rozdziału?

Katalog ma dwie części. Czytaj je po kolei:

1. Zestawy maili według typu aplikacji. Szybki sposób na zakreślenie zakresu systemu mailowego. Znajdź typ aplikacji najbliższy temu, co budujesz, i zacznij od jego listy „Niezbędne”.
2. Pełny katalog maili. Szczegółowa specyfikacja każdego maila wymienionego wyżej: kiedy go wysłać, jaki ma cel, jaką treść musi zawierać i jakie są dobre praktyki.

Praktyczny tok pracy: wybierz typ aplikacji, skopiuj jego listę „Niezbędne” do backlogu, a następnie znajdź każdy mail w pełnym katalogu, by zdefiniować jego treść. Pozycje „Opcjonalne” to dobrzy kandydaci na drugą iterację.

Uniwersalna baza: niemal każda aplikacja potrzebuje weryfikacji e‑maila, resetu hasła i niepromocyjnego maila powitalnego. Jeśli nie zbudujesz nic innego, zbuduj najpierw te trzy.

Co „transakcyjny” naprawdę znaczy w tym katalogu?

Każdy mail w tym katalogu ma jedną wspólną cechę: jest wyzwalany konkretnym działaniem lub zmianą stanu powiązaną z jednym odbiorcą, a odbiorca się go spodziewa z powodu czegoś, co zrobił. To właśnie ta cecha trzyma te wiadomości poza obowiązkami zgody i wypisu nakładanymi na nadawców masowych w większości jurysdykcji i to ona pozwala wysyłać je bez uprzedniej zgody marketingowej (opt-in). W chwili, gdy wiadomość przestaje być jeden-do-jednego konsekwencją własnego działania odbiorcy, a zaczyna być rozsyłką, którą Ty zdecydowałeś się wysłać, staje się marketingiem, niezależnie od tematu wiadomości. Granica, testy prawne za nią stojące oraz przypadki ze strefy szarej (paragony z cross-sellem, maile „tęsknimy za Tobą”, potwierdzenia double opt-in) są szczegółowo przepracowane w Typy maili: transakcyjne vs marketingowe i Zgodność prawna. Ten rozdział zakłada, że masz tę granicę przyswojoną; jeśli nie, przeczytaj najpierw te dwa.

Jedna konsekwencja ma znaczenie dla wszystkiego poniżej: wiadomość czysto transakcyjna jest zwolniona z wymogu wypisu jednym kliknięciem (RFC 8058), który zasady dla nadawców masowych z lutego 2024 nakładają na marketing, ale to zwolnienie jest wąskie i kruche. Dodaj jeden element promocyjny, baner z rabatem, blok „mogą Ci się też spodobać”, zachętę do polecenia, a regulator lub filtr operatora skrzynki może przekwalifikować całą wiadomość na marketing, w którym to momencie brakujący nagłówek List-Unsubscribe staje się luką w zgodności, a wiadomość podbija Twój marketingowy wskaźnik skarg. Najbezpieczniejsza inżyniersko postawa to bezwzględne utrzymywanie strumieni transakcyjnych w czystości i umieszczanie każdego elementu promocyjnego w strumieniu marketingowym opisanym w Maile marketingowe.

Jakich maili transakcyjnych potrzebuje moja aplikacja?

Użyj zestawów poniżej jako punktu wyjścia w zależności od tego, co budujesz. Każdy wymienia maile, które warto traktować jako Niezbędne (zbuduj najpierw) i Opcjonalne (zbuduj w kolejnej iteracji), oraz wyjaśnia, dlaczego taki zestaw pasuje do danego typu aplikacji.

Czego potrzebuje aplikacja skupiona na uwierzytelnianiu?

To obejmuje aplikacje, w których konta użytkowników i bezpieczeństwo są kluczowe: systemy logowania, dostawcy tożsamości, zarządzanie kontem.

Niezbędne:

• Weryfikacja e‑maila
• Reset hasła
• Kody OTP / 2FA
• Alerty bezpieczeństwa (nowe urządzenie, zmiana hasła)
• Powiadomienia o aktualizacji konta

Opcjonalne:

• Mail powitalny (nie może być promocyjny)
• Potwierdzenie usunięcia konta

Dlaczego ten zestaw: dla produktu tożsamościowego maile są powierzchnią produktu. Alerty bezpieczeństwa i kody 2FA niosą zaufanie, na którym opiera się wszystko inne, więc mają najwyższy priorytet i najczystszą dostarczalność. Wysyłaj je z dedykowanej subdomeny transakcyjnej, która nigdy nie niesie marketingu.

Czego potrzebuje platforma newsletterowa lub treściowa?

To obejmuje aplikacje skupione na dostarczaniu treści i subskrypcjach.

Niezbędne:

• Weryfikacja e‑maila
• Reset hasła
• Mail powitalny (nie może być promocyjny)
• Potwierdzenie subskrypcji

Opcjonalne:

• Kody OTP / 2FA
• Powiadomienia o aktualizacji konta

Dlaczego ten zestaw: potwierdzenie subskrypcji jest kotwicą transakcyjną. Same maile z treścią są marketingowe i żyją na osobnej subdomenie z pełną obsługą zgody i wypisem jednym kliknięciem. Nie zacieraj różnicy między nimi, bo skarga na newsletter zaszkodzi reputacji Twojego maila z resetem hasła.

Czego potrzebuje aplikacja e‑commerce lub marketplace?

To obejmuje aplikacje, w których użytkownicy kupują produkty lub usługi.

Niezbędne:

• Weryfikacja e‑maila
• Reset hasła
• Mail powitalny (nie może być promocyjny)
• Potwierdzenie zamówienia
• Powiadomienia o wysyłce
• Faktura / paragon
• Powiadomienia o nieudanej płatności

Opcjonalne:

• Kody OTP / 2FA
• Alerty bezpieczeństwa
• Potwierdzenia subskrypcji (dla zamówień cyklicznych)

Dlaczego ten zestaw: każdy zakup generuje łańcuch oczekiwanych maili: potwierdź, obciąż, wyślij. Brak któregokolwiek ogniwa rodzi zgłoszenia do wsparcia i obciążenia zwrotne, dlatego ta kategoria ma najdłuższą listę niezbędnych. Łańcuch potwierdź‑obciąż‑wyślij to minimum; maile o porzuconym koszyku i prośby o recenzję są marketingiem i należą do osobnego strumienia.

Dodatek dla marketplace. Marketplace ma dwie strony na transakcję, a każda potrzebuje własnego wątku. Kupujący dostaje potwierdzenie zamówienia, wysyłkę i paragon; sprzedający dostaje powiadomienie „masz nowe zamówienie”, powiadomienie „wypłata wysłana” oraz alerty o sporach/zwrotach. Traktuj strumień sprzedającego jako odrębny zestaw szablonów transakcyjnych z własnymi wyzwalaczami, nie doczepiaj powiadomień sprzedającego do szablonów kupującego. Powiadomienia o wypłatach w szczególności są zapisami finansowymi i podlegają zasadom faktury/paragonu poniżej.

Czego potrzebuje usługa SaaS lub subskrypcyjna?

To obejmuje aplikacje z płatnymi poziomami subskrypcji i cyklicznymi rozliczeniami.

Niezbędne:

• Weryfikacja e‑maila
• Reset hasła
• Mail powitalny (nie może być promocyjny)
• Kody OTP / 2FA
• Alerty bezpieczeństwa
• Potwierdzenie subskrypcji
• Powiadomienie o odnowieniu subskrypcji
• Powiadomienia o nieudanej płatności
• Faktura / paragon

Opcjonalne:

• Powiadomienia o aktualizacji konta
• Powiadomienia o zmianie funkcji (przy zmianach łamiących kompatybilność)
• Maile z zaproszeniem do zespołu / na stanowisko (seat)
• Powiadomienia o kończącym się okresie próbnym (transakcyjne tylko wtedy, gdy automatycznie następuje obciążenie lub obniżenie planu)

Dlaczego ten zestaw: cykliczne rozliczenia oznaczają cykliczne punkty styku transakcyjnego. Powiadomienia o odnowieniu i procesy obsługi nieudanych płatności wprost chronią przychód. Mail o nieudanej płatności, który trafia do spamu, często staje się mimowolnym odpływem klienta, więc dostarczalność strumienia rozliczeniowego to metryka przychodowa, nie próżnościowa.

O powiadomieniach o kończącym się okresie próbnym: „Twój okres próbny kończy się za 3 dni” jest transakcyjne, gdy okres próbny automatycznie przechodzi w plan płatny (użytkownik musi działać, by uniknąć obciążenia), a marketingowe, gdy tak nie jest (nic się nie dzieje z kontem użytkownika, jeśli to zignoruje, po prostu próbujesz go skonwertować). Ten sam temat wiadomości, przeciwna klasyfikacja, rozstrzygnięta wyłącznie przez to, co stanie się, jeśli użytkownik nic nie zrobi.

Czego potrzebuje aplikacja finansowa lub fintech?

To obejmuje aplikacje obsługujące pieniądze, płatności lub wrażliwe dane finansowe.

Niezbędne:

• Weryfikacja e‑maila
• Reset hasła
• Kody OTP / 2FA (wymagane przy wrażliwych działaniach)
• Alerty bezpieczeństwa (wszystkie typy)
• Powiadomienia o aktualizacji konta
• Potwierdzenia transakcji
• Faktura / paragon
• Powiadomienia o nieudanej płatności

Opcjonalne:

• Mail powitalny (nie może być promocyjny)
• Powiadomienia dotyczące zgodności

Dlaczego ten zestaw: fintech łączy najsurowsze podejście do bezpieczeństwa z regulacyjnym śladem dokumentowym. Każdy przepływ pieniędzy i zmiana konta powinny generować potwierdzenie, które użytkownik może później zweryfikować. Utrzymuj te zapisy spójnymi i przeszukiwalnymi, bo użytkownicy i regulatorzy mogą zażądać ich nawet po latach.

Czego potrzebuje platforma społecznościowa?

To obejmuje aplikacje skupione na interakcji użytkowników i funkcjach społecznościowych.

Niezbędne:

• Weryfikacja e‑maila
• Reset hasła
• Mail powitalny (nie może być promocyjny)
• Alerty bezpieczeństwa

Opcjonalne:

• Kody OTP / 2FA
• Powiadomienia o aktualizacji konta
• Powiadomienia o aktywności (wzmianki, odpowiedzi)

Dlaczego ten zestaw: powiadomienia o aktywności mogą napędzać zaangażowanie, ale uważaj. Grupuj je i ułatwiaj kontrolę, bo inaczej zaczynają sprawiać wrażenie marketingu i generują skargi. Daj użytkownikom szczegółowe preferencje (osobno dla każdego typu, plus opcję dziennego podsumowania), by powiadomienia pozostały pożądane.

Powiadomienia o aktywności to najtrudniejsza decyzja klasyfikacyjna w tym katalogu. Bezpośrednie, między dwiema osobami zdarzenie, na które odbiorca wyraził zgodę (odpowiedź na Twój komentarz, wiadomość bezpośrednia, wzmianka), jest do obrony jako transakcyjne. Podsumowanie „osoby, które możesz znać” lub „popularne w Twojej sieci” to marketing przebrany za powiadomienie. W razie wątpliwości nadaj każdemu typowi powiadomienia o aktywności nagłówek List-Unsubscribe/List-Unsubscribe-Post (RFC 8058) i honoruj go, mimo że wiadomość jest nominalnie transakcyjna, kosztem jest jeden nagłówek, a chroni Cię, jeśli klasyfikator operatora skrzynki nie zgodzi się z Twoim. Zobacz Zarządzanie listą, jak modelować te szczegółowe preferencje.

Czego potrzebują narzędzia deweloperskie lub platforma API?

To obejmuje aplikacje skierowane do deweloperów, z dostępem do API i integracjami.

Niezbędne:

• Weryfikacja e‑maila
• Reset hasła
• Kody OTP / 2FA
• Alerty bezpieczeństwa
• Powiadomienia o kluczach API (utworzenie, wygaśnięcie)
• Potwierdzenie subskrypcji
• Powiadomienia o nieudanej płatności

Opcjonalne:

• Mail powitalny (nie może być promocyjny)
• Alerty o zużyciu (zbliżanie się do limitów)
• Powiadomienia o zmianie funkcji
• Alerty o nieudanym dostarczeniu webhooka

Dlaczego ten zestaw: deweloperzy polegają na sygnałach operacyjnych. Wygasający klucz API lub zbliżający się limit, o których mail po cichu nie dotrze, mogą zepsuć produkcyjny system klienta. Wysyłaj alerty o zużyciu i wygasaniu kluczy z odpowiednim wyprzedzeniem (na przykład 30, 7 i 1 dzień przed wygaśnięciem klucza API), by klient mógł wymienić klucze bez przestoju.

O alertach o nieudanym dostarczeniu webhooka: jeśli Twoja platforma dostarcza webhooki Twoim klientom, utrzymujące się niepowodzenie dostarczenia to dla nich operacyjny stan wyjątkowy i mail jest uzasadniony. Wyślij go raz na zawodzący endpoint na okno incydentu, nie raz na nieudane dostarczenie, bo inaczej jeden niedziałający endpoint wygeneruje tysiące maili i spali Twoją reputację. Zdarzenia napędzające te maile to te same, które konsumujesz, gdy Ty odbierasz webhooki od dostawcy; zobacz Webhooki i zdarzenia, gdzie opisano stronę konsumenta.

Czego potrzebuje aplikacja medyczna lub zgodna z HIPAA?

To obejmuje aplikacje obsługujące chronione informacje zdrowotne (PHI).

Niezbędne:

• Weryfikacja e‑maila
• Reset hasła
• Kody OTP / 2FA (wymagane)
• Alerty bezpieczeństwa (wszystkie typy, szczegółowe)
• Powiadomienia o aktualizacji konta
• Potwierdzenia wizyt

Opcjonalne:

• Mail powitalny (nie może być promocyjny)
• Powiadomienia dotyczące zgodności

Uwaga: aplikacje medyczne mają surowe wymogi. Maile powinny zawierać minimum PHI i odsyłać do bezpiecznych portali w przypadku wrażliwych informacji.

Praktyczna zasada dla ochrony zdrowia: traktuj treść maila jak publiczną. Nigdy nie umieszczaj diagnoz, wyników badań ani innych PHI w samym mailu. Wyślij neutralne powiadomienie („Masz nową wiadomość”) i wymagaj, by użytkownik zalogował się do bezpiecznego portalu, aby zobaczyć szczegóły. Standardowy e‑mail nie jest gwarancją szyfrowania w tranzycie nawet z MTA-STS (RFC 8461) i DANE, bo nie udowodnisz, że każdy przeskok wymusił TLS; zakładaj, że dowolna wartość umieszczona w treści może zostać odczytana przez pośrednika.

Jak porównać zestawy niezbędne na pierwszy rzut oka?

A jeśli moja aplikacja łączy dwa typy? Większość produktów tak robi (aplikacja fintech jest też SaaS, marketplace jest też społecznościowy). Weź sumę list niezbędnych, a potem rozstrzygaj konflikty w stronę surowszej zasady: jeśli którykolwiek typ wymaga OTP/2FA, zbuduj je; jeśli którykolwiek obsługuje PHI, zastosuj zasadę portalu medycznego wszędzie.

Jak krytyczny jest każdy mail i co to oznacza dla inżynierii?

Nie każdy mail transakcyjny zasługuje na ten sam nakład inżynierski. Użyj modelu warstw (tier), by zdecydować, gdzie idempotencja, ponawianie, budżety opóźnień i dedykowana pula IP są warte kosztu. Mechanika ponawiania i idempotencji dla każdej warstwy żyje w Niezawodności wysyłki; ta tabela to decyzja routingowa.

Praktyczna lekcja jest taka, że Warstwa 0 i Warstwa 1 zasługują na własną tożsamość wysyłkową i własny monitoring, a Warstwa 3 nigdy nie powinna dzielić z nimi infrastruktury. Hałaśliwy strumień powiadomień, który zbiera skargi spamowe, nie może być w stanie zatruć reputacji, która dostarcza reset hasła.

Pełny katalog maili

To jest referencja dla każdego maila z osobna. Każda pozycja poniżej określa kiedy wysłać, cel, treść, którą powinna zawierać, oraz dobre praktyki. Traktuj listy treści jako wymagania minimalne, a nie górną granicę.

Uwaga o kodzie w tej sekcji. Przykłady używają neutralnej wobec dostawcy abstrakcji emailClient i standardowej biblioteki Node. Celowo nie są związane z żadnym jednym dostawcą usług e‑mail (ESP). Konkretne ESP, Amazon SES, Postmark, SendGrid, Mailgun, Resend, Brevo, SparkPost, Mandrill, są wymieniane tylko jako wymienne przykłady; nic tutaj nie zakłada, że wybrałeś którykolwiek z nich. Minimalna wersja abstrakcji wygląda tak:

// interfejs neutralny wobec dostawcy; oprzyj go na dowolnym ESP lub przekaźniku SMTP, którego używasz
export interface EmailClient {
  send(message: {
    to: string;
    from: string;
    subject: string;
    html: string;
    text: string;
    headers?: Record<string, string>;
    // idempotencyKey pozwala transportowi scalić zduplikowane wysyłki; zobacz 09-niezawodnosc-wysylki.md
    idempotencyKey?: string;
  }): Promise<{ messageId: string }>;
}

Maile uwierzytelniania i bezpieczeństwa

Kiedy i jak wysłać weryfikację e‑maila?

Kiedy wysłać: natychmiast po rejestracji użytkownika lub zmianie adresu e‑mail.

Cel: zweryfikować, że adres e‑mail należy do użytkownika.

Treść powinna zawierać:

• Jasny link lub kod weryfikacyjny
• Czas wygaśnięcia (zwykle 24 do 48 godzin)
• Instrukcję, co zrobić
• Notkę bezpieczeństwa na wypadek kliknięcia linku przez pomyłkę

Dobre praktyki:

• Wysyłaj natychmiast (w ciągu sekund)
• Dołącz informację o wygaśnięciu
• Zapewnij opcję ponownego wysłania
• Dodaj link do wsparcia w razie problemów

Dlaczego to ważne: weryfikacja dowodzi, że faktycznie możesz dotrzeć do użytkownika, i chroni Cię przed adresami z literówkami oraz fałszywymi, które po cichu niszczą reputację nadawcy. Niezweryfikowany adres to obciążenie przy każdej kolejnej wysyłce. Weryfikacja przy rejestracji to najtańszy sposób, by utrzymać niski wskaźnik odbić (bounce).

Przykład z życia, generowanie i przechowywanie tokenu weryfikacyjnego. Wygeneruj token o wysokiej entropii, przechowuj tylko jego hash, a surowy token umieść w linku. Nigdy nie przechowuj surowego tokenu; jeśli Twoja baza wycieknie, zahaszowane tokeny są bezużyteczne dla atakującego.

import { randomBytes, createHash } from "node:crypto";

function createVerificationToken() {
  const raw = randomBytes(32).toString("base64url"); // 256 bitów entropii
  const hash = createHash("sha256").update(raw).digest("hex");
  const expiresAt = new Date(Date.now() + 24 * 60 * 60 * 1000); // 24h
  // utrwal { userId, hash, expiresAt, usedAt: null }
  return { raw, hash, expiresAt };
}

// link niesie SUROWY token; wyszukanie weryfikuje przez zahaszowanie nadchodzącej wartości
function verificationUrl(raw: string) {
  return `https://app.example.com/verify?token=${raw}`;
}

Przypadki brzegowe i tryby awarii:

• Zmiana adresu, nie rejestracja. Gdy użytkownik zmienia adres, wyślij weryfikację na nowy adres, ale utrzymaj stary aktywny, dopóki nowy nie zostanie potwierdzony. Nie przełączaj adresu wiodącego, dopóki weryfikacja się nie powiedzie, bo literówka zablokuje użytkownika.
• Nadużywanie ponownej wysyłki. Limituj ponowne wysyłki (na przykład jedna na 60 sekund, z wykładniczym czasem oczekiwania), by endpoint nie mógł być użyty do zasypania mailami osoby trzeciej. Ponowne wydanie tokenu powinno unieważnić poprzedni.
• Klikanie przez boty. Korporacyjne bramy bezpieczeństwa i skanery linków „klikają” linki, by je sprawdzić, co może skonsumować jednorazowy token weryfikacyjny, zanim człowiek go w ogóle zobaczy. Dla weryfikacji preferuj token, który przetrwa podgląd GET i zatwierdza stan dopiero przy jawnym działaniu potwierdzającym, lub użyj krótkiego kodu numerycznego, którego skaner nie może wywołać.
• Twarde odbicie (hard bounce) przy weryfikacji. Jeśli mail weryfikacyjny twardo odbije (hard bounce), adres jest zły, pokaż to w produkcie natychmiast („nie udało się dotrzeć do tego adresu”) zamiast zostawiać użytkownika wpatrzonego w pustą skrzynkę. Wpisz adres do suppression zgodnie z Zarządzanie listą.

Co wchodzi w mail z kodem OTP / 2FA?

Kiedy wysłać: gdy użytkownik żąda kodu uwierzytelniania dwuskładnikowego.

Cel: dostarczyć wrażliwy na czas kod uwierzytelniający.

Treść powinna zawierać:

• Kod OTP (wyraźnie wyświetlony)
• Czas wygaśnięcia (zwykle 5 do 10 minut)
• Ostrzeżenia bezpieczeństwa
• Instrukcję, co zrobić, jeśli nie był żądany

Dobre praktyki:

• Wysyłaj natychmiast
• Kod powinien być duży i łatwy do odczytania
• Wyraźnie podaj wygaśnięcie
• Ostrzeż przed udostępnianiem kodów
• Dodaj link „Nie prosiłem o to”

Dlaczego to ważne: maile OTP są najbardziej wrażliwą na opóźnienia pocztą, jaką wysyłasz. Kod, który dotrze po wygaśnięciu, jest gorszy niż bezużyteczny. Są też celem phishingu, więc treść musi aktywnie zniechęcać do udostępniania kodu. Nigdy nie umieszczaj kodu w klikalnym linku i nie dołączaj marketingu w tej samej wiadomości.

Szczegóły inżynierskie:

• Umieść kod w temacie wiadomości oprócz treści (123456 to Twój kod weryfikacyjny). Użytkownicy odczytują go z powiadomienia bez otwierania wiadomości, co jest szybsze i usuwa powierzchnię phishingową.
• Budżet opóźnień. To wysyłka Warstwy 0. Celuj w dostarczenie do skrzynki w jednocyfrowej liczbie sekund. Jeśli Twoja kolejka kiedykolwiek może opóźnić, OTP musi ją ominąć szybką ścieżką, albo musisz oferować alternatywny kanał (aplikacja uwierzytelniająca, SMS). OTP e‑mail jest najsłabszym powszechnym drugim składnikiem właśnie z powodu opóźnień dostarczenia i kompromitacji skrzynki, traktuj go jako rozwiązanie awaryjne, nie podstawowe, tam, gdzie bezpieczeństwo ma znaczenie.
• Format kodu. 6 cyfr to konwencja; równoważ entropię z limitowaniem prób. Kod 6‑cyfrowy to tylko ~20 bitów, więc jest bezpieczny tylko ze ścisłymi limitami prób (na przykład 5 prób, potem blokada) i krótkim wygaśnięciem.
• Nigdy nie odzwierciedlaj kodu w linku. Link zawierający kod może zostać podejrzany przez skanery i przecieka sekret do logów oraz nagłówków Referer.

import { randomInt } from "node:crypto";

function generateOtp(): string {
  // randomInt jest oparty na CSPRNG; Math.random NIE jest akceptowalny dla kodów
  return randomInt(0, 1_000_000).toString().padStart(6, "0");
}

Czego potrzebuje mail z resetem hasła?

Kiedy wysłać: gdy użytkownik żąda resetu hasła.

Cel: umożliwić użytkownikowi bezpieczne zresetowanie zapomnianego hasła.

Treść powinna zawierać:

• Link do resetu (z tokenem)
• Czas wygaśnięcia (zwykle 1 godzina)
• Ostrzeżenia bezpieczeństwa
• Instrukcję, jeśli nie był żądany

Dobre praktyki:

• Wysyłaj natychmiast
• Link wygasa szybko (1 godzina)
• Dołącz adres IP i lokalizację, jeśli dostępne
• Dodaj link „Nie prosiłem o to”
• Nie dołączaj starego hasła

Dlaczego to ważne: link do resetu to tymczasowy klucz do konta. Krótkie wygaśnięcie i ścieżka „to nie ja” ograniczają zasięg szkód, jeśli wiadomość zostanie przechwycona lub wysłana do niewłaściwej osoby. Nigdy nie wysyłaj istniejącego hasła. Przechowuj hasła w postaci zahaszowanej, byś nie mógł tego zrobić, nawet gdybyś chciał. Unieważnij token w chwili jego użycia lub wygaśnięcia, w zależności od tego, co nastąpi pierwsze.

Szczegóły bezpieczeństwa, które są często pomijane:

• Wyliczanie kont (enumeracja). Endpoint resetu musi zwracać tę samą odpowiedź niezależnie od tego, czy adres istnieje („Jeśli konto dla tego adresu istnieje, wysłaliśmy link do resetu”). Różniące się odpowiedzi lub różniące się czasy odpowiedzi pozwalają atakującemu wyliczyć, które adresy są zarejestrowane.
• Jednorazowe, serwerowe unieważnienie. Oznacz token usedAt atomowo przy pierwszym użyciu. Token użyty ponownie po udanym resecie musi się nie powieść. Wygaś wszystkie inne nieużyte tokeny resetu dla tego użytkownika, gdy jeden zostaje skonsumowany.
• Unieważnij sesje przy resecie. Po udanej zmianie hasła odwołaj istniejące sesje i tokeny odświeżające. Reset, który zostawia sesję atakującego żywą, niweczy cel.
• Znów skanery linków. Tak jak przy weryfikacji, bramy bezpieczeństwa mogą wstępnie pobrać link resetu. Zatwierdź zmianę hasła tylko przy jawnym POST z formularza resetu, nigdy przy GET, który go renderuje.

Kiedy wysłać alert bezpieczeństwa?

Kiedy wysłać: gdy wystąpią zdarzenia istotne dla bezpieczeństwa (logowanie z nowego urządzenia, zmiana hasła itd.).

Cel: powiadomić użytkownika o zdarzeniach bezpieczeństwa konta.

Treść powinna zawierać:

• Co się stało (jasny opis)
• Kiedy to się stało
• Lokalizacja / IP, jeśli dostępne
• Działanie do podjęcia w razie podejrzeń
• Link do ustawień bezpieczeństwa

Dobre praktyki:

• Wysyłaj natychmiast
• Bądź jasny i konkretny
• Dołącz działania do podjęcia
• Zapewnij sposób na zgłoszenie podejrzanej aktywności

Dlaczego to ważne: alerty bezpieczeństwa są często pierwszym i jedynym ostrzeżeniem użytkownika, że jego konto zostało przejęte. Konkretność („Nowe logowanie z Chrome na Windows w Warszawie”) pozwala użytkownikowi natychmiast odróżnić prawdziwe zdarzenie od ataku. Mgliste alerty („Uzyskano dostęp do Twojego konta”) uczą użytkowników ignorować je, więc za każdym razem dołączaj urządzenie, przeglądarkę, czas i lokalizację.

Które zdarzenia uzasadniają alert:

Częste błędy: wysyłanie alertu o zmianie adresu e‑mail tylko na nowy adres (atakujący go kontroluje) oraz dołączanie linku „cofnij” jednym kliknięciem, który sam staje się wektorem ataku, jeśli wiadomość zostanie przekazana dalej. Spraw, by ścieżka odzyskiwania wymagała uwierzytelnienia.

Maile zarządzania kontem

Co powinien zawierać mail powitalny?

Kiedy wysłać: natychmiast po pomyślnym utworzeniu i weryfikacji konta.

Cel: powitać nowych użytkowników i poprowadzić ich do kolejnych kroków. Nie może być promocyjny.

Treść powinna zawierać:

• Wiadomość powitalną
• Kluczowe funkcje lub kolejne kroki
• Linki do ważnych zasobów
• Dane kontaktowe wsparcia

Dobre praktyki:

• Wysyłaj po weryfikacji e‑maila
• Utrzymaj skupienie i nastawienie na działanie
• Nie przytłaczaj informacjami
• Ustaw oczekiwania co do przyszłych maili

Dlaczego to ważne: mail powitalny to Twoja wiadomość o najwyższym zaangażowaniu. Wskaźniki otwarć są najwyższe tuż po rejestracji. Wykorzystaj tę uwagę do aktywacji, a nie do sprzedaży. Dodanie ofert zamienia transakcyjne powitanie w marketing i pozbawia je podstawy prawnej, więc jeden jasny kolejny krok bije pięć ofert produktowych.

Granica, której nie wolno przekroczyć. „Oto jak zacząć, a oto nasz adres wsparcia” jest transakcyjne. „Witaj, oto 20% rabatu na pierwsze zamówienie i nasze najnowsze funkcje” to marketing, a wysłanie tego z Twojego strumienia transakcyjnego bez zgody i nagłówka List-Unsubscribe (RFC 8058) to dokładnie ten rodzaj zatarcia, który prowadzi do przekwalifikowania całego strumienia. Jeśli chcesz wdrażać i pielęgnować, wyślij czyste transakcyjne powitanie i wyzwól osobną, opartą na zgodzie sekwencję onboardingową w strumieniu marketingowym opisanym w Maile marketingowe.

Kiedy wysyłać powiadomienia o aktualizacji konta?

Kiedy wysłać: gdy użytkownik zmienia ustawienia konta (e‑mail, hasło, profil itd.).

Cel: potwierdzić zmiany na koncie i dostarczyć notkę bezpieczeństwa.

Treść powinna zawierać:

• Co się zmieniło
• Kiedy się zmieniło
• Działanie do podjęcia, jeśli nieautoryzowane
• Link do ustawień konta

Dobre praktyki:

• Wysyłaj natychmiast po zmianie
• Bądź konkretny co do tego, co się zmieniło
• Dołącz notkę bezpieczeństwa
• Zapewnij łatwy sposób cofnięcia w razie potrzeby

Dlaczego to ważne: te powiadomienia są siatką bezpieczeństwa przeciw przejęciu konta. Jeśli atakujący zmieni adres do odzyskiwania, stary adres wciąż otrzyma alert i prawdziwy właściciel może zareagować. W przypadku zmiany adresu e‑mail powiadom zarówno stary, jak i nowy adres.

Przypadki brzegowe: nie ujawniaj nowej wartości w alercie wysłanym na stary adres („Twój e‑mail został zmieniony na attacker@evil.com” mówi atakującemu, że alert się odpalił, i potwierdza, że przejęcie się powiodło). Napisz „Twój adres e‑mail został zmieniony” i pokieruj działanie odzyskiwania przez uwierzytelniony proces. Grupuj niskoryzykowne edycje profilu, jeśli użytkownik wykona ich kilka w jednej sesji, by jedna zmiana ustawień nie generowała pięciu maili.

Maile e‑commerce i transakcji

Co wchodzi w potwierdzenie zamówienia?

Kiedy wysłać: natychmiast po złożeniu zamówienia.

Cel: potwierdzić szczegóły zamówienia i dostarczyć paragon.

Treść powinna zawierać:

• Numer zamówienia
• Zamówione pozycje z ilościami
• Rozbicie cenowe
• Adres dostawy
• Szacowaną datę dostawy
• Link do śledzenia zamówienia (jeśli dostępny)

Dobre praktyki:

• Wysyłaj w ciągu minut od zamówienia
• Dołącz wszystkie szczegóły zamówienia
• Ułatw wydruk lub zapis
• Podaj kontakt do obsługi klienta

Dlaczego to ważne: potwierdzenie zamówienia to dowód zakupu klienta i Twój największy „odbijacz” zgłoszeń „czy moje zamówienie przeszło?”. To także najczęściej otwierany mail handlowy, dlatego właśnie musi pozostać wolny od dosprzedaży, by zachować charakter transakcyjny.

Idempotencja jest tu obowiązkowa. Potwierdzenie zamówienia to wysyłka Warstwy 1. Jeśli Twój webhook lub kolejka checkoutu ponawia, nie wolno Ci wysłać dwóch potwierdzeń na jedno zamówienie. Kluczuj wysyłkę na ID zamówienia, by zduplikowany wyzwalacz był operacją bez efektu (no-op):

async function sendOrderConfirmation(order: Order, emailClient: EmailClient) {
  await emailClient.send({
    to: order.customerEmail,
    from: "orders@txn.example.com", // dedykowana subdomena transakcyjna
    subject: `Order ${order.number} confirmed`,
    html: renderOrderHtml(order),
    text: renderOrderText(order),
    // scala duplikaty, jeśli zdarzenie złożenia zamówienia zostanie dostarczone więcej niż raz
    idempotencyKey: `order-confirmation:${order.id}`,
  });
}

Semantyka ponawiania i kwestie dokładnie-jednokrotnej (exactly-once) wysyłki za tym kluczem są omówione w Niezawodności wysyłki, a zdarzenie nadrzędne, które ją wyzwala, to rodzaj webhooka płatności obsługiwanego w Webhooki i zdarzenia.

Kiedy wysyłać powiadomienia o wysyłce?

Kiedy wysłać: gdy zamówienie zostaje wysłane, wraz z aktualizacjami śledzenia.

Cel: powiadomić użytkownika, że zamówienie zostało wysłane, i dostarczyć śledzenie.

Treść powinna zawierać:

• Numer zamówienia
• Numer przesyłki
• Informacje o przewoźniku
• Oczekiwaną datę dostawy
• Link do śledzenia
• Potwierdzenie adresu dostawy

Dobre praktyki:

• Wysyłaj, gdy zamówienie zostaje wysłane
• Wyraźnie podaj numer przesyłki
• Zapewnij link do śledzenia u przewoźnika
• Aktualizuj przy ważnych kamieniach milowych śledzenia

Dlaczego to ważne: gdy pieniądze już zmieniły właściciela, niepokój klienta przenosi się na „gdzie to jest?”. Proaktywne aktualizacje o wysyłce i kamieniach milowych zmniejszają liczbę zgłoszeń do wsparcia i zwiększają satysfakcję po zakupie. Najbardziej przydatne kamienie milowe do zmailowania to „wysłane”, „w doręczeniu” i „dostarczone”.

Tryby awarii: webhooki przewoźnika odpalają zduplikowane i poza kolejnością zdarzenia. Scalaj je, jeden mail „wysłane”, jeden „w doręczeniu”, jeden „dostarczone”, i kluczuj każdy na (orderId, milestone), by ponownie dostarczone zdarzenie przewoźnika nie wysyłało ponownie maila do klienta. Podzielona wysyłka (dwie paczki na jedno zamówienie) potrzebuje jednego powiadomienia na paczkę z jasnym oznaczeniem „1 z 2”, a nie dwóch identycznych maili „Twoje zamówienie zostało wysłane”.

Czego potrzebuje mail z fakturą lub paragonem?

Kiedy wysłać: po przetworzeniu płatności.

Cel: dostarczyć potwierdzenie płatności i paragon.

Treść powinna zawierać:

• Numer faktury / paragonu
• Kwotę płatności
• Metodę płatności
• Zakupione pozycje / usługi
• Datę płatności
• Plik PDF do pobrania (jeśli dotyczy)

Dobre praktyki:

• Wysyłaj natychmiast po płatności
• Dołącz wszystkie szczegóły płatności
• Ułatw pobranie / zapis
• Dołącz informacje podatkowe, jeśli dotyczy

Dlaczego to ważne: paragony to dokumenty, które ludzie zachowują na potrzeby podatków, rozliczeń kosztów i gwarancji. Stabilny numer faktury i pobieralny PDF zamieniają Twój mail w dokument, który użytkownik może zarchiwizować i odnaleźć po latach. Używaj kolejnego, nigdy nieużywanego ponownie numeru faktury, bo działy finansowe polegają na jego unikalności.

Czego naprawdę wymagają finanse i podatki: w zależności od jurysdykcji zgodna faktura potrzebuje nazwy prawnej sprzedawcy i identyfikatora podatkowego, danych nabywcy dla faktur firmowych, unikalnego kolejnego numeru, daty wystawienia, rozbicia na pozycje i sumę oraz osobno wykazanej stawki i kwoty podatku (VAT/GST). Mail to mechanizm dostarczenia; PDF to zapis. Wygeneruj PDF raz, zapisz go i pozwól użytkownikowi pobrać go ponownie z konta, nigdy nie generuj na bieżąco z innym numerem, bo numer, który zmienia się między dwoma pobraniami, to porażka audytu finansowego.

Maile subskrypcji i rozliczeń

Czego potrzebuje potwierdzenie subskrypcji?

Kiedy wysłać: gdy użytkownik subskrybuje lub zmienia subskrypcję.

Cel: potwierdzić szczegóły subskrypcji i informacje rozliczeniowe.

Treść powinna zawierać:

• Szczegóły planu subskrypcji
• Kwotę i częstotliwość rozliczeń
• Datę następnego rozliczenia
• Metodę płatności
• Link do zarządzania subskrypcją

Dobre praktyki:

• Wysyłaj natychmiast po subskrypcji
• Jasno podaj warunki rozliczeń
• Zapewnij łatwą opcję anulowania
• Dołącz kontakt do wsparcia

Dlaczego to ważne: jasne, podane z góry warunki rozliczeń zapobiegają zaskakującym obciążeniom, które napędzają spory i obciążenia zwrotne. Powiedzenie ludziom dokładnie, kiedy i ile pobierzesz, oraz jak anulować, buduje zaufanie, które utrzymuje subskrypcje przy życiu.

Zmiany planu to odrębne zdarzenia. Podniesienie planu, obniżenie, proporcjonalne rozliczenie i zmiana planu, każde zasługuje na własne potwierdzenie podające nowe warunki, datę wejścia w życie oraz wszelkie proporcjonalne obciążenie lub uznanie. Nie używaj ponownie szablonu pierwszej subskrypcji, użytkownik, który obniża plan i dostaje „Witaj w Twojej subskrypcji!”, będzie zdezorientowany i może zakwestionować obciążenie.

Kiedy wysyłać powiadomienie o odnowieniu subskrypcji?

Kiedy wysłać: przed odnowieniem subskrypcji (zwykle 3 do 7 dni wcześniej).

Cel: powiadomić użytkownika o nadchodzącym odnowieniu i obciążeniu.

Treść powinna zawierać:

• Datę odnowienia
• Kwotę do obciążenia
• Metodę płatności w aktach
• Link do aktualizacji metody płatności
• Link do anulowania, jeśli chciane

Dobre praktyki:

• Wysyłaj z odpowiednim wyprzedzeniem (3 do 7 dni)
• Bądź jasny co do kwoty i daty
• Ułatw aktualizację metody płatności
• Zapewnij opcję anulowania

Dlaczego to ważne: powiadomienia o odnowieniu są coraz częściej wymogiem prawnym dla automatycznie odnawianych subskrypcji w kilku jurysdykcjach i zmniejszają liczbę obciążeń zwrotnych typu „zapomniałem, że subskrybuję”, które szkodzą Twojej pozycji u operatora płatności. Dla planów rocznych większe wyprzedzenie (na przykład 14 do 30 dni) jest zarazem bezpieczniejsze prawnie i milsze dla klienta.

Uwaga jurysdykcyjna: kilka jurysdykcji nakazuje teraz przypomnienia o odnowieniu z wyprzedzeniem oraz ścieżkę anulowania, która jest co najmniej tak łatwa jak rejestracja. Traktuj powiadomienie o odnowieniu jako artefakt prawny, nie tylko uprzejmość, i potwierdź konkretne wymogi co do wyprzedzenia i treści dla swoich rynków u wykwalifikowanego specjalisty, zobacz Zgodność prawna. Wysyłaj je na tyle wcześnie, by klient mógł zaktualizować wygasającą kartę przed obciążeniem, co także zmniejsza liczbę nieudanych płatności.

Jak obsłużyć powiadomienie o nieudanej płatności?

Kiedy wysłać: gdy płatność za subskrypcję się nie powiedzie.

Cel: powiadomić użytkownika o nieudanej płatności i podać kroki rozwiązania.

Treść powinna zawierać:

• Co się stało
• Kwotę, która się nie powiodła
• Powód niepowodzenia (jeśli dostępny)
• Kroki do rozwiązania
• Link do aktualizacji metody płatności
• Konsekwencje, jeśli nie zostanie rozwiązane

Dobre praktyki:

• Wysyłaj natychmiast po niepowodzeniu
• Bądź jasny co do konsekwencji
• Zapewnij łatwą ścieżkę rozwiązania
• Dołącz kontakt do wsparcia

Dlaczego to ważne: nieudane płatności to główna przyczyna mimowolnego odpływu klientów. Szybki, jasny mail odzyskujący, część sekwencji „dunning”, wprost odzyskuje przychód, który w innym razie zostałby utracony przez wygasłą kartę. Typowy rytm dunningu ponawia i mailuje w dniu 0, dniu 3 i dniu 7, z ostatnim powiadomieniem przed zawieszeniem.

Projektowanie sekwencji dunningu:

Tryby awarii do obsłużenia: „miękka odmowa” (brak środków, tymczasowa) zasługuje na automatyczne ponowienia, zanim zaczniesz agresywnie mailować, podczas gdy „twarda odmowa” (karta zgłoszona jako zgubiona, konto zamknięte) nigdy nie powiedzie się przy ponowieniu i powinna od razu prosić o nową kartę. Odróżniaj je po kodzie odmowy z bramki płatniczej zamiast traktować każde niepowodzenie tak samo. Zatrzymaj sekwencję w chwili, gdy płatność się powiedzie, mail „Twoja płatność nie powiodła się” docierający po tym, jak klient już zapłacił, to niszczące zaufanie zgłoszenie do wsparcia, więc kluczuj anulowanie na tym samym ID subskrypcji/faktury. To najbardziej wrażliwy na dostarczalność mail rozliczeniowy; jeśli trafi do spamu, klient nigdy nie odzyska karty, a Ty tracisz przychód, więc kieruj go na swojej najczystszej tożsamości transakcyjnej (zobacz Dostarczalność).

Maile powiadomień i aktualizacji

Kiedy zapowiedź funkcji jest transakcyjna, a nie marketingowa?

Kiedy wysłać: gdy funkcja aktywnie używana przez użytkownika znacząco się zmienia.

Cel: powiadomić użytkowników o zmianach wpływających na korzystanie z usługi.

Treść powinna zawierać:

• Co się zmieniło
• Jak to wpływa na użytkownika
• Jakie działanie (jeśli jakieś) jest potrzebne
• Link do dalszych informacji

Dobre praktyki:

• Tylko przy znaczących zmianach
• Skup się na wpływie na użytkownika
• Zapewnij jasne kolejne kroki
• Linkuj do dokumentacji

Uwaga: ogólne zapowiedzi funkcji to maile marketingowe. Wysyłaj jako transakcyjne tylko wtedy, gdy zmiana bezpośrednio wpływa na aktywną funkcję, z której korzysta użytkownik.

Dlaczego to ważne: to najłatwiej nadużywana kategoria. Etykieta transakcyjna stosuje się tylko wtedy, gdy zmiana zmusza użytkownika do działania (wycofane API, usunięte ustawienie). „Zobacz naszą fajną nową funkcję” to marketing. Wysłanie tego jako transakcyjnego narusza zaufanie użytkownika i prawo. Prosty test: jeśli użytkownik nic nie zrobi i coś mu się zepsuje, to transakcyjne; jeśli nic się nie psuje, to marketing.

A co z powiadomieniami o aktywności, wzmiankach i podsumowaniach?

Kiedy wysłać: gdy wystąpi zdarzenie między dwiema osobami, na które użytkownik wyraził zgodę (odpowiedź, wzmianka, wiadomość bezpośrednia), lub według stałego harmonogramu dla podsumowań.

Cel: przyciągnąć użytkownika z powrotem do istotnej aktywności, o której prosił, by go powiadamiać.

Treść powinna zawierać:

• Kto co zrobił (konkretny aktor i działanie)
• Bezpośredni link do elementu
• Kontrolę preferencji / wypisu osobno dla każdego typu

Dobre praktyki:

• Grupuj i scalaj. Seria dziesięciu odpowiedzi powinna dać jeden mail, nie dziesięć.
• Respektuj ciche godziny i preferencje osobno dla każdego typu (modeluj je zgodnie z Zarządzanie listą).
• Dołączaj List-Unsubscribe i List-Unsubscribe-Post (RFC 8058) nawet do nominalnie transakcyjnych powiadomień, bo klasyfikatory operatorów skrzynek mogą traktować je jako masowe.
• Oferuj dzienne lub tygodniowe podsumowanie jako opcję o niższej częstotliwości.

Dlaczego to ważne: powiadomienia o aktywności generują więcej skarg spamowych niż jakakolwiek inna kategoria „transakcyjna”, bo użytkownicy, którzy czują się zasypani spamem, nie odróżniają Twojego powiadomienia o odpowiedzi od marketingu, naciskają przycisk skargi, a zasady dla nadawców masowych z lutego 2024 stawiają Twoją domenę w ryzyku powyżej wskaźnika skarg 0,3%. Obroną jest prawdziwa kontrola użytkownika i konserwatywne domyślne ustawienia: zapisuj się (opt-in) na powiadomienia o wysokiej częstotliwości, nie wypisuj. Wszystko, czego nie da się obronić jako między dwiema osobami, powinno w całości przejść do strumienia marketingowego.

Wymagania przekrojowe dla każdego maila w tym katalogu

Te stosują się niezależnie od kategorii. To części, o których inżynierowie najczęściej zapominają.

Uwierzytelniaj każdą domenę wysyłkową. Poczta transakcyjna wciąż musi przejść uwierzytelnianie, bo inaczej trafi do spamu niezależnie od treści. Co najmniej: SPF (RFC 7208), DKIM (RFC 6376) i DMARC (RFC 7489) z polityką, która przynajmniej monitoruje, a najlepiej egzekwuje. Przykładowe rekordy dla subdomeny transakcyjnej:

# SPF (RFC 7208), TXT pod txn.example.com; -all gdy masz pewność, że wszyscy nadawcy są wymienieni
txn.example.com.  TXT  "v=spf1 include:_spf.your-esp.example -all"

# DKIM (RFC 6376), TXT pod selektorem, który daje Ci ESP
sel1._domainkey.txn.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."

# DMARC (RFC 7489), publikowany pod domeną ORGANIZACYJNĄ, obejmuje subdomeny
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Zweryfikuj przez dig:

dig +short TXT txn.example.com
dig +short TXT sel1._domainkey.txn.example.com
dig +short TXT _dmarc.example.com

Pełna konfiguracja uwierzytelniania, w tym ARC (RFC 8617) dla przekazywanej poczty, MTA-STS (RFC 8461), TLS-RPT (RFC 8460) i BIMI dla zweryfikowanych logo, jest w Dostarczalności. SPF, DKIM i DMARC to baza dla każdego nadawcy; dodatkowe wymogi dla nadawców masowych z lutego 2024 dla Gmaila/Yahoo/Microsoft (dopasowanie DMARC, wskaźnik skarg spamowych poniżej 0,3% oraz wypis jednym kliknięciem RFC 8058 w marketingu) stają się obowiązkowe, gdy wysyłasz mniej więcej 5000 wiadomości dziennie lub więcej do jednego operatora skrzynki.

Zawsze wysyłaj alternatywę w postaci zwykłego tekstu. Każda wiadomość w tym katalogu musi zawierać część text/plain obok HTML. Maile OTP i resetu w szczególności są czytane w klientach, które usuwają HTML, a brakująca część tekstowa szkodzi ocenie spamowej.

Używaj adresu From, na który da się odpowiedzieć, tam gdzie wiadomość zaprasza do odpowiedzi. no-reply@ jest akceptowalny dla OTP i automatycznych alertów, ale maile wsparcia i kont powinny docierać do monitorowanej skrzynki. no-reply na mailu, który mówi „skontaktuj się z nami z pytaniami”, to sprzeczność, którą użytkownicy zauważają.

Idempotencja i stabilne identyfikatory. Wysyłki Warstwy 0 i Warstwy 1 muszą być idempotentne na ID wyzwalającego zdarzenia, by ponowiony webhook lub ponownie zakolejkowane zadanie nie wysłało podwójnie. Paragony, faktury i zamówienia muszą nieść stabilny, nigdy nieużywany ponownie identyfikator. Zobacz Niezawodność wysyłki.

Honoruj suppression. Nawet poczta transakcyjna musi respektować suppression dla twardych odbić (hard bounce) i skarg dla danego adresu, dalsze wysyłanie na adres, który odbija lub złożył skargę, szkodzi Twojej reputacji dla wszystkich. Model obsługi wyjątków i suppression jest w Zarządzanie listą.

Lista kontrolna wdrożenia

• Zidentyfikowano typ aplikacji i skopiowano jego listę „Niezbędne” do backlogu
• Zbudowano najpierw uniwersalną bazę: weryfikacja, reset hasła, powitanie
• Każdy mail transakcyjny jest wolny od treści promocyjnych
• Maile bezpieczeństwa i OTP są wysyłane natychmiast i odpowiednio wygasają
• Maile rozliczeniowe (potwierdzenie, odnowienie, niepowodzenie, paragon) obejmują pełny cykl życia
• Maile medyczne/wrażliwe niosą minimum PHI i linkują do bezpiecznego portalu
• Maile „zapowiedź funkcji” są transakcyjne tylko wtedy, gdy wymagane jest działanie
• Każdy mail definiuje stabilny identyfikator (numer zamówienia/faktury), gdzie to istotne
• Wysyłki Warstwy 0/Warstwy 1 są idempotentne na ID wyzwalającego zdarzenia
• Tokeny są przechowywane zahaszowane, jednorazowe i krótko żyjące; sesje są odwoływane przy resecie hasła
• Alerty bezpieczeństwa zawierają urządzenie/IP/czas/lokalizację i są wysyłane na stary + nowy adres przy zmianie e‑maila
• Subdomena wysyłkowa ma zweryfikowane przez dig SPF (RFC 7208), DKIM (RFC 6376) i DMARC (RFC 7489)
• Każdy mail zawiera alternatywę w postaci zwykłego tekstu
• Sekwencja dunningu anuluje się w chwili, gdy płatność się powiedzie
• Powiadomienia o aktywności są grupowane, kontrolowane preferencjami i niosą nagłówki wypisu RFC 8058

Co przeczytać dalej?

• Typy maili: transakcyjne vs marketingowe: fundamentalne rozróżnienie, na którym opierają się te maile
• Dostarczalność: dbanie o to, by te maile faktycznie docierały do skrzynki
• Zarządzanie listą: suppression, preferencje i modelowanie kontroli powiadomień
• Projektowanie maili transakcyjnych: jak pisać i strukturyzować maile z tego katalogu
• Maile marketingowe: gdzie należy promocyjny onboarding i sekwencje pielęgnujące
• Zgodność prawna: wymogi prawne kształtujące treść transakcyjną
• Niezawodność wysyłki: idempotencja i ponawianie, by krytyczne maile zawsze się wysyłały
• Webhooki i zdarzenia: zdarzenia nadrzędne wyzwalające wiele z tych maili
• Spis treści