Postmark, poczta transakcyjna i strumienie

Postmark, poczta transakcyjna i strumienie

Postmark to usługa do wysyłania poczty z aplikacji: potwierdzeń zamówień, przypomnień hasła, powiadomień o zdarzeniach. Wysyłasz przez interfejs programistyczny albo przez zwykły protokół pocztowy, a usługa zajmuje się dostarczeniem i raportowaniem, co się z wiadomością stało.

Wyróżnikiem jest tu jedna decyzja projektowa, która brzmi jak szczegół, a jest sednem: rozdzielenie poczty transakcyjnej od masowej na poziomie infrastruktury. Do tego wrócimy, bo to jest zarazem najczęstsze źródło problemów u osób przychodzących z innych usług.

Właściciel i co to zmieniło

Usługa została przejęta przez ActiveCampaign w 2022 roku i działa dalej jako osobny produkt, z własnym panelem i własną dokumentacją. Nie ma tu wchłonięcia ani wygaszania, jakie widać przy części przejęć.

Warto natomiast wiedzieć, że w opiniach użytkowników po tej zmianie pojawia się powtarzający się motyw dotyczący warstwy obsługi: czasu odpowiedzi wsparcia i sposobu prowadzenia spraw związanych z weryfikacją konta. To są relacje użytkowników, a nie mierzalna właściwość produktu, więc traktuj je jako sygnał do sprawdzenia, a nie jako fakt.

Sama technologia i dostarczalność pozostają w opiniach mocną stroną, i to jest zresztą główny powód, dla którego ludzie tę usługę wybierają.

Strumienie wiadomości

To jest mechanizm, który warto zrozumieć przed wysłaniem pierwszej wiadomości, bo źle użyty niweczy całą przewagę tej usługi.

Wiadomości dzielą się na dwa rodzaje. Transakcyjne wynikają z działania konkretnej osoby: zamówiła, zarejestrowała się, poprosiła o reset hasła. Marketingowe idą do listy odbiorców, którzy niczego akurat nie zrobili.

Usługa wymusza rozdzielenie ich na osobne strumienie, a każdy strumień ma własną reputację adresu wysyłkowego. Konsekwencja jest bezpośrednia: kampania, na którą część odbiorców zareagowała zgłoszeniem nadużycia, nie psuje dostarczalności potwierdzeń zamówień.

Bez tego rozdzielenia dzieje się rzecz, którą widać w wielu firmach. Newsletter wysłany do dziesięciu tysięcy osób generuje skargi, reputacja adresu spada, a tydzień później okazuje się, że przypomnienia hasła zaczęły lądować w folderze niechcianych. Nikt nie łączy tych dwóch faktów, bo dzieli je czas.

Praktyczna zasada brzmi: jeśli wiadomość idzie do więcej niż jednej osoby naraz, to nie jest transakcyjna, niezależnie od tego, jak bardzo przypomina powiadomienie. Wysyłanie masowej przez strumień transakcyjny jest tu naruszeniem zasad i najprostszą drogą do problemów.

Uwierzytelnianie domeny

Druga rzecz do zrobienia przed pierwszą wysyłką, i ta akurat dotyczy każdej usługi pocztowej, nie tylko tej.

Trzy wpisy w konfiguracji domeny decydują o tym, czy Twoja poczta w ogóle dojdzie. Pierwszy mówi, które serwery mają prawo wysyłać w imieniu domeny. Drugi dokłada podpis kryptograficzny, po którym odbiorca sprawdza, czy wiadomość nie została zmieniona. Trzeci mówi, co zrobić, gdy dwa poprzednie nie wypadną pomyślnie.

Bez pierwszych dwóch część odbiorców przyjmie wiadomość, część odrzuci, a część wrzuci do niechcianych, i będzie to zależało od dostawcy skrzynki. Bez trzeciego duzi dostawcy poczty zaostrzają traktowanie wysyłki, zwłaszcza przy większych wolumenach.

