Blazalek.com

Jak diagnozować awarię e-maili transakcyjnych

Na tej stronie

Awaria e-maili transakcyjnych to błąd, opóźnienie lub niebezpieczny duplikat wiadomości wywołanej zdarzeniem użytkownika albo biznesowym, na przykład resetem hasła, OTP, rejestracją, weryfikacją logowania lub potwierdzeniem zamówienia. Traktuj akceptację przez API jako próbę, a nie dowód przekazania do serwera pocztowego odbiorcy, i najpierw wyodrębnij proces, którego dotyczy problem.

Widoczne objawy

  • Użytkownicy nie otrzymują e-maili z resetem hasła, rejestracją lub weryfikacją logowania.
  • Link resetu albo OTP dociera po upływie skonfigurowanego czasu ważności.
  • Klienci otrzymują zduplikowane wiadomości z potwierdzeniem zamówienia.
  • API wysyłki zwraca sukces, ale wiadomość nie jest widoczna u odbiorcy.
  • Problem dotyczy tylko jednego procesu transakcyjnego, środowiska, integracji dostawcy albo segmentu odbiorców.

Grupy przyczyn

Wyzwalacz aplikacji, kolejka i kontrola ponowień

  • Aplikacja może nie utworzyć zamierzonej wiadomości albo worker może przetworzyć to samo zdarzenie więcej niż raz.
  • Ponowienie bez stabilnego klucza logicznego może stworzyć duplikat, a ponowna wysyłka bez diagnozy może ukryć pierwotną ścieżkę błędu.

Akceptacja przez dostawcę i dalsze dostarczanie

  • Dostawca może przyjąć żądanie, a mimo to wiadomość później nie powiedzie się, zostanie opóźniona, zostanie wykluczona albo nie dotrze do serwera pocztowego odbiorcy.
  • Wykluczenie konkretnego odbiorcy, tymczasowy stan serwera odbiorcy i konfiguracja dostawcy mogą dotyczyć jednego adresu lub strumienia i nie dowodzą awarii całej usługi.

Uwierzytelnianie o krótkim oknie ważności i granice środowiska

  • Prawidłowy token albo OTP może stać się bezużyteczny, gdy opóźnienie od żądania do dostarczenia przekroczy czas życia skonfigurowany w aplikacji.
  • Ścieżki stagingu, domyślnego SMTP, zarządzanej poczty i podłączonego dostawcy mogą mieć inne zasady autoryzacji odbiorcy, limity, wymagania domenowe i logi.

Pierwsze bezpieczne kontrole

  1. Nazwij dokładny proces, środowisko, integrację dostawcy, domenę odbiorcy i okno czasowe; testuj osobno rejestrację, reset i weryfikację.
  2. Prześledź jeden identyfikator korelacyjny od wyzwalacza i utworzenia tokenu przez dodanie do kolejki, żądanie do dostawcy, zdarzenie dostawcy i przekazanie do serwera odbiorcy.
  3. Przed ponowną wysyłką ustal, czy wcześniejsza próba jest w kolejce, opóźniona, dostarczona, wykluczona, nieudana albo już ponowiona.
  4. Przy resetach i OTP porównaj zmierzone opóźnienie od żądania do dostarczenia ze skonfigurowanym wygaśnięciem; nie zakładaj, że domyślna wartość dostawcy jest polityką aplikacji.
  5. Ogranicz tylko niebezpieczną ścieżkę: wstrzymaj automatyczne ponowienia bez diagnozy albo workera tworzącego duplikaty, a nie niepowiązaną pocztę transakcyjną.

Zasady rozwiązania

  • Napraw ostatni potwierdzony punkt, w którym wystąpił błąd, zamiast traktować sukces API, jedną skrzynkę albo jedno zdarzenie dostawcy jako dowód całej ścieżki.
  • Nadaj każdemu zdarzeniu biznesowemu jedną stabilną granicę idempotencji i zadbaj, by konsumenci zachowywali się bezpiecznie przy wielokrotnym dostarczeniu zdarzenia.
  • Dopasuj budżet ponowień i dostarczania do faktycznego okna użyteczności wiadomości, szczególnie linków resetu i kodów jednorazowych.
  • Monitoruj końcowe wyniki dostarczenia, odbicia, zgłoszenia spamu, opóźnienia i wykluczenia niezależnie od akceptacji wysyłki, z podziałem na proces i środowisko.
  • Potwierdź naprawę kontrolowanym testem, który osiąga oczekiwany dalszy stan bez utworzenia duplikatu wiadomości dla klienta.

Wybierz runbook

Wybierz zaobserwowany tryb awarii. Poniższe ścieżki zachowują rozróżnienie między wyzwalaczem, akceptacją przez dostawcę, wynikiem dostarczania i przekazaniem do serwera odbiorcy.

Macierz diagnostyczna

ObjawObszarPierwsza kontrola
Brakuje e-maila z resetem hasłaŻądanie resetu, token, kolejka i zdarzenia dostawcyZanim ponowisz wysyłkę, prześledź jeden wewnętrzny identyfikator żądania od utworzenia tokenu do ostatniego zdarzenia dostawcy.
E-mail resetu dociera po wygaśnięciu linkuOpóźnienie od żądania do dostarczenia i czas życia resetuPorównaj zmierzone opóźnienie end-to-end ze skonfigurowanym czasem życia tokenu resetu i budżetem ponowień.
Wysyłane są zduplikowane potwierdzenia zamówieńPowtórzenie zdarzenia i granica idempotencjiDopasuj duplikaty do tego samego zdarzenia zamówienia i zatrzymaj niekontrolowane ponowienia podczas sprawdzania kluczy oraz konsumentów.
Nieznany zakres awarii e-maili kontaRejestracja a reset hasłaUruchom osobne kontrolowane wywołania rejestracji i resetu oraz porównaj ich stany u dostawcy.
Lovable przestał wysyłać e-maile transakcyjneKonfiguracja zarządzanej poczty a konektoraUstal aktywną ścieżkę wysyłki, zanim sprawdzisz jej powiązanie, poświadczenia, domenę albo limity.
OTP albo e-mail weryfikacyjny jest opóźnionyOpóźnienie u dostawcy i przekazanie do serwera odbiorcyPorównaj znaczniki czasu akceptacji, wysłania, opóźnienia i dostarczenia z czasem wygaśnięcia skonfigurowanym w projekcie.
Brakuje e-maila z weryfikacją logowania SalesforceNadawca i ślad dostarczenia właściwy dla SalesforcePotwierdź rodzaj wiadomości, potem sprawdź Salesforce Email Log Files oraz historię weryfikacji przed żądaniem kolejnego kodu.
Brakuje jednego potwierdzenia zamówieniaWyzwalacz zamówienia, wstrzymanie i ślad dostarczeniaDopasuj zdarzenie zamówienia do stanów wysłania i dostarczenia, a zanim ponowisz wysyłkę, ustal, czy odbiorca jest wykluczony.
Wywołanie OTP na stagingu zgłasza sukces bez e-mailaAutoryzacja SMTP stagingu, limity i zdarzeniaPotwierdź odbiorcę testowego i konfigurację SMTP, sprawdź odpowiedzi o limitach, a następnie prześledź dalsze zdarzenia.
Dostarczanie transakcyjne jest stale zawodneProjekt usługi, monitorowanie końcowych wyników i bezpieczeństwo ponowieńOddziel akceptację API od wyników końcowych i potwierdź kontrakt idempotencji wdrożonego dostawcy.

