Pozyskiwanie adresów

Pozyskiwanie adresów to moment, w którym osoba przekazuje Ci swój adres: przy rejestracji, w formularzu newslettera albo przy zakupie. Ten rozdział odpowiada na pytanie, jak zbierać adresy odpowiedzialnie, by budować czystą, zweryfikowaną listę z zebraną zgodą, zamiast takiej pełnej literówek, fałszywych adresów i kontaktów bez zgody, które odbijają się, generują skargi spamowe i po cichu niszczą reputację nadawcy. To przy pozyskiwaniu walka o reputację jest wygrywana lub przegrywana: każdy dodany adres albo Cię wzmacnia, albo osłabia.

Szybkie odpowiedzi na pytania z tego rozdziału:

• Jak zwalidować adres e‑mail (po stronie klienta i serwera)?
• Czym jest double opt‑in i kiedy używać go zamiast single opt‑in?
• Jak zaprojektować formularz, który konwertuje bez dark patterns?
• Jak zebrać ważną zgodę marketingową za pomocą checkboxów?
• Jak obsłużyć literówki, osoby już zapisane i boty?
• Jak zaprojektować mail weryfikacyjny, w który ludzie naprawdę klikają?

Zakres: ten rozdział dotyczy poprawnego wprowadzenia adresu. Podstawę prawną zbieranej tu zgody opisuje Zgodność prawna. To, co robisz z adresem później, opisują Maile marketingowe. Jak czyste pozyskiwanie chroni reputację, mówi Dostarczalność.

Dlaczego pozyskiwanie to punkt o najwyższej dźwigni w całym systemie

Wszystko poniżej pozyskiwania to ograniczanie strat. Gdy zły adres trafi już do bazy, wydajesz pieniądze na wysyłkę do niego, ryzykujesz twarde odbicie, możesz trafić w pułapkę spamową i ponosisz odpowiedzialność prawną za zapis zgody, którego nie umiesz udowodnić. Najtańsze miejsce, by nie wpuścić złego adresu, to sam formularz; drugie najtańsze to kliknięcie weryfikacyjne; wszystko po tym jest kosztowne.

Konkretnie, koszt pojedynczego złego adresu kumuluje się w całym systemie:

Liczby są poglądowe, ale kształt jest realny i spójny: im bardziej na prawo wyłapiesz zły adres, tym więcej kosztuje, a krzywa kosztu jest mniej więcej wykładnicza. Trafienie w pułapkę spamową lub utrzymujący się odsetek skarg powyżej progu Gmaila/Yahoo/Microsoftu (0,3%, obowiązujący od lutego 2024) może zdławić dostarczanie całej Twojej listy, nie tylko złego adresu. Dlatego jakość pozyskiwania nie jest opcjonalnym detalem UX; to wejście, które decyduje, czy reszta potoku w ogóle działa. Jak naprawdę degraduje się reputacja, opisuje Dostarczalność.

Cztery właściwości, które musi mieć każdy pozyskany adres

Dobry potok pozyskiwania gwarantuje cztery niezależne właściwości. Walidacja, weryfikacja i zbieranie zgody pokrywają po jednej z nich, a potrzebujesz wszystkich czterech:

1. Składniowo poprawny, ciąg jest dobrze sformowanym adresem (RFC 5322).
2. Routowalny, domena istnieje i przyjmuje pocztę (DNS + MX).
3. Należący do osoby zgłaszającej, osoba, która go wpisała, kontroluje skrzynkę (double opt‑in).
4. Z zebraną zgodą, osoba twierdząco zgodziła się na to, co będziesz wysyłać, i potrafisz to udowodnić (zebranie i przechowywanie zgody).

Częstym błędem jest mylenie tych właściwości. Kontrola MX dowodzi routowalności, nie własności. Kliknięcie potwierdzenia dowodzi własności i dostarczalności, ale nie tego, że zapisałeś dający się obronić rekord zgody. Wstępnie zaznaczony checkbox „zbiera zgodę”, ale nie spełnia właściwości 4, bo nie da się udowodnić, że została udzielona dobrowolnie. Traktuj te cztery jako checklistę, nie pojedynczy krok.

Jak zwalidować adres e‑mail?

Walidacja odpowiada na pozornie proste pytanie: czy to prawdziwy, używalny adres e‑mail? Potrzebujesz dwóch warstw i obie są obowiązkowe: walidacji po stronie klienta dla szybkiej informacji zwrotnej oraz walidacji po stronie serwera dla właściwej kontroli. Sama strona klienta nigdy nie wystarcza, a sam serwer daje gorsze doświadczenie użytkownika.

Jak powinna działać walidacja po stronie klienta?

Walidacja po stronie klienta daje użytkownikowi natychmiastową informację zwrotną, by mógł poprawić błędy przed wysłaniem. Traktuj ją jako wygodę UX, nie gwarancję bezpieczeństwa ani jakości. Każdy może ją obejść.

Zacznij od pola HTML5:

<input type="email" name="email" autocomplete="email" inputmode="email"
       spellcheck="false" autocapitalize="off" required>

To samo w sobie daje podstawową kontrolę formatu, a na mobile klawiaturę zoptymalizowaną pod e‑mail (z klawiszami @ i .). Dodatkowe atrybuty znaczą więcej, niż się wydaje:

• autocomplete="email" pozwala przeglądarce i menedżerom haseł wypełnić pole, co zarazem podnosi ukończenie i zmniejsza literówki (zapamiętany adres to poprawny adres).
• inputmode="email" wywołuje klawiaturę e‑mail nawet na polach ostylowanych jako coś innego niż type="email".
• spellcheck="false" i autocapitalize="off" powstrzymują klawiatury mobilne przed „poprawianiem” jane@acme.io na Jane@acme.io albo oznaczaniem części lokalnej jako literówki.

Następnie stosuj te dobre praktyki:

• Waliduj na blur albo z krótkim debounce. Nie pokazuj gniewnego czerwonego błędu, gdy użytkownik dopiero wpisuje pierwszy znak. Poczekaj, aż opuści pole, albo krótko (około 300 do 500 ms) po tym, jak przestanie pisać.
• Pokazuj jasne komunikaty błędów. „Wpisz poprawny adres e‑mail”, a nie „Nieprawidłowy”.
• Nie bądź zbyt restrykcyjny. Dopuszczaj nietypowe, ale poprawne formaty. Adresy mogą zawierać +, kropki i subadresowanie; zbyt agresywne regexy odrzucają prawdziwe adresy (np. user+tag@domain.com). Oficjalna gramatyka RFC 5322 jest słynnie liberalna, więc ciasny regex zawsze odrzuci kogoś prawdziwego.
• Walidacja po stronie klienta nie równa się dostarczalności. Przejście kontroli HTML5 oznacza tylko, że ciąg wygląda jak e‑mail. Nie mówi nic o tym, czy domena istnieje ani czy skrzynka przyjmuje pocztę.

Dlaczego „nie bądź zbyt restrykcyjny” ma znaczenie: najczęstszy błąd walidacji e‑maila to regex odrzucający poprawne adresy. Każdy odrzucony prawdziwy użytkownik to stracona rejestracja i skarga do wsparcia. W razie wątpliwości przyjmij i zweryfikuj (przez double opt‑in), zamiast blokować.

Pragmatyczna kontrola po stronie klienta

