Piątek, 17:30. Wychodzę z biura, telefon dzwoni. CTO klienta: “Nasze potwierdzenia zamówień nie dochodzą od trzech godzin. Black Friday. Mamy problem.”
Okazało się, że ich bounce rate skoczył do 15% (zwykle było 1%). Ktoś dodał do bazy 50 tysięcy starych adresów “bo szkoda je marnować”. Gmail zareagował natychmiast — zablokował całą domenę.
Gdyby mieli monitoring z alertami, wiedzieliby o tym po 15 minutach, nie po 3 godzinach. Ta historia kosztowała ich około 200 tysięcy złotych w utraconych zamówieniach.
“Email wysłany” to nie to samo co “email dostarczony”
Jako DevOps czy SRE wiesz to doskonale. Ale czy Twój zespół widzi, co dzieje się z wiadomościami po tym, jak opuszczą serwer?
Większość firm dowiaduje się o problemach z dostarczalnością od… klientów. “Nie dostałem faktury.” “Gdzie moje potwierdzenie?” “Sprawdźcie spam.” To nie jest monitoring. To gaszenie pożarów.
Co właściwie powinniśmy śledzić?
Zacznijmy od podstaw. Te metryki powinieneś znać na pamięć:
Delivery Rate — procent wiadomości zaakceptowanych przez serwer odbiorcy. Zdrowy poziom to powyżej 98%. Jeśli spada poniżej 95%, coś jest nie tak.
Bounce Rate — procent odrzuconych wiadomości. Powinno być poniżej 2%. Powyżej 5% to już czerwony alarm.
Spam Complaint Rate — procent odbiorców zgłaszających spam. Maksymalnie 0.1%. Powyżej 0.3% Gmail zacznie patrzeć na Ciebie podejrzliwie.
Jest jeszcze kilka metryk dla zaawansowanych:
- Time to Delivery — ile sekund od wysłania do dostarczenia. Cel: poniżej 10 sekund dla 95% wiadomości.
- Inbox Placement Rate — procent wiadomości lądujących w inbox, nie w spamie.
- DMARC Pass Rate — powinno być powyżej 99%.
Bounce’y nie są sobie równe
To jest ważne, bo wielu ludzi tego nie rozumie.
Hard bounce to trwałe odrzucenie. Adres nie istnieje, domena nie istnieje, skrzynka zablokowana permanentnie. Kod 550. Akcja? Natychmiast usuń z listy. Każda kolejna próba wysyłki na ten adres szkodzi Twojej reputacji.
Soft bounce to problem tymczasowy. Skrzynka pełna (kod 452), serwer chwilowo niedostępny, wiadomość za duża. Akcja? Ponów próbę za jakiś czas. Ale jeśli po 3-5 próbach wciąż nie działa — traktuj jak hard bounce.
Żeby było jasne, kody SMTP działają tak:
- 4xx to błędy tymczasowe (możesz ponawiać)
- 5xx to błędy permanentne (nie ponawiaj)
Narzędzia zewnętrzne — darmowe i płatne
Google Postmaster Tools (postmaster.google.com) — obowiązkowe jeśli masz wielu odbiorców na Gmail. Pokazuje reputację domeny, spam rate, błędy autentykacji. Darmowe, ale dane pojawiają się z opóźnieniem ~24h.
Microsoft SNDS — to samo dla Outlook i Hotmail. Trochę mniej intuicyjne, ale darmowe.
MXToolbox — sprawdza blacklisty (ponad 100), DNS, SPF/DKIM/DMARC. Wersja darmowa do ręcznych sprawdzeń, płatna z automatycznym monitoringiem i alertami.
Budowanie własnego dashboardu
Okej, tu przechodzimy do konkretów technicznych.
Architektura jest prosta:
MailingAPI → Webhooks → Event Processor → TimescaleDB → Grafana
↓
Alert Manager → Slack/PagerDuty
Webhook handler w Pythonie może wyglądać tak:
from fastapi import FastAPI, Request
from prometheus_client import Counter, Histogram
app = FastAPI()
email_events = Counter(
'email_events_total',
'Total email events',
['event_type', 'domain']
)
@app.post("/webhooks/mailingapi")
async def handle_webhook(request: Request):
event = await request.json()
email_events.labels(
event_type=event["type"],
domain=event["from_domain"]
).inc()
match event["type"]:
case "bounced":
if event["bounce_type"] == "hard":
await remove_from_list(event["recipient"])
await alert_if_spike(event)
case "complained":
# Spam complaint — zawsze reaguj natychmiast
await alert_immediately(f"Spam complaint: {event['recipient']}")
await add_to_suppression_list(event["recipient"])
return {"status": "ok"}
Kluczowa jest funkcja alert_if_spike — sprawdza czy bounce rate w ostatnich 15 minutach nie przekroczył progu. Jeśli tak, wysyła alert.
W Grafanie query PromQL dla delivery rate wygląda tak:
sum(rate(email_events_total{event_type="delivered"}[1h]))
/
sum(rate(email_events_total{event_type=~"delivered|bounced"}[1h]))
* 100
Co alertować natychmiast, a co śledzić w trendach
Są rzeczy, które wymagają natychmiastowej reakcji (czytaj: budzą Cię w nocy):
- Bounce rate >10% przez 15 minut — coś poszło bardzo źle
- Jakikolwiek spam complaint — ktoś oznaczył Twój mail jako spam
- Wykrycie na blackliście — musisz zacząć delisting
- Delivery rate <90% — sprawdź infrastrukturę
A są rzeczy, które warto obserwować w trendach (codzienny raport na Slack):
- Średni bounce rate — czy rośnie przez kilka dni z rzędu?
- Open rate — czy nie spadł nagle o 15%+?
- Unsubscribe rate — czy nie ma spike’a?
Jak to robimy w MailingAPI
Szczerze? Zbudowaliśmy to wszystko, żebyś nie musiał.
Dashboard pokazuje delivery rate, bounce rate i complaints w czasie rzeczywistym. Wykresy per domena. Szczegóły każdej wiadomości.
Webhooks wysyłają eventy dla każdego statusu: sent, delivered, bounced, complained, opened, clicked. Z automatycznym retry i signature verification.
Alerty? Email gdy bounce rate przekroczy próg. Powiadomienie o blacklist hit. Info o błędach autentykacji.
Możesz też eksportować dane przez API:
curl -H "Authorization: Bearer $API_KEY" \
"https://api.mailingapi.com/v1/stats?domain=example.com&period=7d"
Moja checklista monitoringu
Codziennie (automatycznie):
- Delivery rate >98%
- Bounce rate <2%
- Zero spam complaints
- Zero nowych blacklist hits
Co tydzień (przegląd):
- Trend bounce rate stabilny
- Open rate bez anomalii
- Sprawdzenie reputacji w Postmaster Tools
Co miesiąc (audyt):
- Przegląd suppression list
- Weryfikacja DNS
- Test end-to-end przez mail-tester.com
Na koniec
Monitoring deliverability to nie luksus. To podstawa. Różnica między “dowiesz się po 15 minutach” a “dowiesz się od klienta po 3 godzinach” to często różnica między małym problemem a katastrofą.
Jeśli nie chcesz budować tego wszystkiego sam — załóż darmowe konto i zacznij monitorować deliverability w kilka minut.