Zacznij od jednej kontrolowanej wiadomości i jej identyfikatora korelacyjnego. Nie ponawiaj wysyłki wiadomości o krótkim oknie ważności ani skierowanej do klienta, dopóki nie wiesz, czy pierwotna próba jest nadal w toku, opóźniona, dostarczona czy zduplikowana.

Dlaczego użytkownicy nie otrzymują e-maili z resetem hasła?

Poziom ważności: KrytycznyWstrzymanie wysyłki: Wstrzymaj warunkowo

Zanim uruchomisz kontrolowaną ponowną wysyłkę, prześledź jeden wewnętrzny identyfikator żądania — od utworzenia tokenu po zdarzenie końcowe u dostawcy. Awaria e-maila jako niezależnego kanału odzyskiwania (out-of-band) może zablokować odzyskanie konta, jeśli użytkownik nie ma alternatywnej metody. Nazwy zdarzeń u dostawców i styki między systemami bywają różne, więc zlokalizuj ostatni potwierdzony etap, zanim przypiszesz przyczynę.

Pierwsze 15 minut

  1. Skoreluj wewnętrzny identyfikator żądania przez wszystkie etapy: utworzenie tokenu, renderowanie, przekazanie do dostawcy i końcowe zdarzenie u dostawcy.
  2. Podczas wewnętrznej analizy utrzymuj identyczną publiczną odpowiedź na żądanie resetu (niezależnie od tego, czy konto istnieje).

Teraz

  • Prześledź wewnętrzny identyfikator żądania — bezpieczny dla prywatności — przez styki między etapami: tokenem, renderowaniem, przekazaniem i zdarzeniem końcowym.

Najbliższe 24 godziny

  • Uruchamiaj tylko kontrolowane ponowne wysyłki, które nie prowadzą do enumeracji kont ani lawiny tokenów.

Najbliższe 7 dni

  • Włącz na stałe do procesu resetu korelację identyfikatora żądania i obsługę kontrolowanej ponownej wysyłki.

Kontrole techniczne

Inżynieria

  • Ustal ostatnie zdarzenie Amazon SES spośród Send, Rendering Failure, Delivery, Bounce, Reject, Complaint i DeliveryDelay — o ile publikowanie zdarzeń SES jest włączone.
  • Dla prywatnych kont Gmail zweryfikuj, czy uwierzytelnianie SPF lub DKIM przechodzi pomyślnie.

Kryteria weryfikacji

  • Żądanie resetu można prześledzić do zdarzenia Amazon SES, które odnotowuje, czy wiadomość została wysłana, opóźniona, dostarczona, odrzucona, odbita, zgłoszona jako spam, czy też wystąpił przy niej błąd renderowania.

Kryteria eskalacji

  • Eskaluj sprawę — z identyfikatorami żądań i diagnostyką dostawcy — dopiero wtedy, gdy potwierdzisz, że wiadomość dotarła do punktu przekazania do dostawcy tożsamości lub dostawcy poczty, ale nie pojawiło się oczekiwane zdarzenie końcowe.

Zapobieganie

  • Publikuj zdarzenia dostarczania dla strumienia resetów, aby każdą wiadomość dało się zlokalizować w stanie końcowym lub opóźnionym.
  • Zweryfikuj SPF lub DKIM dla wiadomości resetujących hasło wysyłanych na prywatne konta Gmail.
  • Stosuj identyczne odpowiedzi dla użytkownika, wewnętrzną korelację żądań i limity kontrolowanej ponownej wysyłki.

Wpływ na biznes

  • Gdy zawiedzie e-mail — skonfigurowany niezależny kanał odzyskiwania (out-of-band) — użytkownicy mogą stracić możliwość odzyskania swoich kont.

Uwagi dostawcy

  • Amazon SES udostępnia odrębne zdarzenia, które — gdy publikowanie zdarzeń jest skonfigurowane — pozwalają ustalić, na jakim etapie jest wiadomość resetująca.
  • W procesach opartych na Auth0 eskaluj sprawę dopiero wtedy, gdy potwierdzisz dotarcie do punktu przekazania do dostawcy; w innych systemach wskaż właściciela ich ostatniego potwierdzonego punktu przekazania.

Otwarte pytania

  • Nie znamy dostawcy tożsamości, ESP, domen odbiorców objętych incydentem, odsetka niepowodzeń ani ostatniego potwierdzonego zdarzenia na ścieżce dostarczania.
  • Nazwy zdarzeń u dostawców, sposób działania wykluczeń i zakresy wsparcia bywają różne; przykłady Auth0 i SES obowiązują tylko w swoim zakresie.
  • Zarchiwizowany adres URL wsparcia Auth0 (snapshot) prowadzi teraz do ogólnego Centrum Wsparcia, bez cytowanej treści artykułu, więc wymienionych tam przyczyn właściwych dla konkretnego dostawcy nie dało się niezależnie zweryfikować.
Źródła (5)
  1. Forgot Password Cheat Sheet — Introduction and MethodsOWASP Cheat Sheet Series
  2. Examples of event data that Amazon SES publishes to Amazon SNS — Event record examplesAmazon SES
  3. Email sender guidelines — Requirements for all senders; authenticationGoogle Gmail
  4. Forgot Password Cheat Sheet — Forgot Password RequestOWASP Cheat Sheet Series
  5. Troubleshoot Email Provider Delivery Issues — View errors and Contact Auth0 supportAuth0

Dlaczego e-maile z resetem hasła docierają już po wygaśnięciu?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Porównaj czas życia każdego tokenu resetu z całkowitym opóźnieniem na drodze od żądania do dostarczenia, zanim zaczniesz obwiniać skrzynkę odbiorczą. Ogólne ponowienia SMTP mogą trwać znacznie dłużej, niż token bezpieczeństwa pozostaje użyteczny — użytkownikom zostają wtedy wygasłe linki do odzyskiwania konta. Zamiast ogólnej kolejki pocztowej użyj budżetu ponowień i alertów przypisanego do resetu hasła.

Pierwsze 15 minut

  1. Sprawdź szczegóły zdarzenia DeliveryDelay w Amazon SES: odbiorcę, rozszerzony status, diagnostykę, typ opóźnienia, czas zdarzenia i czas wygaśnięcia — o ile publikowanie jest włączone.
  2. Zmierz opóźnienia od żądania do dostawcy, od dostawcy do dostarczenia i od dostarczenia do kliknięcia, a potem porównaj je z czasem życia tokenu.

Teraz

  • Jeśli opóźniona wiadomość już wygasła, wystaw nowo wygenerowany token przez ścieżkę ponownej wysyłki z limitem żądań.

