Jak wysyłać e-maile z aplikacji (i trafiać do skrzynki odbiorczej)

Aby wysyłać e-maile z aplikacji niezawodnie, użyj dostawcy usługi wysyłki zamiast własnej skrzynki, wysyłaj z adresu na własnej domenie i dodaj rekordy DNS, które podaje dostawca, tak aby SPF, DKIM i DMARC przechodziły weryfikację. Trzymaj e-maile transakcyjne — resety haseł, potwierdzenia, rachunki — osobno od marketingowych, wysyłaj każdy typ tylko do osób, które się go spodziewają, i obsługuj odbicia oraz wypisywanie się. Uwierzytelnianie ustaw najpierw; to najczęstszy powód, dla którego e-maile z aplikacji lądują w spamie.

E-mail transakcyjny a marketingowy

Te dwa rodzaje e-maili w kodzie wyglądają podobnie, ale skrzynki odbiorcze i przepisy traktują je zupełnie inaczej.

Trzymaj je osobno. Jeśli kampania marketingowa dostanie skargi na spam, nie chcesz, żeby przez to cierpiały resety haseł wysyłane z tego samego strumienia. Częste rozwiązanie to osobne subdomeny — na przykład mail.example.com dla poczty konta i news.example.com dla newsletterów — a niektórzy dostawcy rozdzielają oba typy wewnętrznie. Postmark na przykład opisuje swoje strumienie wiadomości transakcyjnych i broadcast jako działające na oddzielnej infrastrukturze wysyłkowej (stan na wrzesień 2026).

Wybór dostawcy

Aplikacja nie powinna wysyłać e-maili sama, z własnego serwera. Dostawcy wysyłki zajmują się infrastrukturą, reputacją IP, ponowieniami i obsługą odbić. Znane opcje to Postmark, Resend, SendGrid, Amazon SES i Mailgun; każdy ma API HTTP i dostęp przez SMTP, a ceny i plany się zmieniają, więc porównaj je na ich stronach.

Na co zwrócić uwagę:

• Specjalizacja. Niektórzy dostawcy skupiają się na transakcyjnych, inni łączą transakcyjne i marketingowe.
• Wygoda dla developera. Przejrzyste API, oficjalne biblioteki dla Twojego języka, przydatne logi pokazujące, czy wiadomość została dostarczona, odbita lub oznaczona jako spam.
• Webhooks dla odbić, skarg i dostarczeń, żeby aplikacja mogła na nie reagować.
• Szablony — przechowywane u dostawcy albo w Twoim kodzie. Trzymanie ich w kodzie sprawia, że są wersjonowane i testowalne.
• Region i obsługa danych, jeśli masz wymagania dotyczące tego, gdzie dane są przetwarzane.
• Koszt przy Twoim wolumenie, łącznie z tym, co się dzieje po przekroczeniu darmowego progu.

Do newsletterów dla listy często lepiej sprawdzi się dedykowane narzędzie do newsletterów lub e-mail marketingu niż budowanie funkcji kampanii w aplikacji.

Skonfiguruj domenę nadawcy

Wysyłaj z własnej domeny — hello@example.com, a nie z adresu Gmail czy Outlook. Poczta z darmowego adresu wysyłana przez zewnętrzną usługę nie przechodzi kontroli uwierzytelniania i jest prawdopodobnie filtrowana.

Rozważ subdomenę tylko do wysyłki. Resend na przykład zaleca wysyłanie z subdomen, takich jak updates.example.com, aby odizolować reputację nadawcy (stan na wrzesień 2026). Dzięki temu rekordy DNS poczty są oddzielone od rekordów Twojej głównej strony.

Dostawca poda rekordy DNS do dodania tam, gdzie zarządzany jest DNS Twojej domeny. Jeśli DNS jest dla Ciebie nowy, jak działają domeny i DNS wyjaśnia najpierw rekordy.

SPF

SPF (Sender Policy Framework) to rekord TXT z listą serwerów, które mogą wysyłać pocztę w imieniu Twojej domeny. Odbiorca sprawdza, czy serwer wysyłający znajduje się na liście.

• Domena powinna mieć tylko jeden rekord SPF. Dodając dostawcę, scal go z istniejącym rekordem zamiast dodawać drugi.
• SPF pozwala na maksymalnie 10 zapytań DNS podczas oceny; długie łańcuchy wpisów include: mogą to przekroczyć i spowodować błędy.
• Wielu dostawców ustawia SPF na subdomenie return-path, którą każą Ci utworzyć, więc możesz w ogóle nie dotykać głównego rekordu SPF.