Trzeci wpis warto wprowadzać stopniowo. Zaczyna się od ustawienia mówiącego „obserwuj i raportuj", zbiera się raporty przez kilka tygodni, sprawdza, czy nic legalnego nie wypada poza uwierzytelnieniem, i dopiero potem zaostrza do odrzucania. Ustawienie odrzucania od razu potrafi zablokować wysyłkę z systemów, o których istnieniu nikt w firmie nie pamiętał.

Osobno warto ustawić domenę zwrotną, czyli adres, na który wracają informacje o niedoręczeniu. Bez tego pojawia się rozjazd między domeną widoczną dla odbiorcy a domeną techniczną, co część dostawców traktuje jako sygnał ostrzegawczy.

Wysyłka i obsługa zdarzeń

curl -X POST "https://api.postmarkapp.com/email" \
  -H "X-Postmark-Server-Token: $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "From": "powiadomienia@twojadomena.pl",
    "To": "klient@example.com",
    "Subject": "Zamowienie 4471 przyjete",
    "HtmlBody": "<p>Dziekujemy za zamowienie.</p>",
    "MessageStream": "outbound"
  }'

Pole ze strumieniem jest tu najważniejsze i najczęściej pomijane w przykładach. Jego brak oznacza użycie strumienia domyślnego, co przy poczcie marketingowej jest błędem opisanym wyżej.

W kodzie wygląda to tak samo, z jedną różnicą wartą uwagi: biblioteka nie zgłasza wyjątku przy odrzuceniu wiadomości, tylko zwraca kod błędu w odpowiedzi.

import { ServerClient } from 'postmark'

const klient = new ServerClient(process.env.POSTMARK_TOKEN!)

const wynik = await klient.sendEmail({
  From: 'powiadomienia@twojadomena.pl',
  To: klient_email,
  Subject: 'Zamowienie 4471 przyjete',
  HtmlBody: '<p>Dziekujemy za zamowienie.</p>',
  TextBody: 'Dziekujemy za zamowienie.',
  MessageStream: 'outbound'
})

if (wynik.ErrorCode !== 0) {
  log.error({ kod: wynik.ErrorCode, tresc: wynik.Message }, 'wysylka nieudana')
}

Sprawdzenie kodu błędu jest tu obowiązkowe. Wywołanie zakończone powodzeniem po stronie sieci nie oznacza, że wiadomość wyszła, a kod różny od zera niesie konkretną przyczynę: nieaktywny adres, niezweryfikowana domena albo przekroczony limit.

Zdarzenia dotyczące wiadomości wracają przez wywołania zwrotne: odbicie, zgłoszenie nadużycia, otwarcie, kliknięcie. Warto obsłużyć przynajmniej dwa pierwsze, bo to od nich zależy higiena listy odbiorców.

Odbicie twarde znaczy, że adres nie istnieje, i taki adres trzeba trwale wyłączyć z wysyłki. Ponawianie do nieistniejących adresów jest jednym z najsilniejszych sygnałów obniżających reputację. Odbicie miękkie znaczy chwilowy problem i tam ponowienie jest właściwe.

export async function POST(request: Request) {
  const zdarzenie = await request.json()

  switch (zdarzenie.RecordType) {
    case 'Bounce':
      if (zdarzenie.Type === 'HardBounce') {
        await wylaczAdresNaStale(zdarzenie.Email)
      }
      break
    case 'SpamComplaint':
      await wylaczAdresNaStale(zdarzenie.Email)
      break
  }

  return new Response(null, { status: 200 })
}

Zwrócenie kodu dwieście jest tu istotne niezależnie od tego, co zrobiłeś z treścią. Odpowiedź inna niż powodzenie sprawia, że usługa ponawia wywołanie, a przy błędzie w Twoim kodzie kończy się to lawiną powtórzeń tego samego zdarzenia.

Zgłoszenie nadużycia wymaga natychmiastowego wyłączenia adresu z wszelkiej wysyłki, także transakcyjnej, choć to bywa dyskusyjne przy potwierdzeniach zamówień. Bezpieczniej jest wyłączyć i pozwolić użytkownikowi zgłosić się samodzielnie.