Najbliższe 24 godziny

  • Po użyciu lub wymianie utrzymuj wcześniejsze tokeny resetu jako nieważne, zgodnie z przyjętym w aplikacji modelem tokenów pozostających w obiegu.

Najbliższe 7 dni

  • Ustaw dla resetu hasła osobny budżet ponowień i alertów, krótszy niż skonfigurowany czas życia tokenu.

Kontrole techniczne

Inżynieria

  • Skoreluj znaczniki czasu z aplikacji i od dostawcy przy zsynchronizowanych zegarach, a każdy segment opóźnienia porównaj z wygaśnięciem tokenu.
  • Nie traktuj zdarzenia zakolejkowania ani dostarczenia u dostawcy jako dowodu, że użytkownik dostał i otworzył działający link resetu.

Wsparcie ESP

  • Przejrzyj diagnostykę zdarzenia DeliveryDelay w SES oraz czas wygaśnięcia dla odbiorcy objętego incydentem, gdy publikowanie zdarzeń jest włączone.

Kryteria weryfikacji

  • Zmierzone opóźnienia od żądania do dostawcy, od dostawcy do dostarczenia i od dostarczenia do kliknięcia mieszczą się w skonfigurowanym czasie życia tokenu dla testowanego procesu.

Kryteria eskalacji

  • Eskaluj sprawę do ESP, gdy diagnostyka zdarzenia DeliveryDelay pokazuje, że kolejka dostawcy zbliża się do wygaśnięcia wcześniej, niż zadziała budżet osobny dla resetu hasła.

Zapobieganie

  • Używaj jednorazowych tokenów resetu z czasem życia dobranym do modelu zagrożeń aplikacji i wygody odzyskiwania konta.
  • Monitoruj każdy segment opóźnienia względem wygaśnięcia tokenu, zamiast polegać wyłącznie na przyjęciu wiadomości przez dostawcę.
  • Utrzymuj budżet ponowień i alertów dla resetu hasła krótszy niż czas życia tokenu.

Wpływ na biznes

  • Użytkownicy mogą dostać bezużyteczne linki do odzyskiwania konta, bo ogólne okna ponowień SMTP mogą być dłuższe niż właściwy czas życia jednorazowego tokenu.

Uwagi dostawcy

  • Zdarzenia DeliveryDelay w Amazon SES zawierają diagnostykę opóźnienia i czas wygaśnięcia tylko wtedy, gdy publikowanie tych zdarzeń jest włączone.

Otwarte pytania

  • Nie podano skonfigurowanego TTL tokenu, obserwowanego rozkładu opóźnień, harmonogramu ponowień ani etapu opóźnienia.
  • MTA po stronie ESP i po stronie odbiorcy stosują różne harmonogramy ponowień i zdarzenia opóźnienia, więc przykłady z RFC i SES nie przesądzają o rzeczywistym zachowaniu kolejki.
Źródła (6)
  1. RFC 5321: Simple Mail Transfer Protocol — Sections 4.2.1 and 4.5.4.1IETF RFC 5321
  2. Forgot Password Cheat Sheet — Introduction; General Security PracticesOWASP Cheat Sheet Series
  3. Examples of event data that Amazon SES publishes to Amazon SNS — DeliveryDelay recordAmazon SES
  4. Examples of event data that Amazon SES publishes to Amazon SNS — Send, Delivery, and DeliveryDelay recordsAmazon SES
  5. Forgot Password Cheat Sheet — Forgot Password Request; token securityOWASP Cheat Sheet Series
  6. RFC 5321: Simple Mail Transfer Protocol — Section 4.5.4.1, Sending StrategyIETF RFC 5321

Dlaczego klienci otrzymują zduplikowane e-maile z potwierdzeniem zamówienia?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Zduplikowane potwierdzenia biorą się stąd, że żądanie z kolejki lub z API zostaje przetworzone więcej niż raz, bez stabilnej granicy idempotencji. Powiąż każde ponowienie jednego zdarzenia zamówienia z tym samym kluczem logicznym i zadbaj, by konsument był idempotentny. Jeśli ścieżka potwierdzeń wciąż generuje powtórne wysyłki, wstrzymaj ją.

Pierwsze 15 minut

  1. Sprawdź, czy zdarzenie zamówienia przyszło ze standardowej kolejki SQS, która potrafi zwrócić tę samą kopię wiadomości więcej niż raz.
  2. Porównaj klucze idempotencji dla zduplikowanych potwierdzeń i sprawdź, czy użyto ponownie jednego stabilnego klucza zbudowanego z typu zdarzenia i ID zamówienia.
  3. Sprawdź, czy Resend zwrócił 409 dla zmienionego ładunku albo dla identycznego żądania z tym samym kluczem, które wciąż jest w toku.

Teraz

  • Dla każdego ponowienia jednego żądania o potwierdzenie zamówienia użyj ponownie tego samego klucza idempotencji i ładunku Resend.

Najbliższe 24 godziny

  • Zbuduj stabilny klucz z typu zdarzenia i ID zamówienia, tak aby jedno zdarzenie zamówienia odpowiadało jednej logicznej wysyłce.

Najbliższe 7 dni

  • Trzymaj współbieżne ponowienia na tym samym kluczu, a gdy dostaniesz 409 dla żądania wciąż w toku, wyślij później ponownie dokładnie to samo żądanie.

Kontrole techniczne

Inżynieria

  • Zweryfikuj, czy konsument SQS jest idempotentny, zanim utworzy wysyłkę potwierdzenia.
  • Uwzględnij, że Resend przechowuje klucz idempotencji przez 24 godziny, gdy ustawiasz w aplikacji okno ochrony przed duplikatami.
  • Obsługuj odpowiedzi 409 z Resend, nie tworząc nowego logicznego klucza idempotencji dla tego samego potwierdzenia.

Kryteria weryfikacji

  • Powtórz to samo żądanie Resend z kluczem w udokumentowanym, 24-godzinnym oknie przechowywania i potwierdź, że zostaje przetworzone tylko raz.
  • Potwierdź, że klucz użyty ponownie z innym ładunkiem zwraca 409, zamiast utworzyć kolejną logiczną wysyłkę.
  • Potwierdź, że identyczne żądanie z kluczem, które było w toku, można ponowić później tym samym żądaniem.

Kryteria eskalacji

  • Eskaluj sprawę, gdy projekt ochrony przed duplikatami musi obejmować okres dłuższy niż udokumentowane, 24-godzinne przechowywanie klucza idempotencji w Resend.
  • Eskaluj sprawę do ESP, gdy obserwowane zachowanie 409 różni się od udokumentowanych przypadków — zmienionego ładunku albo żądania w toku.

Zapobieganie

  • Zadbaj, by konsumenci standardowych kolejek byli idempotentni, żeby ponowne dostarczenie wiadomości nie mogło prowadzić do duplikatów.
  • Przy każdym ponowieniu używaj tego samego klucza idempotencji dostawcy.
  • Dla każdej logicznej wysyłki potwierdzenia zamówienia zbuduj jeden stabilny klucz z typu zdarzenia i ID encji.