Nie musisz implementować RFC 5322 w JavaScripcie. Celem po stronie klienta jest wyłapać oczywiste śmieci („brak @”, „dwa @”, „kończy się kropką”), nigdy nie odrzucając wiarygodnego prawdziwego adresu. Celowo luźny regex plus sanity check „ma dokładnie jedno @ i kropkę po nim” wystarcza:

// Celowo liberalna: wyłapuje oczywiste błędy, nie odrzuca prawie żadnego prawdziwego adresu.
export function looksLikeEmail(input: string): boolean {
  const value = input.trim();
  if (value.length > 254) return false;          // RFC 5321 maks. całkowita długość
  const at = value.lastIndexOf("@");
  if (at <= 0 || at === value.length - 1) return false;
  const local = value.slice(0, at);
  const domain = value.slice(at + 1);
  if (local.length > 64) return false;            // RFC 5321 maks. długość części lokalnej
  if (!domain.includes(".")) return false;        // domena potrzebuje kropki
  if (domain.startsWith(".") || domain.endsWith(".")) return false;
  if (/\s/.test(value)) return false;             // bez spacji
  return true;
}

Oba limity liczbowe pochodzą z RFC 5321: część lokalna (przed @) jest ograniczona do 64 oktetów, a cały adres w praktyce do 254 oktetów. Egzekwowanie ich po stronie klienta jest bezpieczne, bo żaden prawdziwy adres ich nie przekracza.

Co powinna sprawdzać walidacja po stronie serwera?

Zawsze waliduj po stronie serwera. Kontrole po stronie klienta da się obejść przez wyłączony JavaScript, bezpośrednie wywołania API albo boty. Serwer to autorytatywna bramka i jedyne miejsce, gdzie walidacja naprawdę się liczy.

Sprawdź, po kolei, i zatrzymaj się na pierwszej porażce, którą traktujesz jako krytyczną:

• Format e‑maila (RFC 5322): użyj solidnego parsera, a nie naiwnego regexa.
• Znormalizuj adres: zmień domenę na małe litery (domena jest niewrażliwa na wielkość liter), przytnij białe znaki i usuń końcową kropkę. Nie zmieniaj na małe litery ani nie przepisuj części lokalnej, zgodnie z RFC 5321 część lokalna jest technicznie wrażliwa na wielkość liter, a John.Doe@example.com i john.doe@example.com mogą być różnymi skrzynkami. Większość dostawców traktuje je tak samo, ale ich przepisywanie to błąd poprawności, którego nie potrzebujesz.
• Czy domena istnieje (zapytanie DNS): czy domain.com w ogóle się rozwiązuje?
• Czy domena ma rekordy MX: czy faktycznie przyjmuje pocztę? Domena bez rekordu MX nie może odbierać maili, więc adres jest niedostarczalny. Jako rezerwa, RFC 5321 §5.1 mówi, że domena z rekordem A/AAAA, ale bez MX, może wciąż przyjmować pocztę na rekordzie A („niejawny MX”), więc traktuj „brak MX, ale jest A” jako dostarczalne, nie nieprawidłowe.
• Opcjonalnie, wykrywanie adresów jednorazowych: oznaczaj domeny tymczasowe (np. typu „poczta na 10 minut”), jeśli uzasadnia to Twój przypadek użycia.
• Opcjonalnie, wykrywanie kont rolowych: oznaczaj info@, admin@, sales@, noreply@, postmaster@ i podobne adresy współdzielone w przepływach marketingowych. Mają zwykle wielu czytelników, wyższy odsetek skarg i niejasną zgodę.

Wzorcowa kontrola MX w Node

Kontrola MX to najwartościowsza kontrola serwerowa po formacie, bo literówkowe domeny (@gmial.con) są największym pojedynczym źródłem twardych odbić. dns/promises w Node robi to bez zewnętrznej zależności:

import { promises as dns } from "node:dns";

type RoutableResult = { routable: boolean; reason?: string };

export async function isRoutableDomain(domain: string): Promise<RoutableResult> {
  const host = domain.toLowerCase().replace(/\.$/, "");
  try {
    const mx = await dns.resolveMx(host);
    // Niektóre źle skonfigurowane domeny zwracają pojedynczy "." MX, co oznacza "poczta nieprzyjmowana" (RFC 7505 null MX).
    if (mx.length === 1 && mx[0].exchange === "") {
      return { routable: false, reason: "null-mx" };
    }
    if (mx.length > 0) return { routable: true };
  } catch (err: any) {
    if (err.code !== "ENOTFOUND" && err.code !== "ENODATA") {
      // Błąd DNS (timeout, SERVFAIL), NIE traktuj jako nieprawidłowego. Przyjmij i zweryfikuj później.
      return { routable: true, reason: "dns-error-soft-accept" };
    }
  }
  // Brak MX, fallback do niejawnego MX (rekord A/AAAA) zgodnie z RFC 5321 §5.1.
  try {
    await dns.lookup(host);
    return { routable: true, reason: "implicit-mx" };
  } catch {
    return { routable: false, reason: "no-mx-no-a" };
  }
}

Dwie subtelności, które ten kod koduje, a które większość naiwnych implementacji robi źle:

• RFC 7505 „null MX”: domena, która jawnie nie przyjmuje poczty, publikuje pojedynczy rekord MX 0 . (exchange to root). Traktuj to jako niedostarczalne, nie dostarczalne.
• Miękka porażka przy błędach DNS: timeout DNS albo SERVFAIL to Twój problem, nie użytkownika. Odrzucanie rejestracji, bo Twój resolver się zaciął, to samodzielnie zadana strata konwersji. Przyjmij adres i niech double opt‑in będzie właściwym testem dostarczalności.

Zalecane narzędzia: dedykowane usługi weryfikacji adresów (np. ZeroBounce, NeverBounce, Kickbox czy Emailable) obsługują składnię, MX, kontrole domen jednorazowych, wykrywanie kont rolowych, a czasem sondowanie skrzynki na poziomie SMTP przez API. Używaj ich, gdy koszt złego adresu jest wysoki (listy „chłodnawe”, płatne pozyskiwanie) i chcesz sygnał przed pierwszą wysyłką. Dla większości konsumenckich przepływów rejestracji format + MX + double opt‑in wystarcza i unika opłaty za każdą kontrolę oraz śladu prywatnościowego z wysyłania każdego adresu do strony trzeciej.

Uwaga o weryfikacji „pingiem” SMTP. Niektóre usługi potwierdzają istnienie skrzynki, otwierając połączenie SMTP i wydając RCPT TO bez wysyłki. Jest to coraz bardziej zawodne: główni dostawcy (Gmail, Outlook) przyjmują wszystko na brzegu i odrzucają później, zwracają opóźnienia greylistingu albo limitują sondujących. Traktuj pozytywne sondowanie SMTP jako słaby sygnał, a negatywne jako nierozstrzygające, nigdy jako prawdę ostateczną. Jedynym ostatecznym dowodem, że skrzynka jest prawdziwa i należąca do osoby, jest kliknięcie linku weryfikacyjnego.

Dlaczego każda kontrola serwerowa istnieje?

Każda kontrola powstrzymuje inny rodzaj złego adresu, zanim zdąży Ci zaszkodzić:

• Format wyłapuje strukturalne śmieci, zanim trafią do bazy.
• DNS / MX wyłapuje literówkowe lub fałszywe domeny (@gmial.con), które inaczej dałyby twarde odbicie, a każde twarde odbicie szkodzi reputacji nadawcy.
• Wykrywanie jednorazówek to decyzja oceniana. Blokowanie adresów tymczasowych ogranicza nadużycia i śmieciowe rejestracje, ale może też blokować dbających o prywatność, prawowitych użytkowników. Używaj go tam, gdzie nadużycie jest realnym kosztem (np. farmienie darmowych triali), a nie odruchowo.
• Wykrywanie kont rolowych to podobnie decyzja oceniana. support@ to znakomity cel dla biznesowego potwierdzenia transakcyjnego, ale kiepski cel dla osobistego newslettera marketingowego, gdzie skarga jednego odbiorcy dotyka skrzynki czytanej przez kilka osób.

Związek z reputacją: nieprawidłowe adresy, które się prześlizgną, nie siedzą nieszkodliwie, odbijają się. Wysoki odsetek odbić mówi dostawcom skrzynek, że nie zarządzasz listą, i zaczynają kierować Cię do spamu. Utrzymuj twarde odbicia poniżej 2%, a najlepiej poniżej 1%. Walidacja przy pozyskiwaniu to Twoja pierwsza linia zapobiegania odbiciom. Patrz Dostarczalność.

Jak utrzymać wykrywanie domen jednorazowych na bieżąco?

Statyczna lista domen jednorazowych dezaktualizuje się w tygodnie; nowe domeny tymczasowe pojawiają się bez przerwy. Opcje, w rosnącej kolejności nakładu i dokładności:

• Blocklisty open source (utrzymywane społecznościowo listy tysięcy domen jednorazowych). Tanie, ale zawsze lekko z tyłu i podatne na fałszywe pozytywy, gdy lista zbyt agresywnie dołącza domenę, której używają prawdziwi użytkownicy.
• API weryfikacyjne, które utrzymuje listę za Ciebie i zwraca flagę disposable: true.
• Sygnały behawioralne zamiast dopasowywania domen, blokuj na podstawie wzorców nadużyć (wiele rejestracji z jednego IP, sekwencyjne adresy), a nie samej domeny. To wyłapuje niestandardowe konfiguracje jednorazowe, o których lista nigdy się nie dowie.

Cokolwiek wybierzesz, domyślnie zawodź otwarcie (fail open): jeśli wykrywanie jednorazówek jest niepewne, przyjmij adres i polegaj na double opt‑in oraz sygnałach zaangażowania. Błędne zablokowanie prawdziwego użytkownika jest zwykle gorsze niż wpuszczenie jednego adresu jednorazowego, który i tak nigdy nie potwierdzi.

Jakie są częste błędy walidacji adresu?

• Poleganie na skopiowanym regexie, który odrzuca +, subadresowanie albo nowe TLD.
• Walidacja tylko po stronie klienta i ufanie jej po stronie serwera.
• Robienie kontroli MX bez cache'owania wyników, przez co wolne zapytanie DNS blokuje formularz.
• Traktowanie timeoutu DNS jako „nieprawidłowego e‑maila” i odrzucanie prawdziwego użytkownika za porażkę Twojego resolvera.
• Zmienianie na małe litery lub inne przepisywanie części lokalnej i psucie skrzynek wrażliwych na wielkość liter.
• Blokowanie domen jednorazowych domyślnie i ciche tracenie prawdziwych użytkowników dbających o prywatność.
• Traktowanie zaliczonej kontroli formatu jako dowodu, że skrzynka istnieje. Nim nie jest.
• Ufanie pojedynczemu sondowaniu SMTP RCPT TO jako ostatecznemu, gdy główni dostawcy przyjmują wszystko.

Checklista walidacji

• type="email" required z autocomplete="email" i inputmode="email" na polu
• Walidacja po stronie klienta na blur / z debounce, z jasnymi komunikatami
• Walidator formatu jest liberalny (przyjmuje +, subadresowanie, nowe TLD)
• Serwerowa kontrola formatu (RFC 5322)
• Adres znormalizowany (domena na małe litery, białe znaki przycięte; część lokalna nietknięta)
• Zapytanie DNS potwierdza, że domena się rozwiązuje
• Kontrola rekordu MX potwierdza, że domena przyjmuje pocztę (z obsługą niejawnego MX i null MX)
• Błędy DNS skutkują miękkim przyjęciem, a nie odrzuceniem
• Zapytania MX cache'owane / ograniczone czasowo, by nigdy nie blokowały formularza
• Wykrywanie adresów jednorazowych rozważone dla przepływów podatnych na nadużycia, zawodzące otwarcie
• Wykrywanie kont rolowych rozważone dla przepływów marketingowych

Czym jest double opt-in?

Double opt‑in potwierdza dwie rzeczy naraz: że adres faktycznie należy do osoby go podającej oraz że skrzynka jest dostarczalna. Użytkownik dowodzi obu, klikając link w mailu potwierdzającym. Do czasu kliknięcia adres jest oczekujący i nie ma go na Twojej aktywnej liście wysyłkowej.

Jak wygląda proces double opt-in?

1. Użytkownik przesyła e‑mail przez formularz.
2. Wyślij mail weryfikacyjny z unikalnym linkiem/tokenem.
3. Użytkownik klika link.
4. Oznacz adres jako zweryfikowany.
5. Udziel dostępu / dodaj do listy.

Do kroku 4 adres jest oczekujący, jeszcze nie na Twojej aktywnej liście wysyłkowej. Nigdy nie wysyłaj marketingu na adres oczekujący.

Jak bezpiecznie generować i weryfikować token?

Token weryfikacyjny to poświadczenie na okaziciela: kto go ma, ten może potwierdzić adres. Musi być nieodgadywalny, jednorazowy i ograniczony czasowo. Dwa poprawne wzorce:

Wzorzec A, nieprzejrzysty token losowy przechowywany po stronie serwera. Wygeneruj wartość losową o wysokiej entropii, przechowuj tylko jej hash i wyszukaj ją przy kliknięciu. To najprostsze do ogarnięcia i łatwe do unieważnienia (wystarczy usunąć wiersz).

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

// Przy rejestracji:
const rawToken = randomBytes(32).toString("base64url");     // 256 bitów entropii
const tokenHash = createHash("sha256").update(rawToken).digest("hex");
// Zapisz tokenHash, email, createdAt, expiresAt, usedAt=null w bazie.
// Umieść rawToken w URL weryfikacyjnym: https://app.example.com/verify?t=<rawToken>

// Przy kliknięciu:
function verify(rawTokenFromUrl: string) {
  const hash = createHash("sha256").update(rawTokenFromUrl).digest("hex");
  // SELECT ... WHERE tokenHash = hash AND usedAt IS NULL AND expiresAt > now()
  // Jeśli znaleziono: ustaw usedAt = now(), oznacz adres jako zweryfikowany. Jednorazowość wymuszona przez usedAt.
}

Przechowuj hash, nie surowy token, by wyciek bazy nie wręczył atakującemu każdego oczekującego linku weryfikacyjnego. Surowy token żyje tylko w mailu.

Wzorzec B, podpisany bezstanowy token (HMAC). Zakoduj e‑mail i wygaśnięcie w token podpisany sekretem serwera. Sam token nie wymaga przechowywania, ale wciąż potrzebujesz rekordu po stronie serwera, by wymusić jednorazowość (token, którego nie da się unieważnić, można odtwarzać (replay), aż wygaśnie).

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