Śledzenie otwarć działa przez wstawienie niewidocznego obrazka i warto wiedzieć, że jego wiarygodność spadła, odkąd część dostawców poczty pobiera obrazy zawczasu. Otwarcia raportowane przez takie skrzynki nie znaczą, że ktokolwiek przeczytał wiadomość.

Szablony i treść wiadomości

Szablony można trzymać po stronie usługi albo składać w aplikacji, i wybór ma konsekwencje, o których warto wiedzieć wcześniej.

Szablon po stronie usługi ma tę zaletę, że osoba nietechniczna zmienia treść bez wdrożenia. Wady są dwie: wypada z przeglądu kodu i z historii zmian, a przy błędzie nikt nie wie, kiedy i przez kogo został wprowadzony. Do treści zmieniającej się często to bywa właściwy kompromis, do potwierdzeń zamówień rzadziej.

Szablon w aplikacji trzyma się w repozytorium razem z resztą i przechodzi ten sam proces co kod. Przy pisaniu ich jako komponentów w Reakcie dochodzi wygoda znana z interfejsu i możliwość obejrzenia wyniku bez wysyłania czegokolwiek, co przy pracy nad wyglądem wiadomości jest różnicą między minutą a kwadransem.

Niezależnie od wyboru obowiązuje kilka zasad, które w poczcie działają inaczej niż na stronie. Układ oparty o tabele nadal jest bezpieczniejszy niż nowoczesne mechanizmy układu, bo część klientów pocztowych ich nie obsługuje. Style muszą być wpisane bezpośrednio w elementy, bo arkusze zewnętrzne bywają usuwane. Obrazy trzeba traktować jako opcjonalne, bo domyślnie nie są pobierane, a wiadomość zbudowana wyłącznie z obrazu wygląda u części odbiorców jak pusta.

Warto też zawsze dołączać wersję tekstową obok wersji z formatowaniem. Część klientów wyświetla ją zamiast bogatej, a jej brak bywa traktowany jako sygnał wysyłki masowej.

Przy szablonie trzymanym po stronie usługi wysyłka wygląda inaczej: zamiast treści przekazujesz nazwę szablonu i zestaw wartości do podstawienia.

await klient.sendEmailWithTemplate({
  From: 'powiadomienia@twojadomena.pl',
  To: klient_email,
  TemplateAlias: 'potwierdzenie-zamowienia',
  TemplateModel: {
    numer: '4471',
    kwota: '249,00 zl',
    link: 'https://sklep.pl/zamowienia/4471'
  },
  MessageStream: 'outbound'
})

Odwoływanie się do szablonu przez nazwę własną zamiast przez identyfikator liczbowy jest tu drobiazgiem o dużym znaczeniu praktycznym: nazwa przenosi się między środowiskami, a identyfikator jest inny w każdym z nich.

Testowanie i środowiska

Poczta jest jedną z niewielu rzeczy, których nie da się sensownie przetestować na produkcji, więc warto to zaplanować.

Usługa daje skrzynkę testową przyjmującą wszystko, co do niej wyślesz, i nic nie dostarczającą dalej. To jest właściwe miejsce dla środowiska deweloperskiego i testów automatycznych: kod wysyła naprawdę, więc ścieżka jest sprawdzona, a żadna wiadomość nie dociera do prawdziwego adresu.

Najgroźniejszy scenariusz przy pracy z pocztą to wysyłka do prawdziwych adresów z kopii bazy produkcyjnej. Zdarza się to regularnie, zwykle przy testowaniu nowego szablonu na danych, które ktoś skopiował „na chwilę". Zabezpieczeniem jest osobny klucz w każdym środowisku i reguła, że klucz produkcyjny nie istnieje poza produkcją.

Przy podglądach wdrożeń, na przykład tych generowanych przez Vercel dla każdej gałęzi, warto tę zasadę wpisać w konfigurację środowiska, a nie polegać na pamięci. Gałąź testowa z produkcyjnym kluczem pocztowym to jedna z tych pomyłek, których nie da się cofnąć.