Wpływ na biznes

  • Jeśli przy każdym ponowieniu nie użyjesz tego samego klucza idempotencji Resend, powtarzane żądania wysyłki nie są objęte udokumentowanym mechanizmem jednokrotnego przetwarzania.

Uwagi dostawcy

  • Resend przechowuje klucze idempotencji e-maili przez 24 godziny.
  • Resend zwraca 409, gdy klucz zostaje użyty ponownie z innym ładunkiem albo gdy identyczne żądanie z tym samym kluczem jest wciąż w toku.

Otwarte pytania

  • Źródłem duplikatu mogą być powtarzające się zdarzenia zamówień, ponowne dostarczenie z kolejki, współbieżne workery, ponowienie HTTP albo różne klucze idempotencji; logi muszą je od siebie odróżnić.
  • Obsługa idempotencji w API e-mailowym, czas przechowywania kluczy i semantyka konfliktów różnią się w zależności od ESP; udokumentowane, 24-godzinne zachowanie Resend nie jest uniwersalne.
  • Nie znamy obecnego trwałego rejestru wysyłek w aplikacji ani jej ograniczeń unikalności.
Źródła (5)
  1. Amazon SQS at-least-once delivery — At-least-once delivery behaviorAmazon Web Services SQS
  2. Idempotency Keys — How does it work?Resend
  3. Idempotency Keys — How does it work? and How to use idempotency keys?Resend
  4. Idempotency Keys — How to use idempotency keys?Resend
  5. Idempotency Keys — Possible responsesResend

Czy awaria e-maili kont dotyczy wiadomości rejestracyjnych, resetów haseł, czy jednych i drugich?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Traktuj e-maile rejestracyjne i e-maile z resetem hasła jako osobne ścieżki obsługi, dopóki dowody nie wskażą inaczej. Wywołaj każdy proces osobno i porównaj u dostawcy jego stany wysłania, dostarczenia, opóźnienia i niepowodzenia. Dzięki temu zobaczysz, czy niedostępne jest potwierdzenie rejestracji, odzyskiwanie hasła, czy jedno i drugie.

Pierwsze 15 minut

  1. Wywołaj osobno szablon rejestracji i szablon resetu hasła. Każdy test oznacz etykietą procesu, którego dotyczy.
  2. Przy każdym wywołaniu odróżnij udane przyjęcie przez API od przekazania do serwera odbiorcy — porównaj zdarzenia wysłania i dostarczenia.
  3. Zanim przypiszesz przyczynę, przejrzyj szczegóły zdarzeń opóźnienia dostarczenia i niepowodzenia.

Teraz

  • Napraw problem wskazany w szczegółach zdarzenia niepowodzenia: nieprawidłowego odbiorcę, poświadczenia, weryfikację domeny lub limit.

Najbliższe 24 godziny

  • Sprawdź, czy ta sama przyczyna zdarzenia niepowodzenia występuje w obu ścieżkach uwierzytelniania, czy tylko w jednej.

Najbliższe 7 dni

  • Opisz sposób reakcji na każdą przyczynę zdarzenia niepowodzenia zaobserwowaną u wdrożonego dostawcy.

Kontrole techniczne

Inżynieria

  • Skoreluj każde żądanie do dostawcy z jego zdarzeniami wysłania i dostarczenia.
  • Uruchom osobne kontrolowane testy, korzystając z testowych etykiet dostawcy dla rejestracji i resetu hasła.

Wsparcie ESP

  • Przejrzyj szczegóły dołączone do zdarzeń opóźnienia dostarczenia i niepowodzenia w procesie, którego dotyczy problem.

Kryteria weryfikacji

  • Osobne kontrolowane testy rejestracji i resetu hasła osiągają u dostawcy stan dostarczenia, a nie zatrzymują się na wysłaniu.
  • Oba testowe procesy pozostają rozróżnialne w zapisach zdarzeń, więc ewentualny nawrót można wyodrębnić na podstawie procesu.

Kryteria eskalacji

  • Eskaluj sprawę do dostawcy e-maili, gdy zdarzenia opóźnienia dostarczenia utrzymują się, a nie towarzyszy im użyteczny opis tymczasowej przyczyny.
  • Eskaluj sprawę do zespołu inżynierskiego odpowiedzialnego za usługę, gdy zdarzenia niepowodzenia wskazują jako przyczynę poświadczenia, weryfikację domeny lub limit.

Zapobieganie

  • Utrzymuj osobne kontrolowane testy rejestracji i resetu hasła, aby obie ścieżki uwierzytelniania dało się sprawdzać niezależnie.

Wpływ na biznes

  • Incydent może zakłócić potwierdzenie rejestracji, reset hasła albo obie te odrębne ścieżki uwierzytelniania.

Uwagi dostawcy

  • Nazwy sent, delivered, delivery-delayed i failed pochodzą w tym runbooku z semantyki zdarzeń Resend; dla innego dostawcy zmapuj równoważne stany.

Otwarte pytania

  • Nie podano platformy, dostawcy, środowiska ani identyfikatorów wiadomości, których dotyczy incydent; na podstawie samego pytania nie da się ustalić dokładnej przyczyny źródłowej.
  • To, czy problem dotyczy rejestracji, resetu hasła, czy obu naraz, trzeba ustalić osobnymi kontrolowanymi wywołaniami i prześledzeniem zdarzeń.
  • Nazwy zdarzeń i sposób ponawiania różnią się między dostawcami; udokumentowane stany Resend zmapuj na wdrożonego dostawcę.
Źródła (5)
  1. Email Templates — Authentication emailsSupabase
  2. Event Types — Email Events: email.sent and email.deliveredResend
  3. Event Types — Email Events: email.delivery_delayedResend
  4. Event Types — Email Events: email.failedResend
  5. Send Test Emails — Using labels effectivelyResend

Dlaczego Lovable przestał wysyłać maile transakcyjne?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Najpierw ustal, czy projekt korzysta z zarządzanego e-maila Lovable Cloud, czy z oddzielnego konektora Resend. Odłączony projekt traci dostęp do konektora, natomiast poczta z własnej domeny w Cloud wymaga domeny w statusie Verified i włączonego e-maila w projekcie. Lovable Cloud ma też godzinny limit na przestrzeń roboczą (workspace), który nie dotyczy oddzielnego konektora.

Pierwsze 15 minut

  1. Ustal, czy projekt korzysta z konektora Resend, czy z zarządzanego e-maila Lovable Cloud.
  2. Dla konektora Resend sprawdź klucz API, konfigurację nadawcy lub domeny, powiązanie projektu oraz odrzucone lub nieudane wysyłki.
  3. Dla Lovable Cloud potwierdź, że własna domena ma status Verified, a e-mail jest włączony w projekcie.

Teraz

  • Przywróć poprawny klucz API Resend, konfigurację nadawcy lub domeny oraz powiązanie projektu, gdy kontrole konektora wykażą niezgodność.