DKIM

DKIM (DomainKeys Identified Mail) dodaje kryptograficzny podpis do każdej wiadomości. Dostawca podpisuje kluczem prywatnym, a Ty publikujesz odpowiadający mu klucz publiczny jako rekord DNS (TXT lub CNAME, zależnie od dostawcy). Odbiorcy sprawdzają podpis, by upewnić się, że wiadomość pochodzi od autoryzowanego nadawcy i nie została zmieniona po drodze.

DKIM to głównie to, czego dotyczy krok „weryfikacji domeny” u dostawcy. Nie pomijaj go.

DMARC

DMARC łączy pozostałe dwa mechanizmy. To rekord TXT pod adresem _dmarc.twojadomena.com, który mówi odbiorcom:

• Wyrównanie (alignment): domena widocznego adresu From musi być zgodna z domeną, która przeszła SPF lub DKIM.
• Politykę: co zrobić z pocztą, która nie przeszła — p=none (tylko raportuj), p=quarantine (traktuj jako podejrzaną, często spam) albo p=reject.
• Raporty: dokąd wysyłać zbiorcze raporty (rua=), żebyś widział, kto wysyła jako Twoja domena.

Rozsądnie jest zacząć od p=none z adresem do raportów, upewnić się, że Twoja legalna poczta przechodzi, a następnie przejść na quarantine i w końcu na reject. Ścisła polityka utrudnia też innym podszywanie się pod Twoją domenę.

Czego wymaga Gmail

Od września 2026 wytyczne nadawców Google mówią:

• Wszyscy nadawcy wysyłający na prywatne konta Gmail potrzebują SPF lub DKIM, poprawnego forward i reverse DNS dla serwerów wysyłających, TLS oraz wskaźnika spamu w Postmaster Tools poniżej 0,3%.
• Nadawcy masowi (ponad 5000 wiadomości dziennie na Gmail) potrzebują SPF i DKIM, rekordu DMARC (polityka p=none jest dozwolona), zgodności domeny From oraz jednokliknięcia wypisu i widocznego linku do wypisu w wiadomościach marketingowych i subskrybowanych.

Dostawca obsługuje części po stronie serwera. Rekordy DNS i obsługę wypisów masz po swojej stronie. Nawet jeśli wysyłasz znacznie mniej niż 5000 dziennie, spełnienie reguł dla nadawców masowych to najprostszy sposób, by być bezpiecznym.

Wbuduj wysyłkę w aplikację

Gdy domena zostanie zweryfikowana:

1. Zapisz klucz API jako sekret po stronie serwera — nigdy w kodzie front-endu. Zobacz czym są zmienne środowiskowe i sekrety.
2. Wysyłaj z serwera, po tym, jak akcja wywołująca e-mail się powiedzie.
3. Nie każ użytkownikowi czekać na e-mail. W przypadku czegokolwiek więcej niż najprostsza aplikacja, kolejkuj wysyłkę i ponawiaj przy tymczasowych błędach, aby wolna odpowiedź dostawcy nie spowalniała rejestracji.
4. Zapisuj wynik — identyfikator wiadomości u dostawcy i status — bez logowania klucza i pełnej treści wiadomości zawierającej dane osobowe.
5. Obsługuj webhooks dla odbić i skarg: przestań wysyłać na adresy, które twardo się odbijają lub zgłaszają spam.

Prompt obejmujący podstawy:

Wysyłaj e-maile transakcyjne przez [PROVIDER], używając sekretu serwera [ENV_NAME], z adresu „Acme hello@mail.acme.com”. Wyślij e-mail powitalny po rejestracji i potwierdzenie rezerwacji po zapisaniu rezerwacji. Trzymaj szablony w kodzie, z wersją zwykłego tekstu obok HTML. Kolejkuj wysyłki i ponawiaj tymczasowe błędy do trzech razy. Loguj błędy z odpowiedzią dostawcy, ale nigdy klucza API. Dodaj endpoint webhook, który oznacza adresy jako nieosiągalne przy twardych odbiciach i skargach, i pomijaj je w przyszłości.