Ostatnia rzecz to sprawdzenie wyglądu u różnych dostawców. Ta sama wiadomość wygląda inaczej w kilku najpopularniejszych klientach, a różnice bywają na tyle duże, że układ czytelny w jednym rozsypuje się w drugim. Narzędzia do podglądu w wielu klientach naraz oszczędzają tu sporo czasu.

Postmark kontra alternatywy

Ostatni wiersz warto rozstrzygnąć od razu, bo pytanie wraca. Postawienie własnego serwera pocztowego jest technicznie proste i operacyjnie trudne: budowanie reputacji nowego adresu trwa tygodnie, obsługa list blokujących jest pracą ciągłą, a jeden błąd konfiguracji potrafi wypisać Cię z dostarczania na miesiąc. Przy wysyłce transakcyjnej to prawie nigdy się nie opłaca.

Trzeci wiersz kusi ceną i warto wiedzieć, co się w niej mieści. Bardzo niska stawka za wiadomość idzie zwykle w parze z pulą adresów wysyłkowych dzieloną z innymi klientami, więc reputacja zależy częściowo od tego, co robią oni. Przy dużym wolumenie bierze się własny adres wysyłkowy i wtedy różnica w cenie topnieje.

Wybór między dwoma pierwszymi wierszami sprowadza się do tego, co cenisz. Jedna usługa stawia na dostarczalność i rozdzielenie ruchu, druga na wygodę pracy i szablony pisane jak komponenty. Obie robią to samo w sensie podstawowym.

Poza tabelą leży jeszcze jedno podejście, warte uwagi, jeśli rozdzielenie strumieni brzmi dla Ciebie jak zbędna praca. Loops prowadzi wysyłkę transakcyjną i sekwencje cyklu życia z jednego panelu, więc nie utrzymujesz dwóch systemów i dwóch list kontaktów. Cena idzie tam jednak za liczbę kontaktów, a nie wiadomości, co przy rzadkiej wysyłce do dużej bazy wypada drożej niż rozliczenie za wysyłkę.

Cennik i co policzyć

Rozliczenie idzie od liczby wiadomości, ale stawka nie jest jedna. Plan darmowy dla programisty daje sto wiadomości miesięcznie bezterminowo i nie dopuszcza nadwyżki, więc po wyczerpaniu puli wysyłka staje. Plany płatne startują od dziesięciu tysięcy wiadomości i różnią się nie wielkością puli, tylko ceną nadwyżki i zakresem możliwości: Basic 15 dolarów miesięcznie przy 1,80 dolara za tysiąc ponad limit, Pro 16,50 przy 1,30, Platform 18 przy 1,20. Progu pośredniego między stem a dziesięcioma tysiącami nie ma.

Na planach płatnych przekroczenie limitu niczego nie zatrzymuje. Nadwyżkę usługa zlicza na koniec okresu i dokłada do rachunku za kolejny miesiąc, więc rośnie on sam, bez żadnej decyzji z Twojej strony. W drugą stronę to nie działa: niewykorzystane wiadomości nie przechodzą na następny miesiąc.

Dwie pozycje sprawdź przed decyzją. Własny adres wysyłkowy jest dodatkiem płatnym osobno, od pięćdziesięciu dolarów miesięcznie za adres, i nie zależy od samej chęci: dostają go konta wysyłające od trzystu tysięcy wiadomości miesięcznie, na planie Pro albo wyższym. Poniżej tego progu wspólna pula jest lepsza, bo pojedynczy adres o małym ruchu buduje reputację wolniej.

Druga to okres przechowywania zdarzeń, czyli jak długo można sprawdzić, co się stało z konkretną wiadomością. Domyślnie jest to czterdzieści pięć dni na każdym planie, łącznie z darmowym, a nie przywilej droższych. Wydłużenie, w zakresie od siedmiu do trzystu sześćdziesięciu pięciu dni, to osobno płatny dodatek od pięciu dolarów miesięcznie, dostępny od planu Pro w górę. Przy obsłudze klienta to bywa ważniejsze niż cena za wiadomość, bo pytanie „czy on dostał potwierdzenie" pada codziennie.