Najbliższe 24 godziny

  • Przywróć wysyłkę z własnej domeny w Lovable Cloud dopiero wtedy, gdy domena uzyska status Verified, a e-mail zostanie włączony w projekcie.

Najbliższe 7 dni

  • Udokumentuj odrębne mechanizmy kontrolne dla powiązania konektora i dla domeny w Cloud, aby przyszłe incydenty trafiały na właściwą ścieżkę.

Kontrole techniczne

Inżynieria

  • Potwierdź, że projekt objęty problemem jest nadal powiązany z właściwym połączeniem Resend w przestrzeni roboczej.
  • Zweryfikuj klucz API Resend, konfigurację nadawcy lub domeny oraz odrzucone lub nieudane wysyłki.
  • Jeśli korzystasz z Lovable Cloud, potwierdź, że domena ma status Verified i że e-mail jest włączony w projekcie.

Wsparcie ESP

  • Przejrzyj powiązane konto Resend pod kątem odrzuconych lub nieudanych wysyłek związanych z projektem.

Kryteria weryfikacji

  • Nowy test konektora pojawia się na właściwym koncie Resend, bez odrzuconych lub nieudanych wysyłek.
  • Test Lovable Cloud zostaje wysłany dopiero wtedy, gdy własna domena ma status Verified, a e-mail w projekcie jest włączony.

Kryteria eskalacji

  • Eskaluj do wsparcia Lovable powtarzalny błąd platformy lub brak obejścia, a aktualizacje o incydentach obejmujących całą platformę śledź na stronie statusu Lovable.

Zapobieganie

  • Rejestruj, które projekty są powiązane z konektorem Resend w przestrzeni roboczej, i traktuj odłączenie jako odebranie dostępu do e-maila.
  • Monitoruj weryfikację domeny w Lovable Cloud oraz włączenie e-maila w projekcie jako dwie odrębne kontrole.

Wpływ na biznes

  • Odłączony konektor Resend odbiera projektowi dostęp do tego połączenia e-mailowego.
  • Poczta z własnej domeny w Lovable Cloud wymaga zarówno statusu Verified dla domeny, jak i włączonego e-maila w projekcie.

Uwagi dostawcy

  • Zarządzany e-mail Lovable Cloud jest udokumentowany na poziomie 100 wiadomości na godzinę na przestrzeń roboczą; limit ten nie dotyczy oddzielnego konektora Resend.

Otwarte pytania

  • Pytanie nie określa, czy aplikacja korzysta z zarządzanego e-maila Lovable Cloud, czy z oddzielnego konektora Resend; ich mechanizmy kontrolne i logi się różnią.
  • Nie podano logów projektu, stanu konektora, statusu domeny, błędu HTTP, stanu limitu ani identyfikatora wiadomości od dostawcy, więc nie znamy dokładnej przyczyny.
  • Awarii dotyczącej konkretnego dzierżawcy (tenant) nie da się przypisać do incydentu obejmującego całe Lovable bez dowodów ze strony statusu pochodzących z tego samego czasu.
Źródła (6)
  1. Connect your app to Resend — How Resend connections workLovable
  2. Connect your app to Resend — FAQ and Limitations: emails are not sendingLovable
  3. Connect your app to Resend — How to unlink projects from a connectionLovable
  4. Send branded emails from your own domain — Email domain scope and Troubleshooting: Emails are not sendingLovable
  5. Send branded emails from your own domain — Availability and usage; TroubleshootingLovable
  6. Support policy — Scope and ChannelsLovable

Dlaczego e-maile OTP lub weryfikacyjne docierają za późno?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Zanim zmienisz ustawienia OTP, zlokalizuj opóźnienie między przyjęciem żądania przez API dostawcy a przekazaniem wiadomości do serwera odbiorcy. Porównaj znaczniki czasu zdarzeń wysłania, opóźnienia dostarczenia i dostarczenia ze skonfigurowanym w projekcie czasem wygaśnięcia OTP. Jednogodzinny czas wygaśnięcia w Supabase to ustawienie domyślne wersji hostowanej, a nie uniwersalny cel.

Pierwsze 15 minut

  1. Skoreluj znaczniki czasu przyjęcia przez API, wysłania, opóźnienia dostarczenia i dostarczenia dla kontrolowanych żądań OTP.
  2. Porównaj zmierzony czas przekazania ze skonfigurowanym w projekcie czasem wygaśnięcia OTP, zamiast zakładać ustawienie domyślne wersji hostowanej.

Teraz

  • Użyj Send Email Auth Hook w Supabase, aby kolejkować e-maile uwierzytelniające, gdy do opóźnień przyczyniają się skoki ruchu.

Najbliższe 24 godziny

  • Skonfiguruj kolejkę Send Email Auth Hook, aby wygładzić obserwowane skoki liczby e-maili uwierzytelniających.

Najbliższe 7 dni

  • Rozważ kierowanie Send Email Auth Hook przez wiele usług wysyłkowych, aby zwiększyć niezawodność.

Kontrole techniczne

Inżynieria

  • Zmierz odstęp od wysłania przez dostawcę do dostarczenia dla każdego kontrolowanego żądania OTP.
  • Odczytaj wdrożony odstęp między żądaniami i czas wygaśnięcia OTP, zamiast zakładać domyślne 60 sekund i jedną godzinę.

Wsparcie ESP

  • Zbadaj szczegóły zdarzeń opóźnienia dostarczenia i niepowodzenia dla odbiorców objętych incydentem.

Kryteria weryfikacji

  • Kontrolowane żądania docierają do zdarzenia dostarczenia przed skonfigurowanym w projekcie czasem wygaśnięcia OTP.
  • Zmierzony odstęp od wysłania do dostarczenia pozostaje widoczny dla każdego kontrolowanego żądania OTP.

Kryteria eskalacji

  • Eskaluj sprawę do dostawcy, gdy zdarzenia opóźnienia dostarczenia się utrzymują, a szczegóły ich tymczasowej przyczyny nie tłumaczą powrotu do normy.
  • Eskaluj sprawę do inżynierii, gdy zdarzenia niepowodzenia wskazują błędy odbiorcy, poświadczeń, weryfikacji domeny lub limitu.

Zapobieganie

  • Trzymaj skonfigurowany odstęp między żądaniami jawnie zdefiniowany, zamiast zakładać domyślne 60 sekund z wersji hostowanej Supabase.
  • Używaj zakolejkowanego Send Email Auth Hook oraz, w stosownych przypadkach, wielu usług wysyłkowych, aby wygładzać skoki i poprawiać niezawodność.

Wpływ na biznes

  • Kodu OTP, który dociera po skonfigurowanym czasie wygaśnięcia, nie da się użyć w tym oknie ważności.

Uwagi dostawcy

  • Jednogodzinny czas wygaśnięcia OTP i 60-sekundowy odstęp między żądaniami to ustawienia domyślne wersji hostowanej Supabase; konfiguracja projektu może się różnić.