const SECRET = process.env.VERIFY_SIGNING_KEY!;  // 32+ losowych bajtów, nigdy w repo

function sign(payload: string): string {
  const mac = createHmac("sha256", SECRET).update(payload).digest("base64url");
  return `${Buffer.from(payload).toString("base64url")}.${mac}`;
}

function verifySignature(token: string): { ok: boolean; payload?: string } {
  const [body, mac] = token.split(".");
  if (!body || !mac) return { ok: false };
  const payload = Buffer.from(body, "base64url").toString();
  const expected = createHmac("sha256", SECRET).update(payload).digest("base64url");
  const a = Buffer.from(mac);
  const b = Buffer.from(expected);
  // Porównanie w stałym czasie unika wycieku ważności przez timing.
  if (a.length !== b.length || !timingSafeEqual(a, b)) return { ok: false };
  return { ok: true, payload };  // payload = `${email}|${expiresAtMs}`, wciąż sprawdź wygaśnięcie + jednorazowość
}

Niezależnie od wzorca, nienegocjowalne właściwości to: ≥128 bitów entropii (Wzorzec A) lub HMAC‑SHA256 z sekretem nigdy nieujawnionym klientowi (Wzorzec B); porównanie w stałym czasie, byś nie wyciekał ważności przez timing odpowiedzi; wymuszenie jednorazowości we własnym magazynie; oraz wygaśnięcie.

Nigdy nie umieszczaj akcji weryfikacyjnej za GET‑em, który niebezpiecznie mutuje stan, ale licz się z GET. Klienty pocztowe i skanery bezpieczeństwa pobierają linki z wyprzedzeniem. Link, który potwierdza adres na gołym GET, może zostać auto‑potwierdzony przez korporacyjny skaner linków, zanim człowiek w ogóle kliknie, fałszywy pozytyw. Złagodź to, sprawiając, że kliknięcie ląduje na stronie potwierdzenia (GET, idempotentny, pokazuje przycisk „Potwierdź”), a zmiana stanu następuje na POST przycisku, albo akceptując, że wstępne pobranie przez skaner się zdarza, i traktując adres jako potwierdzony dopiero po prawdziwej interakcji tam, gdzie stawka tego wymaga. Dla mało ryzykownych newsletterów potwierdzenie GET‑em jest zwykle akceptowalne; dla aktywacji konta preferuj stronę pośrednią.

Jakie reguły czasowe powinien spełniać krok weryfikacji?

Wyślij mail weryfikacyjny natychmiast, dodaj wygaśnięcie (24 do 48 godzin), pozwól na ponowną wysyłkę po 60 sekundach i ogranicz próby ponowienia (3 na godzinę). Odzwierciedlają one reguły maili transakcyjnych. Szczegóły projektu opisuje Maile transakcyjne.

Kiedy używać single opt-in zamiast double opt-in?

Używaj double opt‑in do wszystkich maili marketingowych. Single opt‑in stosuj tylko wtedy, gdy lista jest produktem ubocznym transakcji wyraźnie zainicjowanej przez użytkownika (tworzenia konta, złożenia zamówienia), gdzie osobny krok potwierdzenia byłby zbędnym tarciem. Tabela poniżej je porównuje.

Rekomendacja: używaj double opt‑in do wszystkich maili marketingowych.

Tabela decyzyjna, którego użyć

Powtarzający się motyw: dostarczalność adresu (weryfikacja) to osobne pytanie od tego, czy osoba zgodziła się na marketing (zebranie zgody). Możesz zweryfikować adres przy rejestracji konta, choć ta osoba nigdy nie zgodziła się na Twój newsletter. Trzymaj te dwie decyzje niezależnie. Patrz Zgodność prawna i Typy maili.

Dlaczego double opt-in jest wart tarcia?

Oczywisty zarzut brzmi: „stracimy osoby, które nie potwierdzą”. To prawda, ale osoby, które nie potwierdzają, to nieproporcjonalnie często te, które podały fałszywy adres, zrobiły literówkę albo nie były naprawdę zainteresowane. Spodziewaj się, że około 10 do 30% zgłoszeń nigdy nie potwierdzi; odfiltrowanie ich poprawia listę:

• Czystsza lista: każdy potwierdzony adres jest prawdziwy i dostarczalny, więc odsetek odbić pozostaje niski.
• Lepsze zaangażowanie: potwierdzeni subskrybenci naprawdę chcą Twoich maili, więc rosną wskaźniki otwarć/kliknięć, co dostawcy skrzynek nagradzają lepszym umiejscowieniem w skrzynce.
• Ochrona prawna: kliknięcie potwierdzenia to audytowalny dowód zgody, który wprost wspiera wymogi GDPR i CASL (patrz Zgodność prawna).
• Antynadużyciowość: powstrzymuje boty i złośliwych aktorów przed zapisywaniem innych ludzi na Twoją listę przy użyciu ich adresów (list‑bombing / subscription‑bombing).

Single opt‑in to właściwy wybór, gdy lista jest produktem ubocznym transakcji wyraźnie zainicjowanej przez użytkownika, tworzenia konta albo złożenia zamówienia, gdzie osobny krok potwierdzenia byłby zbędnym tarciem.

Co dzieje się z adresami, które nigdy nie potwierdzają?

Trzymaj je w stanie oczekującym, nie wysyłaj do nich i czyść je według harmonogramu (np. po 30 dniach). Nigdy po cichu nie aktywuj adresu oczekującego. Jeśli chcesz jedno przypomnienie, wyślij pojedynczy follow‑up przed wygaśnięciem tokenu, a potem przestań. Powtarzane ponaglanie niepotwierdzonego adresu samo w sobie jest ryzykiem spamowym.

Adres oczekujący jest obciążeniem, jeśli źle nim zarządzisz: to adres, którego nie potwierdziłeś, że możesz go kontaktować. Wysyłanie do niego więcej niż pierwotnego maila weryfikacyjnego plus jednego przypomnienia ociera się o wysyłanie poczty bez zgody. Liczy się też kąt retencji danych pod GDPR, trzymanie niepotwierdzonych adresów bez końca to dane, których nie masz podstawy prawnej zachowywać. Zaplanowane czyszczenie niepotwierdzonych rekordów oczekujących (często po 30 dniach) jest zarówno praktyką higieny dostarczalności, jak i minimalizacji danych. Patrz Zgodność prawna i Zarządzanie listą.

Jak bronić się przed subscription‑bombingiem przez mój formularz?

Atakujący używają otwartych formularzy rejestracji, by zalać skrzynkę ofiary: przesyłają jej adres do tysięcy newsletterów naraz, grzebiąc prawdziwy mail potwierdzający (powiedzmy alert o oszustwie z banku) pod szumem. Twój formularz nie może stać się bronią:

• Jeden rekord oczekujący na adres, jeśli adres ma już niewygasły token oczekujący, nie generuj nowego maila przy ponownym przesłaniu; wyślij ponownie istniejący w ramach limitu ponowień.
• Limituj na przesłany adres, nie tylko na IP. Atakujący zmienia IP; stałą jest adres ofiary.
• Limituj na IP / sesję / fingerprint, by spowolnić źródło ataku.
• CAPTCHA lub proof‑of‑work tylko, gdy wykryjesz serię, nigdy przy każdej legalnej rejestracji.
• Uczyń sam mail weryfikacyjny dającym się obronić komunikatem „nie zapisywałem się, zignoruj to”, by ofiara, która go zobaczy, wiedziała, że można go bezpiecznie odrzucić.

