Poczta z aplikacji dla firmy — dlaczego maile nie dochodzą i co ustawić (SPF, DKIM, DMARC)?

Z jakich warstw składa się poczta wysyłana z aplikacji?

Z pięciu, a nie z jednej funkcji „wyślij”. Domena nadawcza z rekordami w DNS, dostawca poczty transakcyjnej wywoływany przez API, szablony wiadomości, zdarzenia zwrotne i skrzynka, na którą ktoś naprawdę odpowiada. Brak którejkolwiek widać dopiero wtedy, gdy klient mówi, że nie dostał potwierdzenia.

Ta warstwa jest osobna także dlatego, że rozstrzyga o niej ktoś inny: serwer odbiorcy. To on czyta rekordy w DNS i decyduje, czy list wejdzie do skrzynki odbiorczej, do spamu, czy wróci z błędem. Aplikacja nie ma tu głosu — ma tylko dowody, które zostawiła w DNS.

W podziale aplikacji na warstwy poczta należy do usług zewnętrznych, obok płatności i bramki SMS. Różni ją jedno: skutek złej konfiguracji widzi klient, a firma dowiaduje się o nim najpóźniej.

Progi, od których to przestaje być kwestią dobrej woli, są opisane wprost. Gmail wymaga od nadawców powyżej 5 000 wiadomości dziennie równocześnie SPF, DKIM i DMARC, a od wszystkich nadawców — odsetka zgłoszeń spamu poniżej 0,30 % w Postmaster Tools (wytyczne dla nadawców, odczyt 31 sierpnia 2026).

Outlook postawił ten sam próg 5 000 wiadomości dziennie od 5 maja 2025: domena bez SPF, DKIM i DMARC trafia najpierw do folderu ze spamem, a docelowo ma być odrzucana z odpowiedzią 550 5.7.515 (wpis zespołu Microsoft Defender for Office 365, odczyt 31 sierpnia 2026).

Decyzja i dlaczego: wysyłka tylko z funkcji po stronie serwera

W aplikacjach, które budujemy, listy wysyła dostawca poczty transakcyjnej wywoływany przez API — i tylko z funkcji po stronie serwera, z kluczem w ustawieniach dostawcy, nigdy w repozytorium ani we froncie. Przeglądarka nie wysyła poczty. Ta jedna decyzja zamyka trzy różne awarie naraz.

Pierwsza alternatywa to własny serwer poczty. Dostarczalność zależy wtedy od reputacji pojedynczego adresu IP, którą buduje się miesiącami, a traci w jeden wieczór po wycieku formularza kontaktowego. To praca na lata, nie na tydzień budowy aplikacji.

Druga to wysyłka ze skrzynki firmowej przez SMTP. Automat zaczyna wtedy dzielić limit i reputację z ludźmi: Gmail w Google Workspace pozwala na 2 000 wiadomości w oknie 24 godzin, a po przekroczeniu blokuje wysyłkę nawet na 24 godziny (dokumentacja Google Workspace, odczyt 31 sierpnia 2026).

Trzecia to klucz dostawcy poczty w kodzie strony. Klucz w przeglądarce znaczy, że dowolna osoba wyśle wiadomość w imieniu firmy, z jej domeną w polu nadawcy. Klucz w repozytorium, nawet prywatnym, traktujemy jako incydent i rotujemy od razu — reszta zasad jest w tekście o bezpieczeństwie od pierwszego dnia.

Zysk z tej decyzji widać w jednym miejscu: podpis DKIM i rekord SPF wskazują na dostawcę, a nie na przypadkowy serwer, z którego akurat poszedł list. Domena ma wtedy jedną historię wysyłek zamiast kilku, a serwer odbiorcy ocenia ją jako całość.

Dostawca poczty przetwarza adresy i treści wiadomości klientów, więc trafia na listę podmiotów, którym firma powierza dane. Co z tego wynika w kodzie, opisuje osobny tekst o RODO w aplikacji dla firmy.

Trzy rekordy DNS — co sprawdza odbiorca i jak wygląda błąd

Wszystkie trzy to wpisy tekstowe w strefie DNS domeny, dopisywane u dostawcy domeny, a nie w pliku konfiguracyjnym projektu. Każdy odpowiada na inne pytanie serwera odbiorcy i każdy psuje się inaczej.

• SPF — lista serwerów, które mogą wysyłać w imieniu domeny. Odbiorca liczy odpytania DNS przy jej rozwijaniu: powyżej 10 wynik to permerror, czyli SPF przestaje działać, choć rekord w domenie stoi (RFC 7208, sekcja 4.6.4, odczyt 31 sierpnia 2026).
• DKIM — podpis kryptograficzny każdej wiadomości, sprawdzany kluczem publicznym z DNS. RFC 8301 wymaga kluczy co najmniej 1024-bitowych i zaleca 2048, a podpisy rsa-sha1 uznaje za trwale nieważne (odczyt 31 sierpnia 2026).
• DMARC — wpis pod nazwą _dmarc mówi, co zrobić z listem, który nie potwierdził ani SPF, ani DKIM: none, quarantine albo reject. Adres w polu rua zbiera raporty zbiorcze. Od maja 2026 DMARC opisuje RFC 9989 w statusie Proposed Standard, zastępując RFC 7489 i RFC 9091 (odczyt 31 sierpnia 2026).
• Zgodność z polem nadawcy — do DMARC wystarczy jeden przechodzący mechanizm, ale domena z pola nadawcy musi być zgodna z domeną SPF albo DKIM (wytyczne Google dla nadawców, odczyt 31 sierpnia 2026). Bez tej zgodności wysyłka wygląda dla odbiorcy jak podszycie.

