Jaka jest różnica, w jednym zdaniu?
SMTP to otwarty protokół, którym Twoje oprogramowanie przekazuje pocztę serwerowi; API e-mailowe to specyficzny dla dostawcy interfejs HTTPS, który robi to samo z ustrukturyzowanymi danymi i informacją zwrotną o zdarzeniach. Protokół przekazania nie decyduje, czy trafisz do skrzynki – decydują o tym uwierzytelnianie i reputacja domeny, a SPF, DKIM i DMARC działają identycznie na obu drogach. Wybieraj więc ze względów integracyjnych: przenośność, obsługa błędów, narzędzia. O wszystkim, co dzieje się po przyjęciu wiadomości przez dostawcę, mówi poradnik dostarczalność e-maili dla startupów.
Jak działa wysyłka przez SMTP?
Twoja aplikacja otwiera połączenie z serwerem dostawcy, czyli przekaźnikiem SMTP – przy przekazywaniu zwykle na porcie 587 z uwierzytelnieniem, zgodnie z RFC 6409 – i przekazuje gotową wiadomość. Sam protokół przesyłania to RFC 5321, ustandaryzowany w obecnej formie w 2008 roku i używany znacznie dłużej, dlatego obsługuje go wszystko: każdy framework, CMS, forum, narzędzie do monitoringu czy kilkudziesięcioletni skrypt może wysyłać w ten sposób, mając tylko host, port i dane logowania. To cicha przewaga SMTP – migracja to wymiana danych logowania, więc zmiana platformy e-mailowej nigdy nie oznacza przepisywania kodu wysyłki. To też naturalny wybór dla stosów hostowanych samodzielnie, w których obsługa SMTP jest dostępna domyślnie.
Jak działa wysyłka przez API e-mailowe?
Twój kod wywołuje endpoint HTTPS dostawcy z danymi JSON – odbiorca, treść lub odwołanie do szablonu, tagi, metadane, często klucz idempotencji chroniący przed podwójną wysyłką. Odpowiedź jest synchroniczna: sukces z identyfikatorem wiadomości albo błąd, który Twój kod może przechwycić, by ponowić wysyłkę. Dokumentacja Postmark wprost pokazuje ten kontrast – jego REST API od razu zwraca sukces lub błąd, a endpoint SMTP przyjmuje wszystkie wiadomości i zapisuje ewentualne błędy jako odbicia, nadal dostępne przez webhooki odbić. Po przyjęciu wiadomości webhooki przesyłają do Twojej aplikacji odbicia, skargi i otwarcia, i to właśnie umożliwia automatyczne wykluczanie adresów. SDK dostawców zamykają to wszystko w kilku linijkach; w zamian integracja jest związana z tym jednym dostawcą.
SMTP vs API: bezpośrednie porównanie
Cała decyzja sprowadza się do jednego kompromisu: SMTP daje przenośność, API daje informację zwrotną i narzędzia. Tak wygląda to punkt po punkcie.
| SMTP | API e-mailowe | |
|---|---|---|
| Czym jest | Otwarty protokół (RFC 5321) – wszędzie taki sam | Specyficzny dla dostawcy interfejs produktu przez HTTPS |
| Nakład integracji | Prawie zerowy, jeśli oprogramowanie już obsługuje SMTP: host, port, dane logowania | Kod pod endpoint lub SDK dostawcy |
| Przenośność | Wysoka – zmiana dostawcy to wymiana danych logowania | Niska – format każdego dostawcy jest inny; zmiana oznacza przepisanie integracji |
| Obsługa błędów | Przyjęcie przy przekazaniu; część błędów wychodzi później jako asynchroniczne odbicia | Synchroniczne błędy, które możesz przechwycić, by ponowić wysyłkę, plus zdarzenia asynchroniczne |
| Informacja zwrotna o zdarzeniach | Nic w samym protokole – webhooki odbić dostawcy nadal obejmują pocztę przekazaną przez SMTP, ale podłączasz je osobno | Webhooki przesyłają odbicia, skargi i otwarcia do Twojej aplikacji |
| Szablony i analityka | Nic w samym protokole – wysyłasz gotową wiadomość | Odwołania do szablonów, tagi i metadane dla każdej wiadomości |
| Przy self-hostingu | Naturalne dopasowanie – oprogramowanie hostowane samodzielnie obsługuje SMTP od razu | Kolejna zależność od konkretnego dostawcy w Twoim stosie |
Kiedy SMTP to właściwy wybór?
- Oprogramowanie, które już obsługuje SMTP – CMS, forum, helpdesk czy starsza aplikacja zaczyna wysyłać przez Twojego dostawcę, potrzebując tylko nowych danych logowania.
- Maksymalna przenośność – jeśli chcesz móc zmieniać dostawców bez dotykania kodu, SMTP jest neutralnym interfejsem.
- Stosy hostowane samodzielnie – obsługę SMTP ma wbudowaną praktycznie wszystko, co uruchomisz na własnej infrastrukturze, bez potrzeby SDK.
- Poczta operacyjna o małym wolumenie – alerty z crona i wewnętrzne powiadomienia rzadko uzasadniają dedykowaną integrację z API.
Kiedy API to właściwy wybór?
Przy wysyłkach z produktu na dużą skalę. Gdy e-mail jest wpięty w Twoją aplikację – onboarding, potwierdzenia zakupu, przepływy cyklu życia klienta – synchroniczne błędy, odwołania do szablonów i webhooki zdarzeń są warte kosztu integracji, a lista wykluczeń może aktualizować się sama w chwili, gdy adres się odbije albo zgłosi skargę. Jednego API nie daje: reputacji. Ta należy do Twojej domeny wysyłkowej, a nie do drogi przekazania, więc rozgrzewanie domeny i uwierzytelnianie działają identycznie, niezależnie od sposobu przekazania.
Dlaczego fromHello obsługuje oba sposoby?
Ponieważ to decyzja integracyjna, a nie kwestia dostarczalności, fromHello ma adaptery dla obu: API HTTP (Resend, Postmark, SendGrid), dowolnego serwera SMTP i skrzynek Microsoft 365. Ustawiasz domyślnego dostawcę dla każdej przestrzeni roboczej i możesz przypisać szablonowi jego własnego dostawcę. Na fromHello Cloud, we wczesnym dostępie, plany Team i wyższe mają skonfigurowaną wysyłkę e-maili; w planie Core lub przy self-hostingu korzystasz z własnego dostawcy. Limity i tak obowiązują na poziomie dostawcy – Resend na przykład dokumentuje dla swojego endpointu SMTP ten sam limit częstotliwości co dla API. A wykluczenia i zgody platforma egzekwuje niezależnie od drogi przekazania: wykluczony adres pozostaje wykluczony, czy wiadomość wychodzi przez HTTPS, czy przez port 587.