Checklista double opt-in

• Nowe rejestracje marketingowe startują w stanie oczekującym
• Mail weryfikacyjny wysłany natychmiast
• Token ma ≥128 bitów entropii albo jest podpisany HMAC sekretem tylko serwerowym
• Po stronie serwera przechowywany jest tylko hash tokenu (wzorzec nieprzejrzystego tokenu)
• Porównanie tokenu jest w stałym czasie
• Link/token jest jednorazowy (wymuszone we własnym magazynie)
• Token wygasa w 24 do 48 godzin
• Ponowna wysyłka po 60 s, limit 3/godz., z ponownym użyciem istniejącego rekordu oczekującego
• Uwzględnione wstępne pobranie przez skaner linków (strona pośrednia dla przepływów wysokiego ryzyka)
• Adres aktywowany dopiero po kliknięciu
• Znacznik czasu potwierdzenia + IP + URL formularza zapisane jako dowód zgody
• Niepotwierdzone rekordy oczekujące czyszczone według harmonogramu

Jak zaprojektować formularz, który konwertuje?

Formularz to miejsce, gdzie pozyskiwanie się udaje lub zawodzi. Celem jest sprawić, by prawdziwej osobie było bezwysiłkowo podać poprawny adres, zbierając przy tym uczciwą zgodę. Trzymaj go krótkim, uczyń jedno działanie oczywistym i nigdy nikogo nie podpuszczaj do zgody.

Jak powinno zachowywać się pole e‑mail?

• Użyj type="email", by urządzenia mobilne pokazały klawiaturę e‑mail (z @ i .).
• Dodaj autocomplete="email", by menedżery haseł i przeglądarki je wypełniały, adresy z autouzupełniania to poprawne adresy.
• Dołącz placeholder („you@example.com”), by zamodelować oczekiwany format, ale nigdy jako zamiennik widocznej etykiety.
• Pokazuj jasne komunikaty błędów, „Wpisz poprawny adres e‑mail”, a nie „Nieprawidłowy”.
• Wyłącz autocapitalize i spellcheck (autocapitalize="off" spellcheck="false"), by klawiatura mobilna nie „naprawiała” adresu.

Jak zebrać ważną zgodę marketingową za pomocą checkboxów?

Przy rejestracjach marketingowych zgoda musi być wyraźna i świadoma. Checkbox musi wymagać świadomego działania.

• Domyślnie odznaczone (wymagane). Wstępnie zaznaczona zgoda nie jest ważną zgodą w świetle GDPR i wszędzie jest dark patternem.
• Konkretny język o tym, na co się zapisują.
• Osobne checkboxy dla różnych typów maili. Nie pakuj „newslettera” i „promocji” w jeden ptaszek.
• Link do polityki prywatności.

<fieldset>
  <legend>Choose what you'd like to receive (optional)</legend>
  <label>
    <input type="checkbox" name="consent_newsletter" value="yes">
    Subscribe to our weekly newsletter with product updates
  </label>
  <label>
    <input type="checkbox" name="consent_promotions" value="yes">
    Send me promotional offers and deals
  </label>
  <p>
    We process your data per our
    <a href="/privacy">Privacy Policy</a>. Unsubscribe anytime.
  </p>
</fieldset>

Nie rób tego: nie zaznaczaj checkboxów z góry, nie używaj ogólnikowego języka ani nie ukrywaj zgody w regulaminie.

Dlaczego „domyślnie odznaczone” jest nienegocjowalne: w świetle GDPR zgoda musi być dobrowolnym, konkretnym, świadomym i jednoznacznym działaniem potwierdzającym. Wstępnie zaznaczony checkbox nie jest żadnym z tych, użytkownik nic nie zrobił. Poza wymogiem prawnym, zgoda wyłudzona podstępem jest bezwartościowa: tacy subskrybenci nie angażują się, oznaczają Cię jako spam i ciągną reputację w dół. Uczciwa zgoda to też lepsza zgoda. Patrz Zgodność prawna.

Jakich dark patterns musi unikać formularz zgody?

„Wolny od dark patterns” to twardy wymóg, nie preferencja stylu. Poniższe wszystkie unieważniają zgodę w UE i są szkodliwe wszędzie; unikaj każdego:

Ostatni wiersz łączy się dalej: od lutego 2024 Gmail, Yahoo i Microsoft wymagają od masowych nadawców honorowania wypisu jednym kliknięciem (RFC 8058: nagłówek List-Unsubscribe plus List-Unsubscribe-Post: List-Unsubscribe=One-Click). Przepływ pozyskiwania, który utrudnia odejście, to nie tylko dark pattern, ustawia Cię na łamanie wymogów nadawcy w dalszej części. Projektuj wyjście w tym samym czasie, gdy projektujesz wejście. Patrz Maile marketingowe i Zgodność prawna.

Jakie metadane zgody muszę zebrać i przechowywać?

Zebranie zgody nie wystarcza; musisz móc ją później udowodnić, potencjalnie lata po fakcie w odpowiedzi na regulatora lub skargę. Przechowuj niezmienny rekord zgody w momencie działania potwierdzającego:

Rekord zgody powinien być tylko do dopisywania (append‑only): gdy ktoś zmienia preferencje lub wycofuje zgodę, zapisz nowy rekord, nie nadpisuj starego. Ślad audytowy jest całym sensem. Przechowywanie dokładnego brzmienia (lub identyfikatora wersji wskazującego na nie) ma znaczenie, bo „na co użytkownik się zgodził” to pytanie, które regulatorzy faktycznie zadają, a „obecny tekst na naszym formularzu” nie jest odpowiedzią, jeśli tekst się od tego czasu zmienił.

type ConsentRecord = {
  email: string;                  // znormalizowany
  purposes: string[];             // ["newsletter", "promotions"]
  grantedAt: string;              // ISO 8601 UTC
  source: string;                 // np. "https://example.com/blog/post-x#footer-form"
  ip: string;
  userAgent: string;
  wordingVersion: string;         // np. "consent-copy-2026-03"
  method: "checkbox" | "double-opt-in" | "import-reconsent";
  doubleOptInConfirmedAt?: string;
  doubleOptInConfirmIp?: string;
};

Jak rozłożyć formularz?

• Trzymaj go prostym i skupionym. Każde dodatkowe pole obniża ukończenie, więc proś tylko o to, czego potrzebujesz.
• Jedno działanie główne: jeden, oczywisty przycisk wysyłki.
• Jasna propozycja wartości: powiedz użytkownikowi, co dostaje i jak często.
• Przyjazny mobile: duże obszary dotyku (≥44×44 px), żadnych maleńkich pól.
• Dostępny: prawdziwe <label> powiązane z polami, ARIA gdzie trzeba, obsługa klawiatury i błędy ogłaszane czytnikom ekranu (aria-live, aria-describedby łączące pole z tekstem błędu).

Jak zatrzymać boty bez szkodzenia prawdziwym użytkownikom?

Boty zaśmiecają listę śmieciami i mogą wywołać subscription‑bombing. Broń się warstwami, najtaniej i najmniej inwazyjnie w pierwszej kolejności:

1. Pole honeypot, ukryte pole, którego prawdziwi użytkownicy nigdy nie wypełniają; każde zgłoszenie, które je wypełnia, to bot. Zero tarcia, łapie naiwne boty.
2. Kontrola czasu do wysłania, formularz wysłany w poniżej ~1 sekundy był prawie na pewno zeskryptowany.
3. Kontrola pochodzenia / tokenu, wymagaj wydanego przez serwer tokenu formularza (zarazem ochrona CSRF), by ślepe POST‑y do Twojego endpointu zawodziły.
4. Niewidoczna / oparta na ryzyku CAPTCHA, eskaluj do widocznego wyzwania tylko, gdy wcześniejsze sygnały wyglądają podejrzanie.

<!-- Honeypot: wizualnie ukryty, poza ekranem, aria-hidden. Prawdziwi użytkownicy nigdy go nie widzą ani nie wypełniają. -->
<div aria-hidden="true" style="position:absolute; left:-9999px;">
  <label>Leave this field blank
    <input type="text" name="website" tabindex="-1" autocomplete="off">
  </label>
</div>

Zarezerwuj widoczną CAPTCHA na zaobserwowane nadużycia. Widoczne wyzwanie przy każdej rejestracji wymiernie obniża konwersję i tworzy bariery dostępności (może być twardą blokadą dla użytkowników z niepełnosprawnością wzroku lub ruchu), więc powinno być ostatecznością, nie pierwszym krokiem.

Jakie są częste błędy projektu formularza?

• Pytanie o imię, firmę i telefon, gdy potrzebujesz tylko adresu.
• Wstępnie zaznaczony lub spakowany checkbox zgody, który łamie GDPR i rodzi skargi.
• Którykolwiek z dark patterns z tabeli powyżej (confirmshaming, asymetryczne przyciski, zgoda przez kontynuowanie).
• Ogólnikowa propozycja wartości („Dołącz do listy”) bez obietnicy częstotliwości ani treści.
• Maleńkie obszary dotyku albo przycisk wysyłki ukryty pod zgięciem na mobile.
• Tekst placeholdera użyty jako jedyna etykieta, co psuje czytniki ekranu i znika przy fokusie.
• Zbieranie zgody bez przechowywania metadanych, co uniemożliwia jej późniejsze udowodnienie.
• Widoczna CAPTCHA przy każdej rejestracji, dławiąca konwersję i wykluczająca osoby z niepełnosprawnością.

Checklista projektu formularza

• type="email" z autocomplete="email", inputmode="email" i realistycznym placeholderem
• Widoczna <label> dla pola (placeholder nie jest etykietą)
• Jeden skupiony formularz, jedno działanie główne
• Podana propozycja wartości („co tydzień”, „aktualizacje produktu”)
• Marketingowe checkboxy zgody domyślnie odznaczone
• Osobne checkboxy dla każdego typu maili
• Polityka prywatności podlinkowana przy zgodzie
• Brak wstępnie zaznaczonych checkboxów, brak ogólnikowej lub zakopanej zgody, brak confirmshamingu, brak asymetrycznych przycisków
• Pełne metadane zgody zebrane (znacznik czasu, IP, UA, źródło, wersja brzmienia)
• Honeypot + czas do wysłania + token CSRF; CAPTCHA tylko przy zaobserwowanych nadużyciach
• Etykiety powiązane z polami; błędy ogłaszane przez aria-live; dostępny dla klawiatury i czytników ekranu
• Obszary dotyku ≥44×44 px

Jak obsłużyć błędy pozyskiwania i nadużycia?

Formularze pozyskiwania spotykają wiele przypadków brzegowych: literówki, osoby już na liście i boty. Dobre obsłużenie każdego poprawia zarówno konwersję, jak i bezpieczeństwo, więc traktuj obsługę błędów jako część produktu, a nie dodatek na później.

Co zrobić, gdy e‑mail jest nieprawidłowy?

• Pokaż jasny komunikat błędu przy polu.
• Sugeruj poprawki częstych literówek: @gmial.com na @gmail.com, @hotmial.com na @hotmail.com, @gmail.con na @gmail.com. Podpowiedź „Czy chodziło o…?” odzyskuje użytkowników, którzy inaczej by się odbili lub poddali.
• Pozwól poprawić i wysłać ponownie bez ponownego wpisywania wszystkiego.

Dlaczego sugestie literówek się opłacają: duża część twardych odbić to zwykłe literówki w popularnych domenach. Wyłapanie ich na formularzu, zanim w ogóle trafią na listę, całkowicie zapobiega odbiciu i ratuje rejestrację. To jeden z elementów UX pozyskiwania o najwyższym zwrocie.

Jak działa sugerowanie literówek

Standardowe podejście liczy odległość edycyjną (Levenshtein / Damerau‑Levenshtein) między wpisaną domeną a listą popularnych domen i TLD, i sugeruje najbliższe dopasowanie w małym progu. Biblioteki open source jak mailcheck implementują dokładnie to. Kluczowe reguły:

• Sugeruj, nigdy nie auto‑poprawiaj. Ciche zastąpienie @gmail.con na @gmail.com jest złe, jeśli użytkownik naprawdę miał na myśli niszową domenę bliską .con (rzadkie, ale auto‑poprawa odbiera mu możliwość nadpisania). Pokaż „Czy chodziło o you@gmail.com?” jako akceptację jednym dotknięciem.
• Pokryj zarówno domenę, jak i TLD, gmial.com (literówka w domenie) i gmail.con (literówka w TLD) to różne klasy błędów.
• Trzymaj listę popularnych domen krótką i o dużym ruchu (gmail.com, yahoo.com, outlook.com, hotmail.com, icloud.com, plus więksi dostawcy Twojego regionu). Długa lista zwiększa fałszywe sugestie.

// Szkic: sugeruj poprawkę tylko, gdy wpisana domena jest o jedną edycję od znanej.
// Użyj Damerau-Levenshtein, by transpozycja (gmial.com -> gmail.com) liczyła się jako jedna edycja;
// zwykły Levenshtein punktuje tę zamianę jako odległość 2 i by ją przeoczył.
const POPULAR = ["gmail.com", "yahoo.com", "outlook.com", "hotmail.com", "icloud.com"];

function suggestDomain(domain: string): string | null {
  const d = domain.toLowerCase();
  if (POPULAR.includes(d)) return null;            // już poprawna
  for (const candidate of POPULAR) {
    if (damerauLevenshtein(d, candidate) === 1) return candidate;  // o jedną literówkę/transpozycję
  }
  return null;
}

Co pokazać, gdy e‑mail jest już zarejestrowany?

• Konta: „Ten e‑mail jest już zarejestrowany. [Zaloguj się]”
• Marketing: „Już jesteś zapisany! [Zarządzaj preferencjami]”
• Nie ujawniaj, czy konto istnieje w przepływach wrażliwych pod kątem bezpieczeństwa.

Napięcie bezpieczeństwa: powiedzenie atakującemu „ten e‑mail jest już zarejestrowany” potwierdza istnienie konta (enumeracja kont). W przepływach logowania/rejestracji preferuj neutralną odpowiedź („Jeśli ten e‑mail nie jest jeszcze zarejestrowany, wysłaliśmy potwierdzenie”) i dostarcz konkretny komunikat mailem. Dla mało wrażliwego newslettera przyjazne „już jesteś zapisany” zwykle jest w porządku. Dopasuj rygor do wrażliwości.

Ponowny zapis i przypadek ponownej zgody

Subtelny przypadek: ktoś, kto wcześniej się wypisał (lub został wyciszony za odbicia), ponownie wysyła formularz. Nie dodawaj go po cichu z powrotem.