E-maile konta — linki weryfikacyjne, magic linki i resety haseł — są częścią logowania. Jak dodać logowanie do aplikacji pokazuje, jak te przepływy do siebie pasują; takie linki powinny być jednorazowe i krótkotrwałe.

Nawyki zapewniające dostarczalność

Uwierzytelnianie sprawia, że jesteś brany pod uwagę. Zachowanie utrzymuje Cię w skrzynce odbiorczej.

• Wysyłaj tylko to, czego ludzie się spodziewają. Potwierdzone rejestracje, wyraźna zgoda na marketing, żadnych kupionych list.
• Ułatw wypisywanie się przy wszystkim, co nie jest ściśle transakcyjne, i honoruj je natychmiast.
• Stopniowo rozgrzewaj nowe domeny. Nowa domena, która pierwszego dnia wysyła tysiące wiadomości, wygląda podejrzanie. Zacznij od poczty transakcyjnej i stopniowo zwiększaj wolumen.
• Czyść listy. Usuwaj twarde odbicia od razu i rozważ usunięcie osób, które od dawna niczego nie otworzyły.
• Pisz jak człowiek. Jasny temat, rozpoznawalna nazwa nadawcy, część w zwykłym tekście, niewiele obrazków i linki do Twojej domeny. Unikaj skracaczy linków.
• Monitoruj. Zarejestruj domenę w Google Postmaster Tools i od czasu do czasu czytaj raporty DMARC.
• Używaj prawdziwego adresu odpowiedzi, na który ktoś faktycznie zagląda. Odpowiedzi są dobrym sygnałem i cennym feedbackiem.

Testowanie bez spamowania nikogo

• Używaj trybu testowego lub sandboxa dostawcy, jeśli go ma, albo wysyłaj na adresy, które sam kontrolujesz.
• W środowisku deweloperskim wysyłaj na testową skrzynkę typu catch-all zamiast do prawdziwych użytkowników; baza z danymi wyglądającymi na prawdziwe adresy to prosty sposób na przypadkowe wysłanie wiadomości do obcych ludzi.
• Sprawdź każdy szablon w kilku klientach — Gmail w przeglądarce, aplikacja pocztowa w telefonie, Outlook — oraz w trybie ciemnym.
• Zajrzyj do nagłówków testowego e-maila: pokazują, czy SPF, DKIM i DMARC przeszły weryfikację.

Podstawy prawne

Przepisy różnią się w zależności od kraju. Ogólnie: e-mail marketingowy w wielu miejscach wymaga zgody, musi identyfikować nadawcę i oferować działający link do wypisu; e-mail transakcyjny jest traktowany inaczej, ale nie powinien być używany do przemycania marketingu. Jeśli zbierasz adresy z strony z listą oczekujących, powiedz jasno, co i kiedy będziesz wysyłać oraz jak i kiedy każda osoba się zapisała. W razie wątpliwości sprawdź przepisy obowiązujące tam, gdzie są Twoi użytkownicy.

Lista kontrolna e-maili

• Wybrany dostawca wysyłki; klucz API zapisany jako sekret serwera
• Wysyłka z własnej domeny lub subdomeny, a nie z darmowej skrzynki
• Rekordy SPF, DKIM i DMARC dodane i przechodzące weryfikację
• Poczta transakcyjna i marketingowa rozdzielone
• Wysyłki kolejkowane i ponawiane; wyniki zalogowane
• Obsłużone webhooks odbić i skarg
• Wypis w e-mailach niebędących transakcyjnymi, honorowany natychmiast
• Szablony przetestowane w kilku klientach; testowa poczta nigdy nie trafia do prawdziwych użytkowników

Wysyłanie e-maili z aplikacji Mythex

Mythex nie zawiera wbudowanej usługi wysyłki e-maili dla aplikacji, które budujesz, więc przynosisz własnego dostawcę, na przykład Resend, SendGrid albo Postmark. Zapisz jego klucz API jako sekret projektu — agent może o niego poprosić kartą sekretów na czacie — i opisz zwykłymi słowami e-maile, których potrzebujesz. Starter prompt znajdziesz w dokumentacji w wysyłaniu e-maili z aplikacji. Jeśli kupiłeś domenę przez Mythex w planie Pro, możesz dodać rekordy TXT i CNAME dostawcy w ustawieniach DNS domeny; zobacz domeny własne.

Pytania