Otwarte pytania

  • Nie podano wdrożonego dostawcy uwierzytelniania, skonfigurowanego czasu życia OTP, znaczników czasu kolejki, zdarzeń dostawcy, dostawcy odbiorcy ani obserwowanego rozkładu opóźnień.
  • Jednogodzinny czas wygaśnięcia i 60-sekundowe okno żądań to wartości domyślne Supabase, a nie uniwersalne wymagania OTP.
  • Nie wiadomo, czy opóźnienie powstaje przed przyjęciem przez dostawcę, w trakcie dostarczania przez dostawcę, czy już po przekazaniu do serwera odbiorcy.
Źródła (6)
  1. Event Types — Email Events: email.sent and email.deliveredResend
  2. Event Types — Email Events: email.delivery_delayedResend
  3. Passwordless email logins — Email OTP request behaviorSupabase
  4. Passwordless email logins — Email OTP request behaviorSupabase
  5. Send emails with custom SMTP — Use the Send Email Auth Hook for more controlSupabase
  6. Event Types — Email Events: email.failedResend

Dlaczego e-maile z weryfikacją logowania Salesforce nie docierają do użytkowników?

Poziom ważności: WysokiWstrzymanie wysyłki: Kontynuuj wysyłkę

Zacznij od Salesforce Email Log Files, aby ustalić, czy wiadomość z weryfikacją logowania została wysłana, czy się nie powiodła. Weryfikację logowania z noreply[at]salesforce.com traktuj jako strumień odrębny od resetu hasła z support[at]salesforce.com. W trakcie zbierania dowodów nie ponawiaj żądań kodu, bo proces weryfikacji ma godzinny limit żądań.

Pierwsze 15 minut

  1. Potwierdź, czy brakujący strumień to weryfikacja logowania z noreply[at]salesforce.com, a nie reset hasła z support[at]salesforce.com.
  2. Zażądaj Salesforce Email Log Files, aby ustalić, czy wiadomość weryfikacyjna została wysłana, czy się nie powiodła.
  3. Sprawdź w Login History i Identity Verification History, jaką weryfikację uruchomił Salesforce i pod jaki adres próbował ją skierować.

Teraz

  • Jeśli filtrowana jest tylko weryfikacja logowania, prześledź ten strumień i dodaj do niego noreply[at]salesforce.com na liście dozwolonych.

Najbliższe 24 godziny

  • Śledząc Message-ID lub nadawcę, potwierdź, że zmiana na liście dozwolonych działa na właściwy strumień weryfikacji.

Najbliższe 7 dni

  • Opisz w runbooku wsparcia odrębnych nadawców Salesforce oraz limit pięciu żądań kodu weryfikacyjnego na godzinę.

Kontrole techniczne

Inżynieria

  • Dopasuj zdarzenie weryfikacji logowania w Login History lub Identity Verification History do wpisu w logu e-mail.

IT / DNS

  • Jeśli logi Salesforce pokazują dostarczenie do serwera odbiorcy, prześledź Message-ID przez filtrowanie po stronie odbiorcy.
  • Dodaj noreply[at]salesforce.com do listy dozwolonych (allowlist) tylko wtedy, gdy filtrowany jest wyłącznie ten strumień weryfikacji logowania.

Kryteria weryfikacji

  • Salesforce Email Log Files pokazują, czy kontrolowana wiadomość weryfikacyjna została wysłana, czy się nie powiodła.
  • Jeśli log pokazuje dostarczenie do serwera odbiorcy, śledzenie po stronie odbiorcy wskaże, jak potem zadecydował filtr.

Kryteria eskalacji

  • Eskaluj sprawę do administratora poczty odbiorcy, gdy logi Salesforce pokazują dostarczenie do serwera odbiorcy, a wiadomość mimo to jest filtrowana.
  • Eskaluj sprawę filtrowania zależnego od nadawcy, gdy prześledzenie Message-ID i dodanie noreply[at]salesforce.com do listy dozwolonych nie przywracają strumienia weryfikacji logowania.

Zapobieganie

  • Monitoruj strumień weryfikacji z noreply[at]salesforce.com oddzielnie od strumienia resetu hasła z support[at]salesforce.com.
  • Zachowuj logi e-mail Salesforce oraz historię weryfikacji logowania, aby odróżnić przekazanie wiadomości od filtrowania po stronie odbiorcy.

Wpływ na biznes

  • Filtrowanie strumienia weryfikacji logowania z noreply[at]salesforce.com może odciąć użytkowników od tej ścieżki weryfikacji, nawet gdy maile z resetem hasła docierają bez przeszkód.

Uwagi dostawcy

  • Salesforce wskazuje w dokumentacji noreply[at]salesforce.com do weryfikacji logowania, support[at]salesforce.com do resetu hasła oraz limit pięciu żądań kodu na godzinę dla opisanego procesu weryfikacji.

Otwarte pytania

  • Salesforce Email Log Files, Login History, Identity Verification History, Message-ID, domena odbiorcy i werdykt filtra nie zostały podane.
  • Adresy nadawców Salesforce i limity kodów dotyczą wyłącznie udokumentowanych procesów i mogą się zmieniać w zależności od produktu lub metody weryfikacji.
  • Bez wyniku przekazania po stronie Salesforce nie da się jeszcze przypisać incydentu do wysyłki Salesforce ani do systemu pocztowego odbiorcy.
Źródła (6)
  1. Salesforce Login Verification Emails Not Received — Important distinctionSalesforce
  2. Salesforce Login Verification Emails Not Received — Resolution, Step 1: Request and Review Salesforce Email Log FilesSalesforce
  3. Salesforce Login Verification Emails Not Received — Resolution, Step 2: Confirm If Salesforce Delivered the Email SuccessfullySalesforce
  4. Salesforce Login Verification Emails Not Received — Resolution, Steps 2-3Salesforce
  5. System Verification Codes Not Received for Salesforce — Email Verification codesSalesforce
  6. Admin Guide: Resolve User Login Problems — Scenario 2: Verification IssuesSalesforce

Dlaczego klient nie otrzymał e-maila z potwierdzeniem zamówienia?

Poziom ważności: ŚredniWstrzymanie wysyłki: Wstrzymaj warunkowo

Zanim ponowisz wysyłkę, potraktuj brakujące potwierdzenie zamówienia jako problem z możliwością prześledzenia wiadomości. Dopasuj wiadomość wywołaną przez zamówienie do stanów wysłania i dostarczenia u dostawcy, aby ustalić, czy doszło do przekazania. Jeśli ponowienie jest konieczne, skorzystaj z idempotencji, aby sama diagnostyka nie wygenerowała zduplikowanego potwierdzenia.

Pierwsze 15 minut

  1. Dopasuj zdarzenie zamówienia do zdarzenia wysłania u dostawcy. Następnie sprawdź przekazanie do serwera odbiorcy (stan dostarczenia).
  2. Sprawdź, czy odbiorca został wykluczony (suppressed) po twardym odbiciu (hard bounce) lub zgłoszeniu spamu.
  3. Zanim wykonasz jakiekolwiek ponowienie, ustal, czy ważny klucz `Idempotency-Key` może zapobiec zduplikowanemu żądaniu.