• Jeśli się wypisał, traktuj nowe zgłoszenie jako świeży, świadomy opt‑in, przeprowadź go ponownie przez double opt‑in i zapisz nowy rekord zgody. Jego wcześniejszy wypis to wycofanie, które musisz honorować, dopóki nie wyrazi zgody ponownie jawnie.
• Jeśli jest na liście wyciszeń za twarde odbicia, świeże, poprawnie wyglądające zgłoszenie tego samego adresu może wyczyścić wyciszenie dopiero po udanym kliknięciu weryfikacyjnym, które dowodzi, że skrzynka jest teraz dostarczalna. Nigdy automatycznie nie usuwaj adresu z wyciszeń tylko dlatego, że ktoś znów go wpisał.

To ma znaczenie zarówno dla dostarczalności, jak i zgodności prawnej: ponowna wysyłka do wcześniej wypisanego adresu bez nowej zgody to magnes na skargi i, zależnie od jurysdykcji, bezprawie. Patrz Zarządzanie listą i Zgodność prawna.

Jak ograniczyć liczbę zgłoszeń (rate limiting), by zatrzymać nadużycia?

• Ogranicz maile weryfikacyjne: 3 na godzinę na adres. Powstrzymuje atakujących przed użyciem Twojego formularza do spamowania osoby trzeciej (i chroni reputację).
• Ograniczaj wysyłki formularza ogólnie (na IP, na sesję, na fingerprint).
• Używaj CAPTCHA oszczędnie: tylko gdy faktycznie widzisz nadużycia; szkodzi konwersji i dostępności.
• Monitoruj wzorce nadużyć: serie rejestracji, kolejne adresy po sobie, zalewy z jednego IP, rejestracje z zakresów IP centrów danych.

Warstwowy projekt rate limitingu

Skuteczne limitowanie używa kilku kluczy naraz, bo każdy broni przed innym atakiem:

Implementuj je licznikiem typu sliding‑window lub token‑bucket w szybkim magazynie (np. Redis). Gdy limit zaskoczy, preferuj miękką odpowiedź, „Spróbuj ponownie za chwilę” albo CAPTCHA, zamiast twardego bana, bo fałszywe pozytywy uderzają w prawdziwych użytkowników. Loguj każde zaskoczenie, byś mógł stroić pułapy względem realnego ruchu, a nie zgadywanek.

Jak po pozyskaniu odróżnić prawdziwe odbicie od sygnału nadużycia?

Niektóre złe adresy ujawniają się dopiero po wysyłce weryfikacyjnej. Połącz webhooki odbić/skarg z powrotem do pozyskiwania, by formularz się uczył:

• Mail weryfikacyjny, który twardo odbija, oznacza, że walidacja przeszła, ale skrzynka jest martwa, przekaż ten wzorzec domeny z powrotem do monitoringu.
• Skok skarg akurat na maile weryfikacyjne sugeruje subscription‑bombing (ofiary oznaczające niechciane potwierdzenie jako spam), zacieśnij limity na adres.
• Powtarzające się miękkie odbicia, a potem twarde odbicie na tym samym adresie to normalny cykl życia, nie nadużycie.

Podłączenie tych sygnałów wymaga konsumowania zdarzeń webhook Twojego dostawcy. Model zdarzeń i ich weryfikację opisują Webhooki i zdarzenia, a obsługę ponowień i odbić, Niezawodność wysyłki.

Checklista obsługi błędów

• Komunikaty błędów na poziomie pola, czytelne dla człowieka, ogłaszane czytnikom ekranu
• Sugestie literówek „Czy chodziło o…?” dla popularnych domen i TLD (sugeruj, nie auto‑poprawiaj)
• Ponowne wysłanie bez ponownego wpisywania wszystkich pól
• Neutralne, nieenumerujące odpowiedzi w przepływach wrażliwych
• Wcześniej wypisane adresy przeprowadzane przez świeży double opt‑in, nie dodawane po cichu z powrotem
• Wyciszone (odbite) adresy czyszczone dopiero po udanym kliknięciu weryfikacyjnym
• Maile weryfikacyjne ograniczone do 3/godz. na adres
• Wysyłki formularza ograniczane na IP / sesję / fingerprint
• CAPTCHA tylko gdy zaobserwowano nadużycia
• Wzorce rejestracji monitorowane pod kątem nadużyć; webhooki odbić/skarg przekazywane z powrotem do pozyskiwania

Jak zaprojektować mail weryfikacyjny, w który ludzie naprawdę klikają?

Mail weryfikacyjny to mailowa połowa double opt‑in. Ponieważ cała rejestracja zależy od kliknięcia w niego przez użytkownika, musi być jasny, szybki i godny zaufania. Wysyłaj go natychmiast, od zaufanego nadawcy, z jednym oczywistym działaniem.

Co powinien zawierać mail weryfikacyjny?

• Jasny cel: „Verify your email address”.
• Wyróżniony przycisk weryfikacji.
• Czas wygaśnięcia: podaj, kiedy link przestaje działać.
• Awaryjny link tekstowy pod przyciskiem, na wypadek gdyby przycisk się nie wyrenderował.
• Opcja ponownej wysyłki.
• Komunikat „I didn't request this” by ktoś zapisany wbrew woli mógł zrezygnować (i by ofiara subscription‑bombingu wiedziała, że wiadomość można bezpiecznie zignorować).
• Nie umieszczaj kodów OTP/2FA w temacie ani w tekście podglądu. Zniechęca to do otwarcia (użytkownik czuje się załatwiony bez otwierania) i odsłania kod w podglądach powiadomień.

Jak powinien być zaprojektowany mail weryfikacyjny?

• Przyjazny mobile: większość kliknięć weryfikacyjnych dzieje się na telefonie.
• Duży, dotykalny przycisk (≥44 px wysokości).
• Jasne wezwanie do działania.

Szczegółowe wskazówki projektowe opisuje Maile transakcyjne. Maile weryfikacyjne kierują się dokładnie tymi samymi regułami projektu (tematy, pre-header, układ mobile-first, prezentacja kodów/linków, obsługa błędów).

Jaką autentykację musi przejść mail weryfikacyjny?

Mail weryfikacyjny, który ląduje w spamie, niweczy cały przepływ pozyskiwania, użytkownik już zdecydował się dołączyć, a Ty tracisz go na ostatnim kroku. Ponieważ to wiadomość o najwyższej stawce w lejku, musi czysto przejść autentykację:

• SPF (RFC 7208), Twoje IP wysyłające jest autoryzowane dla domeny envelope‑from.
• DKIM (RFC 6376), wiadomość jest kryptograficznie podpisana i niezmodyfikowana w tranzycie.
• DMARC (RFC 7489), opublikowana polityka dopasowuje (align) SPF/DKIM do widocznej domeny From: i mówi odbiorcom, co robić przy porażce.