Reguła po własnej lekcji: rekordy poczty ustawiamy na poziomie domeny u jej dostawcy i sprawdzamy, czy strefa DNS w ogóle istnieje, zanim ogłosimy start. Domena kupiona w jednym miejscu i wskazana serwerami nazw na hosting nie dostaje strefy sama — wygląda wtedy jak działająca, a nie odpowiada.

Weryfikacja domeny nadawczej u dostawcy poczty trwa do 72 godzin (dokumentacja Resend, odczyt 31 sierpnia 2026). To jedna z rzeczy do załatwienia na początku budowy, a nie w tygodniu startu — razem z resztą dostępów, które dostarcza zamawiający.

Co zmienia skala: 10, 1 000 i 10 000 użytkowników?

Trzy rzeczy: limit dzienny dostawcy, tempo wysyłki i obowiązki wobec dużych dostawców skrzynek. Rekordy DNS wyglądają tak samo przy dziesięciu i przy dziesięciu tysiącach kont — reszta nie.

Przy dziesięciu kontach limity są bez znaczenia, a rekordy i tak muszą być gotowe przed pierwszym mailem produkcyjnym. Plan darmowy Resend obejmuje 100 wiadomości dziennie i 3 zweryfikowane domeny, przy czym każdy adres w polach kopii liczy się osobno, a listy przychodzące też zjadają tę pulę (dokumentacja, odczyt 31 sierpnia 2026).

Przy tysiącu kont darmowy plan kończy się na pierwszym powiadomieniu do wszystkich: to dziesięciokrotność limitu dziennego. Odzywa się też tempo — domyślny limit API to 10 zapytań na sekundę na zespół, a jedenaste w tej samej sekundzie dostaje odpowiedź 429 (dokumentacja Resend, odczyt 31 sierpnia 2026). Tysiąc listów to minimum sto sekund pracy kolejki.

Przy dziesięciu tysiącach kont przekroczenie 5 000 wiadomości dziennie zamienia zalecenia w wymagania: SPF, DKIM i DMARC obowiązkowo po stronie Gmaila i Outlooka, a przy wiadomościach marketingowych dochodzi rezygnacja jednym kliknięciem.

Powiadomienia z aplikacji warto wtedy trzymać na innej poddomenie niż poczta ludzi — dostawca zaleca to wprost, żeby reputacja liczyła się osobno (dokumentacja Resend, odczyt 31 sierpnia 2026).

Rachunek rośnie inaczej, niż wygląda w cenniku: plany płatne mają twardy sufit nadwyżek na poziomie pięciokrotności miesięcznego limitu, po którym wysyłka staje do końca okresu rozliczeniowego (dokumentacja Resend, odczyt 31 sierpnia 2026). Ile kosztuje cała aplikacja w rachunku trzyletnim, liczy osobny serwis.

Co mierzyć po stronie aplikacji?

Trzy rzeczy przy adresie, nie w arkuszu: czy list dotarł, czy odbił się trwale, czy odbiorca oznaczył go jako spam. Dostawca podaje to jako zdarzenia zwrotne — Resend opisuje 11 typów zdarzeń dotyczących wiadomości (dokumentacja, odczyt 31 sierpnia 2026).

Zdarzenie trzeba przyjąć i zapisać, a nie tylko obejrzeć w panelu dostawcy. Przy braku odpowiedzi 200 dostawca ponawia je po 5 s, 5 min, 30 min, 2 h, 5 h i 10 h, a kolejność zdarzeń nie jest gwarantowana (dokumentacja Resend, odczyt 31 sierpnia 2026). Sortujemy je po znaczniku czasu z treści zdarzenia.

Odbicia dzielą się na trwałe, przejściowe i nieokreślone. Adres z trwałym odbiciem albo ze skargą trafia u dostawcy na listę zablokowanych i kolejne listy do niego nie wychodzą (dokumentacja Resend, odczyt 31 sierpnia 2026). Ten sam stan powinien być widoczny przy koncie w aplikacji, żeby obsługa widziała powód, zanim zadzwoni klient.

Odsetek zgłoszeń spamu jest tu jedyną liczbą z twardym progiem z zewnątrz: poniżej 0,10 % jako cel i nigdy 0,30 % (wytyczne Google dla nadawców, odczyt 31 sierpnia 2026). Reszta pomiaru po starcie jest w tekście o tym, co mierzyć po starcie.

Jak sprawdzić to samemu w pięć minut?

Bez programisty i bez narzędzi konsolowych. Wystarczy konto Gmail i konto Outlook, czyli dokładnie to, czego używają klienci.

• Wyślij z aplikacji prawdziwe potwierdzenie na własny adres Gmail i na własny adres Outlook. Sprawdź, czy list wszedł do skrzynki odbiorczej, czy do spamu.
• W Gmailu otwórz podgląd oryginału wiadomości i przeczytaj trzy linie wyniku: spf, dkim i dmarc. Każda ma pokazywać wynik pozytywny.
• Sprawdź adres nadawcy i adres odpowiedzi. Jeśli oba zaczynają się od słowa „noreply”, odpowiedź klienta nie trafi do nikogo.
• Zapytaj wykonawcę o dwie rzeczy: gdzie leży klucz dostawcy poczty i co aplikacja robi po zdarzeniu odbicia. Odpowiedź „nic” znaczy, że listy będą wychodzić na martwy adres do skutku.