Teraz

  • Zidentyfikuj i napraw pierwotną przyczynę twardego odbicia (hard bounce) lub zgłoszenia spamu, zanim zmienisz status wykluczonego odbiorcy.

Najbliższe 24 godziny

  • Usuń wykluczenie dopiero po potwierdzeniu adresu i naprawieniu źródłowej przyczyny.

Najbliższe 7 dni

  • Sprawdź, czy odbiorcy, których wcześniej przywrócono, nie są ponownie wykluczani — to sygnał, że pierwotna przyczyna nadal występuje.

Kontrole techniczne

Inżynieria

  • Skoreluj zdarzenie zamówienia ze stanami wysłania i dostarczenia u dostawcy.
  • Sprawdź, czy pierwotne żądanie korzystało z klucza `Idempotency-Key` i czy jego 24-godzinne okno przechowywania nadal obowiązuje.

Dostarczalność

  • Zbadaj stan wykluczenia odbiorcy oraz przyczynę twardego odbicia (hard bounce) lub zgłoszenia spamu.

Kryteria weryfikacji

  • Kontrolowane potwierdzenie zamówienia osiąga u dostawcy stan dostarczenia, zamiast zatrzymać się na stanie wysłania.
  • Adresy testowe dostawcy odtwarzają wyniki dostarczenia, odbicia, zgłoszenia spamu i wykluczenia bez użycia fałszywych odbiorców.

Kryteria eskalacji

  • Eskaluj sprawę do dostawcy, gdy wiadomość ma zdarzenie wysłania, ale brakuje dającego się wyjaśnić zdarzenia dostarczenia lub zdarzenia końcowego.
  • Eskaluj sprawę do zespołu dostarczalności, gdy przyczyny wykluczenia nie da się naprawić bez ryzyka kolejnego twardego odbicia (hard bounce) lub zgłoszenia spamu.

Zapobieganie

  • W ponawialnych żądaniach potwierdzenia zamówienia używaj klucza `Idempotency-Key` w Resend, w ramach jego 24-godzinnego okna przechowywania.
  • Testuj ścieżki dostarczenia, odbicia, zgłoszenia spamu i wykluczenia na udokumentowanych adresach testowych dostawcy.
  • Wymagaj naprawienia pierwotnej przyczyny odbicia (bounce) lub zgłoszenia spamu przed usunięciem wykluczenia.

Wpływ na biznes

  • Brak potwierdzenia zamówienia wysyłanego jeden do jednego zakłóca wiadomość transakcyjną wywołaną zakupem klienta.

Uwagi dostawcy

  • Stany wysłania i dostarczenia w Resend, regionalne wykluczenia, adresy testowe oraz 24-godzinne okno idempotencji to mechanizmy specyficzne dla dostawcy.

Otwarte pytania

  • Nie podano identyfikatora zdarzenia zamówienia, adresu odbiorcy, identyfikatora wiadomości u dostawcy, odpowiedzi API, zdarzeń dostarczenia ani stanu wykluczenia.
  • Dokładny dostawca jest nieznany; fakty o Resend i Postmark opisują przykłady stanów i klasyfikacji specyficzne dla danego dostawcy.
  • To, że serwer odbiorcy przyjął wiadomość, nie dowodzi, że klient zobaczył ją w skrzynce odbiorczej ani że ją przeczytał.
Źródła (6)
  1. Introduction — Things you should know: Message StreamsPostmark
  2. Event Types — Email Events: email.sent and email.deliveredResend
  3. Email Suppressions — What caused the suppression and Suppression ScopeResend
  4. Send Email — Headers: Idempotency-KeyResend
  5. Send Test Emails — How to send test emailsResend
  6. Email Suppressions — Viewing Suppression Details and removal guidanceResend

Dlaczego API OTP na stagingu zwraca sukces, choć żaden e-mail nie dociera?

Poziom ważności: ŚredniWstrzymanie wysyłki: Wstrzymaj warunkowo

Sukces zwrócony przez API OTP nie dowodzi, że serwer pocztowy odbiorcy przyjął wiadomość. W projekcie stagingowym Supabase najpierw sprawdź, czy odbiorca ma autoryzację dla domyślnego SMTP, i przejrzyj odpowiedzi o limitach żądań (rate limit). Następnie prześledź dalsze zdarzenia — wysłania i dostarczenia. Wbudowana usługa SMTP działa w trybie best-effort i jest przeznaczona do zastosowań nieprodukcyjnych.

Pierwsze 15 minut

  1. Potwierdź, że adres odbiorcy jest z góry autoryzowany jako członek zespołu organizacji w projekcie, gdy działa domyślny SMTP.
  2. Sprawdź, czy Supabase zwróciło HTTP 429 i czy obowiązuje limit wbudowanego dostawcy dla całego projektu.
  3. Prześledź żądanie dalej niż do odpowiedzi o sukcesie z API — aż do dalszych zdarzeń wysłania i dostarczenia.

Teraz

  • Zdecyduj, czy ścieżka uwierzytelniania na stagingu potrzebuje niezawodności własnego SMTP zamiast domyślnego.

Najbliższe 24 godziny

  • Skonfiguruj własny SMTP, gdy ścieżka e-maili uwierzytelniających jest produkcyjna lub w inny sposób krytyczna.

Najbliższe 7 dni

  • Utrzymuj krytyczne e-maile uwierzytelniające na ścieżce własnego SMTP zalecanej przez Supabase.

Kontrole techniczne

Inżynieria

  • Zweryfikuj, czy odbiorca testowy ma autoryzację w zespole projektu, gdy skonfigurowany jest domyślny SMTP.
  • Zapisz odpowiedzi HTTP 429 i aktywny limit żądań wbudowanego dostawcy.
  • Skoreluj żądanie OTP z dalszymi zdarzeniami wysłania i dostarczenia, zamiast poprzestać na odpowiedzi o sukcesie z API.

Kryteria weryfikacji

  • Kontrolowane żądanie OTP dociera do dalszego zdarzenia dostarczenia, a nie zatrzymuje się na stanie wysłania lub odpowiedzi o sukcesie z API.
  • Krytyczna ścieżka korzysta ze skonfigurowanej usługi własnego SMTP, a nie z domyślnego SMTP Supabase.

Kryteria eskalacji

  • Eskaluj sprawę do właściciela projektu, gdy krytyczna ścieżka uwierzytelniania wciąż zależy od domyślnego SMTP w trybie best-effort.
  • Eskaluj sprawę konfiguracji poczty, gdy krytyczny proces wymaga własnego SMTP, a tego jeszcze nie skonfigurowano.

Zapobieganie

  • Monitoruj limit dwóch wiadomości na godzinę, jaki wbudowany dostawca nakłada na cały projekt — wszędzie tam, gdzie pozostaje włączony.
  • Używaj własnego SMTP do produkcyjnych i innych krytycznych e-maili uwierzytelniających w Supabase.