Dla nadawców o dużym wolumenie lutowe 2024 wymogi Gmaila/Yahoo/Microsoftu czynią to nieopcjonalnym: masowi nadawcy muszą autentykować się SPF i DKIM, publikować DMARC, utrzymywać odsetek skarg spamowych poniżej 0,3% i wspierać wypis jednym kliknięciem na poczcie marketingowej (RFC 8058). Mail weryfikacyjny jest transakcyjny i nie podlega wymogowi wypisu, ale wciąż musi przejść SPF/DKIM/DMARC, by trafić do skrzynki. Sąsiednie standardy warte wdrożenia w miarę dojrzewania programu: ARC (RFC 8617) do zachowania wyników autentykacji przez forwardery, MTA-STS (RFC 8461) i TLS-RPT (RFC 8460) do egzekwowania i raportowania TLS oraz BIMI do wyświetlania logo, gdy DMARC jest w trybie egzekwowania. Pełna konfiguracja autentykacji, z gotowymi do wklejenia rekordami DNS, znajduje się w Dostarczalność.

Minimalne rekordy DNS, jako ilustracja (Twój dostawca podaje dokładny selektor i wartości):

; SPF, autoryzuj infrastrukturę wysyłkową Twojego dostawcy (RFC 7208)
example.com.            IN TXT  "v=spf1 include:_spf.your-provider.example -all"

; DKIM, klucz publiczny, którym podpisuje Twój dostawca (RFC 6376); selektor różni się per dostawca
prov1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

; DMARC, zacznij od p=none, by monitorować, potem przejdź do quarantine/reject (RFC 7489)
_dmarc.example.com.     IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

# Zweryfikuj, że każdy rekord się rozwiązuje, zanim zaufasz wysyłce weryfikacyjnej:
dig +short TXT example.com                       # oczekuj linii v=spf1
dig +short TXT prov1._domainkey.example.com      # oczekuj klucza v=DKIM1
dig +short TXT _dmarc.example.com                # oczekuj polityki v=DMARC1

Dlaczego maile weryfikacyjne zasługują na szczególną dbałość?

To mail, na którym wisi cała rejestracja. Jeśli wyląduje w spamie, wygląda jak phishing albo ma trudny do trafienia przycisk, użytkownik nigdy nie potwierdzi, i tracisz go po tym, jak już zdecydował się dołączyć. Traktuj go jak wysokopriorytetowy mail transakcyjny: wysyłaj natychmiast, od zaufanego nadawcy, z jednym oczywistym działaniem.

Jak wysyłać mail weryfikacyjny niezależnie od dostawcy?

Trzymaj wysyłkę za cienką abstrakcją, by logika pozyskiwania nigdy nie zależała od konkretnego ESP. Każdy z Amazon SES, Postmark, SendGrid, Mailgun, Resend, Brevo, SparkPost czy Mandrill może siedzieć za tym samym interfejsem; zmiana dostawcy nie powinna ruszać Twojego kodu pozyskiwania.

// Interfejs niezależny od dostawcy, zaimplementuj raz per dostawca, wołaj wszędzie.
interface EmailClient {
  send(message: {
    to: string;
    subject: string;
    html: string;
    text: string;          // zawsze dołącz część tekstową (plain-text)
    headers?: Record<string, string>;
  }): Promise<{ id: string }>;
}

async function sendVerificationEmail(
  emailClient: EmailClient,
  to: string,
  verifyUrl: string,
): Promise<void> {
  await emailClient.send({
    to,
    subject: "Verify your email address",
    html: `<p>Confirm your address to finish signing up.</p>
           <p><a href="${verifyUrl}">Verify email</a></p>
           <p>Or paste this link: ${verifyUrl}</p>
           <p>This link expires in 24 hours. If you didn't sign up, ignore this email.</p>`,
    text: `Confirm your address to finish signing up.\n\n${verifyUrl}\n\n` +
          `This link expires in 24 hours. If you didn't sign up, ignore this email.`,
  });
}

Interfejs EmailClient to szew: implementacja SES, implementacja Postmark i tak dalej wszystkie go spełniają, a Twój kod pozyskiwania widzi tylko interfejs. To ten sam wzorzec używany w całym przewodniku do wysyłek i do Webhooki i zdarzenia, polegaj na standardowym kontrakcie (surowy SMTP, schemat Standard Webhooks, crypto w Node), nigdy na powierzchni SDK dostawcy.

Checklista maila weryfikacyjnego

• Temat jasno mówi „Verify your email” (bez kodów w nim)
• Jeden wyróżniony przycisk weryfikacji, nad zgięciem na mobile, ≥44 px wysokości
• Wygaśnięcie podane przy przycisku
• Awaryjny link tekstowy pod przyciskiem
• Alternatywna część tekstowa (plain-text) dołączona do wiadomości
• Dostępna opcja ponownej wysyłki
• Komunikat „nie prosiłem o to” ze sposobem rezygnacji
• Wysłany natychmiast od zaufanego, spójnego nadawcy
• Przechodzi dopasowanie (alignment) SPF (RFC 7208), DKIM (RFC 6376) i DMARC (RFC 7489)
• Wysłany przez abstrakcję niezależną od dostawcy, nie przez SDK związane z jednym vendorem
• Dobrze renderuje się na mobile i w trybie ciemnym

Częste błędy w całym przepływie pozyskiwania

Skonsolidowana lista trybów awarii, przed którymi ostrzega ten rozdział, do szybkiego przeglądu:

• Ufanie walidacji po stronie klienta. To tylko UX; serwer to bramka.
• Zbyt restrykcyjne regexy, które odrzucają +, subadresowanie albo nowe TLD i po cichu tracą prawdziwych użytkowników.
• Odrzucanie przy błędach DNS zamiast miękkiego przyjęcia i pozwolenia, by zadecydowała weryfikacja.
• Brak double opt‑in w marketingu, przez co lista zapełnia się literówkami, fałszywkami i kontaktami bez zgody.
• Przechowywanie surowych tokenów weryfikacyjnych zamiast ich hashy, zamieniając wyciek bazy w masowe przejęcie kont.
• Porównanie tokenu nie w stałym czasie, wyciekające ważność przez timing.
• Wstępnie zaznaczona, spakowana lub zakopana zgoda, która jest prawnie nieważna i operacyjnie bezwartościowa.
• Zbieranie zgody bez przechowywania metadanych do jej późniejszego udowodnienia.
• Formularze umożliwiające subscription‑bombing, bo limitują na IP, ale nie na przesłany adres.
• Ciche dodawanie z powrotem wypisanych lub wyciszonych adresów przy ponownym zgłoszeniu.
• Mail weryfikacyjny, który nie przechodzi autentykacji i ląduje w spamie, tracąc użytkowników na ostatnim kroku.
• Sprzęganie kodu pozyskiwania z SDK jednego ESP zamiast z interfejsem niezależnym od dostawcy.

Co przeczytać dalej?

• Maile transakcyjne: reguły projektu maili weryfikacyjnych (temat, układ, kody, błędy)
• Zgodność prawna: wymogi prawne zgody (GDPR, CASL) i przechowywanie rekordów zgody
• Maile marketingowe: co dzieje się po pozyskaniu, w tym wypis jednym kliknięciem (RFC 8058)
• Dostarczalność: konfiguracja SPF/DKIM/DMARC oraz jak walidacja i double opt‑in poprawiają reputację nadawcy
• Zarządzanie listą: utrzymywanie pozyskanej listy w czystości, wyciszenia i obsługa ponownego zapisu
• Niezawodność wysyłki: ponowienia, obsługa odbić i kolejkowanie wysyłki weryfikacyjnej
• Webhooki i zdarzenia: konsumowanie zdarzeń odbić/skarg i przekazywanie ich z powrotem do pozyskiwania
• Typy maili: transakcyjne vs marketingowe: który przepływ pozyskiwania wymaga jakiej zgody
• Spis treści