Warto też policzyć wolumen uczciwie. Aplikacja z tysiącem użytkowników wysyła więcej, niż wynikałoby z liczby rejestracji: potwierdzenia, przypomnienia, powiadomienia o zmianach, raporty. Rachunek robi się przewidywalny dopiero po tygodniu pomiaru na produkcji.

Typowe błędy

Pierwszy to wysyłanie poczty marketingowej strumieniem transakcyjnym. Psuje reputację dokładnie tam, gdzie najbardziej zależy Ci na dostarczeniu, a skutki widać z opóźnieniem.

Drugi to brak uwierzytelnienia domeny albo ustawienie jednego wpisu z trzech. Część odbiorców przyjmie wiadomość, część odrzuci, a diagnoza jest trudna, bo zależy od dostawcy skrzynki.

Trzeci to ponawianie wysyłki na adresy odbite twardo. To jeden z najsilniejszych sygnałów obniżających reputację i najłatwiejszy do uniknięcia przez obsłużenie wywołania zwrotnego.

Czwarty to ustawienie zaostrzonej polityki uwierzytelniania od razu, bez okresu obserwacji. Blokuje wysyłkę z systemów, o których nikt nie pamiętał, na przykład ze starego narzędzia do faktur.

Piąty to traktowanie otwarć jako miary skuteczności. Część dostawców pobiera obrazy zawczasu, więc otwarcie nie znaczy, że ktoś przeczytał.

Szósty to dążenie do własnego adresu wysyłkowego przy małym wolumenie. Tutaj odcina je próg trzystu tysięcy wiadomości miesięcznie, u innych dostawców nie odcina nic, a adres o niewielkim ruchu buduje reputację wolniej niż wspólna pula i pogarsza sytuację zamiast ją poprawiać.

FAQ

Czym są strumienie wiadomości?

Rozdzieleniem poczty transakcyjnej od masowej na poziomie infrastruktury, gdzie każdy strumień ma własną reputację adresu wysyłkowego. Dzięki temu kampania generująca skargi nie psuje dostarczalności potwierdzeń zamówień i przypomnień hasła.

Czy Postmark to nadal osobny produkt?

Tak. Usługa została przejęta przez ActiveCampaign w 2022 roku i działa dalej z własnym panelem oraz dokumentacją. W opiniach użytkowników po przejęciu powtarza się motyw dotyczący warstwy obsługi, więc warto to sprawdzić samodzielnie przed dłuższym zobowiązaniem.

Co ustawić przed pierwszą wysyłką?

Trzy wpisy uwierzytelniające domenę oraz domenę zwrotną. Politykę odrzucania wprowadzaj stopniowo, zaczynając od trybu obserwacji przez kilka tygodni, bo ustawienie jej od razu potrafi zablokować wysyłkę z systemów, o których nikt w firmie nie pamiętał.

Kiedy warto wziąć własny adres wysyłkowy?

Od trzystu tysięcy wiadomości miesięcznie, bo poniżej tego progu usługa go nie wydaje, a dodatek kosztuje od pięćdziesięciu dolarów miesięcznie za adres i wymaga planu Pro albo wyższego. Wspólna pula jest wtedy lepsza, bo adres o małym ruchu buduje reputację wolniej i bywa traktowany ostrożniej przez dostawców skrzynek.

Czy da się tym wysyłać newsletter?

Tak, ale wyłącznie osobnym strumieniem przeznaczonym do wysyłki masowej. Wysyłanie kampanii strumieniem transakcyjnym narusza zasady usługi i psuje dostarczalność wiadomości, na których zależy najbardziej.

Dokumentacja stoi na stronie dla programistów, a opis strumieni w poradniku o dostarczalności.