Wpływ na biznes

  • Proces na stagingu oparty na domyślnym SMTP w trybie best-effort nie może traktować odpowiedzi o sukcesie z API jako gwarancji, że wiadomość została przekazana dalej do serwera odbiorcy.

Uwagi dostawcy

  • Domyślny SMTP Supabase ogranicza odbiorców do autoryzowanych adresów zespołu projektu, działa w trybie best-effort i jest przeznaczony wyłącznie do zastosowań nieprodukcyjnych.

Otwarte pytania

  • Nie wiadomo, jakie API OTP i jaki dostawca poczty wchodzą w grę; zachowania Supabase i Resend nie wolno zakładać dla innego stosu technologicznego.
  • Nie podano autoryzacji odbiorcy w zespole projektu, bieżącej odpowiedzi o limicie żądań, konfiguracji SMTP ani dalszych zdarzeń dostarczenia.
  • Sama odpowiedź o sukcesie z API nie wskazuje, w którym miejscu zatrzymała się dalsza ścieżka dostarczania e-maila.
Źródła (6)
  1. Send emails with custom SMTP — Default SMTP restrictions: Send messages only to pre-authorized addressesSupabase
  2. Rate limits — Rate-limit table: endpoints that trigger email sendsSupabase
  3. Send emails with custom SMTP — Default SMTP restrictions: No SLA guaranteeSupabase
  4. Event Types — Email Events: email.sent and email.deliveredResend
  5. Send emails with custom SMTP — Default SMTP restrictions and custom SMTP setupSupabase
  6. Rate limits — Rate-limit behaviorSupabase

Jak zapewnić niezawodność e-maili transakcyjnych w naszym SaaS?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Traktuj akceptację API jako próbę wysyłki, a nie dowód, że klient otrzymał wiadomość, i monitoruj zdarzenia końcowego dostarczenia, odbicia, zgłoszenia spamu i opóźnienia. Tam, gdzie używasz Resend, przy ponowieniach użyj tego samego klucza idempotencji i ładunku w obrębie 24-godzinnego okna przechowywania. Przy poczcie Amazon SES o krótkim oknie ważności skonfiguruj okno dostarczania tak, aby odpowiadało okresowi ważności tokenu i ważności biznesowej w aplikacji.

Pierwsze 15 minut

  1. Oddziel udane żądania API od zdarzeń dostarczenia, odbicia, zgłoszenia spamu i opóźnienia dla strumienia wiadomości objętego incydentem.
  2. Sprawdź, czy każde ponowienie przestrzegało kontraktu idempotencji u wdrożonego dostawcy; dla Resend potwierdź, że w ciągu 24 godzin ponownie użyto tego samego klucza i ładunku.

Teraz

  • Dodaj obsługiwaną przez dostawcę idempotencję do powtarzanych żądań wysyłki.
  • Deduplikuj zdarzenia webhooka SendGrid według sg_event_id, gdy jest obecny.

Najbliższe 24 godziny

  • Dla poczty o krótkim oknie ważności ustaw maksymalny czas dostarczania w Amazon SES na okres ważności w aplikacji.

Najbliższe 7 dni

  • Oddziel wiadomości transakcyjne jeden-do-jednego od newsletterów, ogłoszeń i innych strumieni masowych, korzystając z równoważnych mechanizmów u wdrożonego dostawcy.

Kontrole techniczne

Inżynieria

  • Potwierdź, że ponowienia Resend używają tego samego klucza idempotencji i ładunku w udokumentowanym 24-godzinnym oknie.
  • Deduplikuj ładunki zdarzeń z SendGrid Event Webhook według sg_event_id, gdy tylko ten identyfikator jest obecny.
  • Sprawdź, czy endpoint webhooka SendGrid zwracał odpowiedzi inne niż 2xx, i uwzględnij ponowienia w coraz dłuższych odstępach przez maksymalnie 24 godziny.
  • Odróżnij akceptację wysyłki przez Amazon SES od zdarzeń dostarczenia, odbicia, zgłoszenia spamu i opóźnienia.

Kryteria weryfikacji

  • Testowa wysyłka daje wynik końcowego dostarczenia, odbicia, zgłoszenia spamu lub opóźnienia — odrębny od akceptacji API.
  • Monitoring raportuje zdarzenia końcowego dostarczenia, odbicia, zgłoszenia spamu i opóźnienia dla strumienia transakcyjnego, zamiast zliczać akceptację API jako dostarczenie do klienta.

Kryteria eskalacji

  • Eskaluj sprawę do ESP i zespołu inżynierii, gdy zaakceptowanym wysyłkom brakuje pochodzącego od dostawcy wyniku końcowego dostarczenia, odbicia, zgłoszenia spamu lub opóźnienia.

Zapobieganie

  • Używaj idempotentnych żądań wysyłki i deduplikuj wywołania zwrotne zdarzeń od dostawcy.
  • Trzymaj strumienie transakcyjne oddzielnie od poczty masowej i ustaw alerty na wyniki końcowego dostarczenia, odbicia, zgłoszenia spamu i opóźnienia.

Wpływ na biznes

  • Wiadomości o krótkim oknie ważności, takie jak e-mail z jednorazowym hasłem, mogą dotrzeć po upływie użytecznego okresu ważności w aplikacji, jeśli okno dostarczania nie zostanie do niego dopasowane.
  • Traktowanie akceptacji API jako dostarczenia do klienta może przesłonić odbicia, zgłoszenia spamu, opóźnienia lub brakujące wyniki końcowego dostarczenia.

Uwagi dostawcy

  • SendGrid ponawia żądanie POST do Event Webhook po odpowiedzi innej niż 2xx, w coraz dłuższych odstępach, przez maksymalnie 24 godziny.

Otwarte pytania

  • Wdrożony ESP, jego kontrakt idempotencji, gwarancje dostarczania webhooków, stan listy wykluczeń oraz możliwości failover nie są znane.
  • Biznesowe SLO, okna ważności tokenów, akceptowalne ryzyko duplikatów oraz zaobserwowane luki w zdarzeniach musi podać właściciel SaaS.
Źródła (7)
  1. Idempotency Keys — How does it work?Resend
  2. Twilio SendGrid Event Webhook Overview — Duplicate eventsTwilio SendGrid
  3. Twilio SendGrid Event Webhook Overview — General troubleshootingTwilio SendGrid
  4. Creating Amazon SES event destinations — Select event typesAmazon SES
  5. Creating configuration sets in SES — Maximum delivery durationAmazon SES
  6. Postmark Developer Documentation — Things you should know: Message StreamsPostmark
  7. Creating Amazon SES event destinations — Sending and delivery event typesAmazon SES

Powiązane zasoby

Wojtek BlazalekWojtek BlazalekEkspert ds. dostarczalności e-mail

Masz incydent z pocztą? Pomagam zespołom przywrócić dostarczanie, reputację i uwierzytelnianie do normy.

Praktyczna praca nad dostarczalnością dla firm wysyłających na dużą skalę

Umów bezpłatną rozmowę diagnostycznąZobacz usługi
Umów bezpłatną rozmowę diagnostyczną